Cookie와 Session, JWT

[ParkYK]

Authentication(인증) vs Authorization(인가)

두 개의 단어는 비슷해보이지만 엄연히 다른 프로세스이다. Authentication은 인증이고, Authorization은 인가(권한 부여)인데 로그인 시스템에서 중요한 역할을 한다. 예를 들어 웹사이트에서 로그인하는 것을 Authentication이라고 한다. 한번 로그인을 한 후에는 로그인 상태가 유지되어야 한다. 이 역할을 하는 것이 Authorization이다. 즉, 권한 부여를 통해 로그인 상태의 사용자만 사용할 수 있는 기능을 사용할 수 있게 한다.

인증 : 어떤 개체의 신원을 확인하는 과정이다. 다시 말해 누구인지 확인하는 행위이다. 보통 어떤 인증요소를 증거로 자신을 증명한다. 온라인에서는 ID 와 패스워드를 입력하는 행위가 인증이 될 수 있다.
인가 : 어떤 리소스에 접근할 수 있는지, 어떤 동작을 수행할 수 있는지 검증한다.
접근 권한을 얻는 일이다. 권한이 있는지 확인하는 행위라 할 수 있다.

클라이언트의 모든 요청마다 로그인을 할 수는 없는 노릇이니 로그인 상태를 유지시키는 기술이 필요하다. 이때 사용될 수 있는 기술이 Cookie & Session이나 JWT이다.

쿠키(Cookie)

HTTP의 일종으로 사용자가 어떤 웹 사이트를 방문할 경우, 해당 사이트가 사용하고 있는 서버에서 사용자의 컴퓨터에 저장하는 작은 기록 정보 파일이다. HTTP에서 클라이언트의 상태정보를 쿠키(이름, 값) 형태로 클라이언트 PC에 저장하였다가 필요 시 정보를 참조하거나 재사용할 수 있다.

쿠키의 특징

 - Key-Value로 구성되어 있다.
 - 쿠키이름, 쿠키값, 만료시간, 전송할 도메인명, 전송할 경로, 보안 연결여부, HttpOnly 여부로 구성되어 있다.
 - 도메인 당 20개의 쿠키를 가질 수 있으며, 하나의 쿠키는 4KB(= 4096 byte)까지 저장이 가능하다.

쿠키 작동 방식

쿠키의 사용목적

쿠키는 주로 3가지 목적을 위해 사용한다.

 - 세션 관리(Session Management) : 로그인, 사용자 닉네임, 접속 시간, 장바구니 등의 서버가 알아야 할 정보들을 저장.

 - 개인화(Personalization) : 사용자마다 다르게 그 사람에 적절한 페이지를 보여줄 수 있다.

 - 트래킹(Tracking) : 사용자의 행동과 패턴을 분석하고 기록.

쿠키 종류와 특징

Session Cookie	일반적으로 만료시간(Expire Date)를 설정하고 메모리에만 저장되며, 브라우저 종료 시 쿠키를 삭제.
Persistent Cookie	장기간 유지되는 쿠키이다. 파일로 저장되어 브라우저 종료와 관계없이 사용할 수 있다.
Secure Cookie	HTTPS 프로토콜에서만 사용하며, 쿠키 정보가 암호화되어 전송된다.
Third-Party Cookie	방문한 도메인과 다른 도메인의 쿠키이다. 일반적으로 광고 배너 등을 관리할 때 유입 경로를 추적하기 위해 사용한다.

쿠키값 확인 및 단점

브라우저 개발자도구의 네트워크에서 쿠키값을 확인할 수 있지만, 가독성이 떨어지고 수정이 불가능하다. 하지만 '브라우저의 쿠키 관리 탭' 또는 '쿠키 관리 플러그인'을 설치하면 쿠키를 쉽게 수정할 수 있다. 이러한 쿠키는 클라이언트에서 수정할 수 있기 때문에 위변조의 위험이 항상 존재한다. 따라서 쿠키값(value)를 암호화해야 하며, 민감하거나 중요한 정보를 담지 않도록 해야한다.

세션(Session)

세션은 브라우저와 웹 서버가 연결되어 브라우저가 종료될 때까지의 시점이다.  일정 시간 동안 같은 사용자(브라우저)로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 유지시키는 기술이다. 여기서 일정 시간은 방문자가 웹 브라우저를 통해 웹 서버에 접속한 시점부터 웹 브라우저를 종료하여 연결을 끝내는 시점을 말한다.

브라우저를 통해 서버에 접속할 때 서버는 세션 id를 쿠키에 담아 되돌려주고, 사용자는 세션 id를 담은 쿠키인 세션 쿠키를 이 후 요청부터 계속해서 함께 전달함으로 서버가 클라이언트를 식별할 수 있게 하는 기술이 세션 기반 인증 방식인데 보통 세션이라고 한다.

클라이언트가 HTTP요청을 보낼 때 쿠키에 세션 id가 없다면 서버는 세션 id를 생성 해 쿠키에 담아서 돌려준다. 다시 HTTP 재요청을 할 때 쿠키를 보내기 때문에 서버에서는 세션 id를 통해 클라이언트를 식별할 수 있는 것이다.

즉, 브라우저가 종료되기 전까지 클라이언트의 요청을 유지하게 해주는 기술을 세션이라고 한다.

세션의 특징

 - 웹 서버에 웹 컨테이너의 상태를 유지하기 위한 정보를 저장한다.
 - 웹 서버에 저장되는 쿠키(세션 쿠키 / session cookie)이다.
 - 브라우저를 닫거나, 서버에서 세션을 삭제했을 때만 삭제가 되기 때문에 쿠키보다 비교적 보안적으로 우수하다.
 - 저장 데이터에 제한이 없다.(서버 용량 허용 범위 내에서)
 - 각 클라이언트에 고유 세션 ID(Session ID)를 부여한다. 세션 ID를 통해 클라이언트를 구분하여 각 요구에 맞는 서비스를 제공한다.

세션 작동 방식

세션의 사용 목적 : 사용자나 다른 누군가에게 노출되면 안되는 보안적으로 중요한 정보들을 서버 안에서 다루기 위해 사용한다.

* Cookie session이 필요한 이유
HTTP프로토콜은 stateless하다. 클라이언트가 서버로 요청을 하고 응답을 받으면 접속을 끊고 상태정보를 저장하지 않는 특징을 가지고 있다. 그렇기 때문에 예를 들어 쿠키와 세션이 없으면 로그인 상태를 유지하지 않아서 페이지 이동을 하거나 게시판을 작성하는 등의 작업을 할 때마다 로그인을 해야하는 번거로움이 있다.
* Session 기반 인증의 장점
서버에서 클라이언트의 상태를 유지하고 있으므로, 사용자의 로그인 여부와 같은 연결 상태 확인이 용이하고, 경우에 따라서 강제 로그아웃 등의 작업을 할 수 있다. 클라이언트가 임의로 정보를 변경시키더라도 서버에서 클라이언트의 상태 정보를 가지고 있으므로 쿠키에 비해 상대적으로 안전하다.
* Session 기반 인증의 단점
- 서버에서 클라이언트의 상태를 모두 유지하고 있어야 하므로, 클라이언트 수에 따른 메모리, 디스크 또는 DB에 부하가 심하다. 

- 사용자가 많아지는 경우 로드 밸런싱을 통한 서버 확장을 이용해야 하는 데 이 때 세션의 관리가 어려워진다.

- 웹 브라우저에서 세션 관리에 사용하는 쿠키는 단일 도메인 및 서브 도메인에서만 작동하도록 설계되어 CORS 방식(여러 도메인에 request를 보내는 브라우저)을 사용할 때 쿠키 및 세션 관리가 어렵다.

- 멀티 디바이스 환경(모바일, 브라우저 공동 사용 등)에서 중복 로그인 처리가 되지 않는 등의 신경을 써야 할 부분들이 많다.

쿠키 vs 세션

저장 위치	Client	Server
저장 형식	Text	Object
만료 시점	쿠키 저장 시 설정 (설정 없으면 브라우저 종료 시)	정확한 시점 모름
리소스	클라이언트의 리소스	서버의 리소스
용량 제한	한 도메인 당 20개, 한 쿠키 당 4KB	제한 없음
속도	쿠키에 정보가 있어 비교적 빠름	정보가 서버에 있어 비교적 느림

저장 위치
 - 쿠키: 클라이언트의 웹 브라우저가 지정하는 메모리 또는 하드디스크
 - 세션: 서버의 메모리에 저장

만료 시점
 - 쿠키: 저장할 때 expires 속성을 정의해 무효화시키면 삭제될 수 있도록 유효기간 지정 가능
 - 세션: 클라이언트가 로그아웃하거나, 설정 시간동안 반응이 없으면 해제되어 정확한 시점을 알 수 없음

* 세션과 쿠키의 동작 과정 *
1) 초기 접속 : 클라이언트가 처음으로 웹 서버에 접속한다.
2) 세션 생성 : 서버는 새로운 세션을 생성하고, 고유한 세션 ID를 발급한다.
3) 쿠키 저장 : 서버는 이 세션 ID를 쿠키에 저장하여 클라이언트에게 전송한다.
4) 클라이언트 저장 : 클라이언트는 이 쿠키를 브라우저에 저장한다.
5) 후속 요청 : 이후 클라이언트가 서버에 요청을 보낼 때, 브라우저는 저장된 쿠키를 서버에 자동으로 전송한다.
6) 세션 확인 : 서버는 쿠키에서 세션 ID를 읽어 현재 세션을 확인하고, 해당 세션에 저장된 정보를 사용한다.

// 세션 생성 (존재하지 않으면 새로운 세션 생성)

HttpSession session = request.getSession();
// 세션에 데이터 저장
session.setAttribute("username", "JohnDoe");
session.setAttribute("email", "john.doe@example.com");

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

// 세션에 저장된 데이터 가져오기
String username = (String) session.getAttribute("username");
String email = (String) session.getAttribute("email");

참고 : session.invalidate() 또는 session.removeAttribute("user")를 사용하면 서버 측 세션 데이터는 삭제된다. 하지만 클라이언트 브라우저에는 여전히 세션 ID가 쿠키로 남아 있을 수 있다. 이 경우 클라이언트가 브라우저 쿠키를 통해 다시 요청하면 세션이 없어진 것을 감지할 수 있지만, 쿠키 자체는 클라이언트 브라우저에서 직접 삭제하지 않기 때문에 남아 있는 것처럼 보일 수 있다.

해결 방법: 세션을 삭제한 후, 클라이언트 브라우저에 남아 있는 JSESSIONID 쿠키를 제거해야 한다~~
아래와 같이 쿠키를 삭제하는 코드를 추가하면 클라이언트의 세션 쿠키가 지워집니다:
    // 세션 무효화
    session.invalidate();
    // JSESSIONID 쿠키 삭제
    Cookie cookie = new Cookie("JSESSIONID", null); // 쿠키 이름 설정
    cookie.setMaxAge(0); // 쿠키의 유효 시간 만료
    cookie.setPath("/");     // 쿠키 경로 설정 (애플리케이션 전체)
    response.addCookie(cookie); // 클라이언트에 쿠키 삭제 명령 전달

😊 JWT (Json Web Token)  😊

정보를 비밀리에 전달하거나 인증할 때 주로 사용하는 토큰으로, Json 객체를 이용한다. JWT는 Json Web Token의 약자로 일반적으로 클라이언트와 서버 사이에서 통신할 때 권한을 위해 사용하는 토큰이다. 웹 상에서 정보를 Json형태로 주고 받기 위해 표준규약에 따라 생성한 암호화된 토큰으로 복잡하고 읽을 수 없는 string 형태로 저장되어 있다.

Session의 단점을 일부 해결할 수 있는 기술중 하나로 JWT를 사용한다. JWT는 JSON 객체를 사용하여 두 개체 간에 정보를 안전하게 전송하기 위한 컴팩트한 방식이다. JWT는 일반적으로 세 가지 부분으로 구성된다.
 - 헤더(Header) : 토큰 유형과 서명 알고리즘을 포함한다. JWT에서 사용할 타입과 해시 알고리즘의 종류

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

      alg : Signature에서 사용하는 알고리즘
      typ : 토큰 타입
Signature에서 사용하는 알고리즘은 대표적으로 RS256(공개키/개인키)와 HS256(비밀키(대칭키))가 있다. 이 부분은 auth0(https://auth0.com/docs/get-started/applications/signing-algorithms) 공식 문서에서 확인할 수 있다.

 - 페이로드(Payload) : 클레임(Claims)이라고 하는 인증 정보와 기타 데이터를 포함한다. 서버에서 첨부한 사용자 권한 정보와 사용자의 데이터. "...": "..."(key-value) 한 쌍을 Claim이라고 한다.

      { "sub": "1234567890", "name": "John Doe", "admin": true }

사용자 정보의 한 조각인 클레임(claim)이 들어있다.
    sub : 토큰 제목(subject)
    aud : 토큰 대상자(audience)
    iat : 토큰이 발급된 시각 (issued at)
    exp : 토큰의 만료 시각 (expired)

 - 서명(Signature) : 토큰의 무결성을 검증하기 위해 사용된다. Header, Payload 를 Encode한 이후 Header 에 명시된 해시함수를 적용하고, Private Key로 서명한 전자서명으로  (헤더 + 페이로드)와 서버가 갖고 있는 유일한 key 값을 합친 것을 헤더에서 정의한 알고리즘으로 암호화를 한다.

     HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

Signature는 헤더와 페이로드의 문자열을 합친 후에, 헤더에서 선언한 알고리즘과 key를 이용해 암호한 값이다. Header와 Payload는 단순히 Base64url로 인코딩되어 있어 누구나 쉽게 복호화할 수 있지만, Signature는 key가 없으면 복호화할 수 없다. 이를 통해 보안상 안전하다는 특성을 가질 수 있게 되었다.
header에서 선언한 알고리즘에 따라 key는 개인키가 될 수도 있고 비밀키가 될 수도 있다. 개인키로 서명했다면 공개키로 유효성 검사를 할 수 있고, 비밀키로 서명했다면 비밀키를 가지고 있는 사람만이 암호화 복호화, 유효성 검사를 할 수 있다.

참고 :

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

JWT 명세는 JWT에 암호화 방식으로 서명하는 기능을 제공  https://escapefromcoding.tistory.com/255

JWT  알아가기  https://brunch.co.kr/@jinyoungchoi95/1

*JWT 프로세스 진행 과정 ( https://escapefromcoding.tistory.com/255 )

  - 사용자가 아이디와 비밀번호 혹은 소셜 로그인을 이용하여 서버에 로그인 요청을 보낸다.
  - 서버는 비밀키를 사용해 json 객체를 암호화한 JWT 토큰을 발급한다.
  - JWT를 헤더에 담아 클라이언트에 보낸다.

여기까지가 JWT를 발급받기까지의 (로그인 전)과정이다. 로그인 이후에는 다음과 같은 과정이 이루어진다.

  - 클라이언트는 JWT를 로컬에 저장해놓는다.
  - API 호출을 할 때마다 header에 JWT를 실어 보낸다.
  - 서버는 헤더를 매번 확인하여 사용자가 신뢰할만한지 체크하고, 인증이 되면 API에 대한 응답을 보낸다.

JWT는 기본적으로 '헤더.페이로드.서명'의 형태로 인코딩된다. 

구성 :  Token은 점(.)을 기준으로 구분되어 heaer, payload, signature로 구성 되어 있다.

동작방식 : JWT는 일종의 확인서이다. 사용자가 어떤 웹사이트에 로그인을 해서 성공적으로 Authentication이 이루어지면 서버는 서명된 확인서(JWT)를 사용자에게 제공한다. 그러면 매 번 요청 때마다 JWT를 서버에게 같이 보여주면서 권한을 확인받는 것이다. 서버는 JWT만 확인해 Authorization 하기 때문에 세션 DB에 저장할 필요가 없다.

  1) 사용자 인증: 사용자가 로그인하면 서버는 사용자의 인증 정보를 확인한다.
  2) JWT 생성: 서버는 사용자 정보를 기반으로 JWT를 생성한다. 이 토큰에는 사용자 ID 및 권한과 같은 정보가 포함된다.
  3) 토큰 전송: 생성된 JWT는 클라이언트에게 전송된다. 클라이언트는 이 토큰을 로컬 저장소 또는 쿠키에 저장한다.
  4) 후속 요청: 클라이언트는 이후의 모든 요청에 JWT를 포함한다. 일반적으로 HTTP 헤더의 Authorization 필드에 Bearer 토큰으로 포함된다.
  5) 토큰 검증: 서버는 요청을 받을 때 JWT의 서명을 검증하고, 페이로드의 정보를 확인하여 사용자를 인증한다.

JWT 저장위치 : JWT를 웹에서 저장하기 위해서는 브라우저 저장소에 저장하는 방식과 쿠키에 저장하는 방식을 사용할 수 있다. 로컬 스토리지와 세션 스토리지 같은 브라우저 저장소에 JWT를 저장하면 스크립트 공격(XSS)에 취약해진다. 그리고 쿠키에 저장할 때 http-only 를 사용한다면 HTTPS로만 쿠키가 전달되기 때문에 보안을 강화할 수 있고, CSRF 문제에 대해서는 CSURF 같은 라이브러리를 사용하여 해결할 수 있다.

access token & refresh token  : 이 방식은 토큰들에 유효기간을 주어서 보안을 강화시킨 것이다. access token은 유효기간이 짧은 토큰이고, refresh token은 access token보다 유효기간이 긴 토큰이다.

 - 사용자가 로그인을 하면 서버로부터 access token, refresh token 2개의 토큰을 받는다. 이때 서버는 refresh token을 안전한 저장소에 저장한다.

 - 서버로부터 받은 access token의 유효 기간이 지나지 않은 경우 사용자가 어떤 요청을 보낼 때 access token을 함께 보내고 서버는 유효한 지 확인 후 응답을 보낸다.

 - 서버로부터 받은 access token의 유효 기간이 지난 경우 사용자는 refresh token과 함께 요청을 보내고, 저장소에 저장되어 있던 refresh token과 비교한 후에 유효하다면 새로운 access token과 응답을 함께 보낸다.

https://jwt.io/ 에 들어가 token 값을 입력하면 현재 자신이 사용 중인 jwt 토큰이 어떤 구조로 되어 있는지 쉽게 눈으로 확인할 수 있다. 

JWT 장점

• 데이터의 위변조를 방지할 수 있다.
• JWT는 인증에 필요한 모든 정보를 담고 있기 때문에 인증을 위한 별도의 저장소가 없어도 된다.
• 세션(Stateful)과 다르게 서버는 무상태(StateLess)가 된다.
• 확장성이 우수하다.
• 토큰 기반으로 다른 로그인 시스템에 접근 및 권한 공유가 가능하다.(쿠키와의 차이)
• OAuth의 경우 소셜 계정을 통해서 다른 웹서비스에 로그인 할 수 있다.
• 모바일에서도 잘 동작한다.(세션은 모바일 x)

JWT 단점

• 쿠키/세션과 다르게 토큰의 길이가 길어, 인증 요청이 많아질수록 네트워크 부하가 심해진다.
• Payload 자체는 암호화가 되지 않아 중요한 정보는 담을 수 없다.
• 토큰을 도난 당하면 이에 대한 대처가 어렵다.

Cookie & Session vs JWT  장단점

Cookie와 Session	Cookie만 사용하는 방식보다 보안 향상 서버 쪽에서 Session 통제 가능 네트워크의 부하가 낮음	세션 저장소 사용으로 인한 서버의 부하
JWT	인증을 위한 별도의 저장소가 필요 없다. 빠른 인증 처리 확장성 우수	토큰의 길이가 길수록 네트워크의 부하가 증가, 특정 토큰을 강제로 만료시키기가 어렵다.

JWT와 세션 기반 인증의 비교
^ 무상태 vs 상태 유지
  JWT: 서버는 무상태이다. 클라이언트가 모든 요청에 JWT를 포함하므로 서버는 상태를 유지할 필요가 없다.
  세션: 서버는 상태를 유지한다. 서버는 세션 저장소에 클라이언트의 세션 정보를 저장한다.

^ 확장성
  JWT: 서버 간 확장성이 좋다. 여러 서버에서 JWT를 동일한 비밀키로 검증할 수 있다.
  세션: 상태를 공유해야 하므로 서버 간 확장이 복잡할 수 있다.

^ 보안
  JWT: 토큰이 클라이언트에 저장되므로 XSS 공격에 취약할 수 있다. 토큰 탈취 시 위험하다.
  세션: 세션 ID는 서버에 저장되며, 세션 탈취 공격(CSRF- Cross-Site Request Forgery, 요청 위조 공격 )에 취약할 수 있다.

JWT 생성 서블릿 샘플 ---------------------------------- ----------------------------------

// 사용자 인증 후 JWT 생성
String username = request.getParameter("username");
String SECRET_KEY = "your-256-bit-secret";

// 토큰 생성
String jwt = Jwts.builder()
                .setSubject(username)         // 토큰 용도(제목)
                .setIssuedAt(new Date())      // 생성 시간 설정
                .setExpiration(new Date(System.currentTimeMillis() + 3600000))   // 토큰 만료 시간 설정. 1시간 유효
                .signWith(SignatureAlgorithm.HS256, SECRET_KEY)   // HS256과 Key로 Sign
                .compact();  // 토큰 생성

// 응답에 JWT 포함
response.setContentType("application/json");
response.getWriter().write("{\"token\": \"" + jwt + "\"}");

// 토큰 검증

String token = request.getHeader("Authorization").replace("Bearer ", "");
try {
     Claims claims = Jwts.parser()      // JWT를 파싱하는 JwtParser 객체를 생성
                    .setSigningKey(SECRET_KEY)  // JWT의 서명 검증을 위해 JwtParser에 JWT 생성 때 사용된 비밀 키와 동일한 비밀 키 설정.
                    .parseClaimsJws(token) // 주어진 토큰을 파싱하고, 서명확인하여 JWT의 클레임들을 추출, 토큰 유효성 검사 진행.
                    .getBody();    // Jws 객체에서 페이로드를 추출하여 반환. 페이로드에는 JWT에 포함된 클레임들이 포함되어 있다.
   

     // 파싱 parsing : JWT를 파싱하는 과정은 토큰의 구성을 해석하고, 그 내용을 이해하여 필요한 정보를 추출하는 것.

    String username = claims.getSubject();

    // 응답에 사용자 정보 포함
    response.setContentType("application/json");
    response.getWriter().write("{\"username\": \"" + username + "\"}");
} catch (SignatureException e) {
    // 토큰 검증 실패
    response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
    response.getWriter().write("{\"error\": \"Invalid token\"}");
}

---------------------------------- ---------------------------------- ----------------------------------

*** 샘플 *** 

jwt 실행 라이브러리

jwt_lib.zip

1.93MB

// 고정된 비밀 키 사용 (예제용)  최소 256비트 길이의 비밀 키

String secretKeyString = "mySuperSecretKey12345678901234567890123456789012";

Key secretKey = Keys.hmacShaKeyFor(secretKeyString.getBytes());

고정된 비밀 키( secretKeyString )를 자동으로 생성하려 한다면 기존 소스를 아래와 같은 형태로 변경 해 준다.

InitServlet.java   <== 새로 작성

package pack;
import javax.servlet.*;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.*;
import javax.crypto.SecretKey;
import javax.crypto.KeyGenerator;
import java.util.Base64;
@WebServlet(loadxxxxOnStartup = 1)
public class InitServlet extends HttpServlet {
public void init() throws ServletException {
        try {
            // 비밀 키 생성
            KeyGenerator keyGen = KeyGenerator.getInstance("HmacSHA256");
            keyGen.init(256); // 256비트 길이의 키 생성
            SecretKey secretKey = keyGen.generateKey();
            /*
            실제 비밀 키는 KeyGenerator 객체가 생성한 후 SecretKey 객체로 반환된다. 
            이 SecretKey 객체는 메모리에 존재하며, 파일이나 데이터베이스와 같은 외부 저장소에 
            저장하려면 명시적으로 저장하는 코드를 작성해야 한다.
             */

            // 비밀 키를 Base64로 인코딩하여 문자열로 변환  java.util.Base64
            String encodedKey = Base64.getEncoder().encodeToString(secretKey.getEncoded());
            System.out.println("encodedKey : " + encodedKey);
            // 서블릿 컨텍스트에 비밀 키 저장
            getServletContext().setAttribute("secretKey", encodedKey);
        } catch (Exception e) {
            throw new ServletException("키 생성 오류", e);
        }
    }
}

web.xml에 아래 내용 추가

<servlet>

  <servlet-name>InitServlet</servlet-name>

  <servlet-class>pack.InitServlet</servlet-class>

  <load-on-startup>1</load-on-startup>

</servlet>

login.jsp , success.jsp를 수정

    // 고정된 비밀 키 사용 (예제용)  최소 256비트 길이의 비밀 키
    // String secretKeyString = "mySuperSecretKey12345678901234567890123456789012"; 
    // Key secretKey = Keys.hmacShaKeyFor(secretKeyString.getBytes());
    
    // 위의 작업을 주석 처리하고 아래 내용으로 변경하자.

    // 서블릿 컨텍스트에서 Base64로 인코딩된 비밀 키 가져오기  java.util.Base64
    String encodedKey = (String) getServletContext().getAttribute("secretKey");
    byte[] decodedKey = Base64.getDecoder().decode(encodedKey);
    Key secretKey = Keys.hmacShaKeyFor(decodedKey);

참고 : SpringBoot 프로젝트에서 Security  없이 JWT 만 사용해 작업하고자 한다면 build.gradle에 아래와 같이 jjwt를 추가해 준다. 

implementation 'io.jsonwebtoken:jjwt-api:0.11.2'

runtimeOnly 'io.jsonwebtoken:jjwt-impl:0.11.2'

runtimeOnly 'io.jsonwebtoken:jjwt-jackson:0.11.2'

세션과 DB 연습문제 -----------------------------------------------------------------------

[김보현2]

내가만든 쿠키~~

[yulzzang]

너를 위해 구워찌~