프론트-백 통신 기초: HttpSession과 REST API 공부하기

주말 과제가 SpringBoot Web에 static resource를 넣어서 회원가입, 로그인 기능을 HttpSession으로 처리하고

로그인 된 사용자만 OTT 컨텐츠를 선택할 수 있는 기능을 구현한 웹페이지를 만드는 것이었다.

 

통신을 하는 과정을 구현하는 것도 쉽지 않았지만 원리에 대한 이해도가 너무 떨어져 공부해야겠다고 느꼈다.

 

출처: https://velog.io/@matisse/%EB%B0%B1%EC%97%94%EB%93%9Cback-end-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-feat.-%ED%94%84%EB%A1%A0%ED%8A%B8

 

 

먼저 HttpSession에 대해 공부해보자.

Java HttpSession(javax.Servlet.Http)

HttpSession은 Java의 인터페이스이며, 이를 사용해 세션(session)을 제어할 수 있다.

session은 쿠키의 트래픽 이슈와 쿠키 변경으로 인한 보안 이슈를 해결하기 위해 등장했다.

session

세션은 서버가 사용자별 상태를 일정 시간 동안 유지하기 위해 사용하는 저장 공간을 말한다.

HTTP는 기본적으로 상태를 유지하지 않는 프로토콜이다. 즉, 브라우저가 서버에 요청을 한 번 보내면 서버는 그 요청이 누구로부터 왔는지 기억하지 못한다.

그러므로 세션은 사용자별 상태를 유지해야 할 때 사용된다.

 

session 동작 원리

1. client가 server에 리소스(resource)를 요청한다.

2. server는 client가 요청한 request-header의 session cookie를 통해 session-id를 확인한다.

3. session-id가 존재하면, server는 session-id가 유효한지 확인 후 client의 요청을 처리하고 응답(response)한다.

4. session-id가 존재하지 않으면, server는 set-cookie를 통해 session-id를 생성한 후 response-header에 추가하여 client에 응답한다.

5. 위 4번 항목 처리 후 client는 server에 요청 시, server로부터 응답한 session-id를 request-header에 추가하여 요청한다.

특징 

특징	설명
서버 메모리 기반	세션은 서버 RAM에 저장됨 → 사용자가 많으면 서버 부담 ↑
브라우저 쿠키 사용	세션 ID를 쿠키로 전달 → 서버가 사용자 식별
상태 유지 시간	기본 30분, 서버 설정 가능 (server.servlet.session.timeout)
보안 주의	세션 ID 탈취 위험 → HTTPS, HttpOnly 옵션 필수
장점	로그인 상태 유지, 사용자별 데이터 관리 쉬움
단점	서버 메모리 부담, RESTful 서비스에서는 상태 없는 토큰(JWT) 선호

 

코드 예시 (Spring Boot)

// 로그인
public boolean login(String id, String pw, HttpSession session) {
    Member m = memberService.findMember(id); // id로 회원인지 확인 없으면 null
    // 회원이 아니거나 비밀번호가 틀리면 로그인 실패
    if (m != null && m.getPw().equals(pw)) { 
        session.setAttribute("loginUser", m);
        return true;
    }

    return false;
}

// 로그아웃
public void logout(HttpSession session) {
    session.invalidate(); // 세션 무효화
}

// 로그인 상태 확인
public boolean isLogin(HttpSession session) {
    return session != null && session.getAttribute("loginUser") != null;
}

로그인 기능, 로그아웃, 로그인 상태를 확인하는 서버 코드이다.

 

클라이언트가 /login 요청을 보내면 서버 쪽에서 HttpSession 객체가 존재하지 않으면 생성되고, 로그인 성공 시 session.setAttribute("loginUser", m)으로 세션에 사용자 정보를 저장한다.

 

새 세션이 생성되면 서버는 응답 시 Set-Cookie: JSESSIONID=... 헤더를 같이 내려보내고 브라우저는 그 값을 쿠키로 저장한다.

이후 요청들은 Cookie: JSESSIONID=...를 포함해서 보내므로 서버는 같은 세션을 찾아 로그인 상태를 유지한다.

 

이를 실행해보면 개발자 도구에서 session 쿠키를 확인할 수 있다.

Application 탭에서 JSESSIONID와 값을 볼 수 있다.

 

Network 탭에서 login요청을 보면 Cookie의 JSESSION의 값이 내려져 있는 것을 볼 수 있다.

 

HttpSession

HttpSession은 client request에서 client를 식별하고 해당 client 정보를 저장하는 방법을 제공하는 Java의 public interface이다.

HttpSession interface를 사용하는 서블릿 컨테이너(servlet container)는 server와 client간의 session을 제어한다.

 

servlet container는 웹 container라고도 불리며 Tomcat, JBoss, Jetty 등이 대표적이다.

여기서 servlet container와 servlet은 다르다.

servlet container는 server에서 servlet 생명 주기(life cycle) 관리, request에 따른 
스레드(thread) 생성, 동적(dynamic) resource(JSP, servlet 등) 생성 등 
servlet과 상호 작용하는 web server의 일부이다.
servlet은 javax.servlet package에 정의된 interface이며, JVM(java virtual machine) 내에서 
실행되는 web application의 작은 조각이다.

 

즉, 우리가 웹어플리케이션을 개발할 때 사용하는 HttpSession은 Servlet Container가 생성하는 인스터스이다.

Spring은 Servlet Container가 만든 HttpSession을 주입할 뿐, HttpSession을 생성하는 주체는 Servlet Container이다.

 

---

 

HttpSession 방식에 대해 알아봤는데 이외에도 강사님이 JWT라는 방식이 자주 쓰이지만 사실 보안상 좋지만은 않다고 하셨었다.

그래서 JWT가 무엇인지 알아보려고 한다.

 

 

JWT (Json Web Token)

JWT는 Json 객체에 인증에 필요한 정보들을 담은 후 비밀키로 서명한 토큰으로, 인터넷 표준 인증 방식이다. 공식적으로 인증(Authentication)과 권한허가(Authorization) 방식으로 사용된다.

 

 

JWT 프로세스

출처: https://velog.io/@chuu1019/%EC%95%8C%EA%B3%A0-%EC%93%B0%EC%9E%90-JWTJson-Web-Token

 

로그인 이전 과정

1. 사용자가 아이디와 비밀번호 혹은 소셜 로그인을 이용하여 서버에 로그인 요청을 보낸다.

2. 서버는 비밀키를 사용해 json 객체를 암호화한 JWT 토큰을 발급한다.

3. JWT를 헤더에 담아 클라이언트에 보낸다.

 

로그인 이후 과정

1. 클라이언트는 JWT를 로컬에 저장해놓는다.

2. API 호출을 할 때마다 header에 JWT를 실어 보낸다.

3. 서버는 헤더를 매번 확인하여 사용자가 신뢰할만한지 체크하고 인증이 되면 API에 대한 응답을 보낸다.

 

JWT의 구조

출처: https://velopert.com/2389

 

JWT는 Header, Payload, Signature 3개로 구성되어 있다.

 

Header

{ "alg": "HS256", "typ": "JWT" }

 

• alg: Signature에서 사용하는 알고리즘
• typ: 토큰 타입

Signature에서 사용하는 알고리즘은 대표적으로 RS256(공개키/개인키)와 HS256(비밀키(대칭키))가 있다.

이 부분은 auth0 공식 문서에서 자세히 볼 수 있다.

 

Payload

사용자 정보의 한 조각인 클레임(claim)이 들어있다.

{
  "sub": "user123",
  "iss": "my-app",
  "iat": 1610000000,
  "exp": 1610003600,
  "role": "USER"
}

• sub : 토큰 제목(subject)
• aud : 토큰 대상자(audience)
• iat : 토큰이 발급된 시각 (issued at)
• exp : 토큰의 만료 시각 (expired)

Signature

Signature는 헤더와 페이로드의 문자열을 합친 후에, 헤더에서 선언한 알고리즘과 key를 이용해 암호한 값이다.

 

Header와 Payload는 단순히 Base64url로 인코딩되어 있어 누구나 쉽게 복호화할 수 있지만, Signature는 key가 없으면 복호화할 수 없다. 이를 통해 보안상 안전하다는 특성을 가질 수 있게 되었다.

앞서 언급한 것처럼 header에서 선언한 알고리즘에 따라 key는 개인키가 될 수도 있고 비밀키가 될 수도 있다. 개인키로 서명했다면 공개키로 유효성 검사를 할 수 있고, 비밀키로 서명했다면 비밀키를 가지고 있는 사람만이 암호화 복호화, 유효성 검사를 할 수 있다.

 

직접 사용해보기

https://www.jwt.io/

JSON Web Tokens - jwt.io

위의 사이트에서 token 값을 입력하면 현재 자신이 사용중인 jwt 토큰이 어떤 구조로 되어있는 눈으로 확인할 수 있다.

 

 

header와 payload는 누구나 쉽게 확인할 수 있기 때문에 이 부분들에는 중요한 정보를 담으면 안된다.

 

JWT 장단점

장점

• 서버가 세션 저장소를 관리할 필요가 없다.
• 여러 마이크로서비스에서 토큰 검증만으로 인증 가능하다. 
• 토큰 자체에 사용자 정보 포함 가능하다.

단점

• 토큰이 발급되면 만료 전까지 유효하다. 즉시 로그아웃과 폐기가 여렵다.
• JWT는 비교적 크기가 있어 네트워크 부담이 증가할 수 있다.
• 잘못 저장하면 XSS/CSRF에 취약하다.
• 페이로드는 인코딩만 될 뿐 암호화가 아니다. 중요한 정보는 절대 저장 금지해야 한다.

 

느낀 점

백엔드를 자바로 구현해보는 과제를 하면서 다양한 분야를 경험해볼 수 있어서 좋았다. 특히 객체 지향적으로 코드를 짜보는 건 어려웠지만 분석을 하면서 코드를 짠다는 재미가 있었다. 

 

부족하다고 느낀 건 통신에 대한 기초지식이 많이 부족하다고 느꼈다. CS 공부의 필요성을 더 느꼈고 그래도 하나씩 넓혀가다보면 처음 접하는 게 생기더라도 이해하는 속도가 가속될 거라는 확신이 들었다. 다양하게 받아들이면서 견문을 넓혀야겠다.

 

 

참고 자료 : 

https://velog.io/@dmchoi224/Session-HttpSession-%EC%9D%B8%ED%84%B0%ED%8E%98%EC%9D%B4%EC%8A%A4.-%EC%BF%A0%ED%82%A4

Session, HttpSession 인터페이스. 쿠키

https://velog.io/@chuu1019/%EC%95%8C%EA%B3%A0-%EC%93%B0%EC%9E%90-JWTJson-Web-Token

😎 알고 쓰자, JWT(Json Web Token).