서버가 클라이언트의 인증을 확인하는 방식에는 대표적으로 세션, 토큰 ,쿠키 방식이 있다.
오늘은 JWT에 대해 알아보도록 하자
JWT (JSON Web Token)
인증에 필요한 정보들을 암호화시킨 JSON 토큰이다.
JWT는 헤더, 페이로드, 시그니처로 이루어져있다.
각 부분을 base64로 인코딩해서 .(마침표)로 연결하면 우리가 아는 JWT가 된다.
1. 헤더(Header)
- alg : 서명 암호화 알고리즘 (서명 값을 만드는데 사용되는 알고리즘)
헤더 + 페이로드 + 서버의 시크릿키를 해당 암호화 알고리즘에 넣고 돌리면 서명 값이 나온다.
- typ : 토큰 유형 (언제나 JWT가 들어간다.)
2. 내용(Payload)
다음은 Base64로 디코딩해서 나타는 JSON형식 정보들이다.
토큰에 담긴 사용자 정보 등에 담긴 정보들을 Claim이라고 한다.
3. 서명(Signature)
헤더와 페이로드를 .을 구분자로 합친 문자열을 서명한 값이다.
Signature은 헤더의 alg의 알고리즘과 비밀키를 이용해 생성한다.
예시
유저가 로그인 되었다면 JWT 토큰을 발급해준다.
JWT는 발급될때 서버의 시크릿 키와 페이로드와 헤더를 입력으로 넣으면 특정 알고리즘에 의해 서명이 만들어질 것이다.
그리고 유저에게 이를 넘겨주고, 서버는 완전히 잊어버린다. (서버는 시크릿 키만 갖고 있으면 된다.)
유저가 JWT를 이용해 서버에 요청 시에 서버는 토큰의 유효성을 어떻게 검증할까?
서버는 유저가 갖고 있는 JWT의 헤더와 페이로드를 이용해 자신의 시크릿키로 서명 값을 계산해본다.
만약 요청된 유저의 JWT 서명값과 서버가 계산한 서명값이 일치한다면 이는 유효한 토큰으로 간주된다.
페이로드의 정보가 누군가에 의해 조금이라도 수정되었다면 당연히 틀릴 것이다.
그러면 정보를 조작한 사용자이거나 해커로 간주 되어서 거부된다.
서명값(Signature, 3번)과 계산 값이 일치하고 유효기간도 지나지 않았다면 그 사용자는 로그인 된 사용자로서 인가 받게 된다.
Session vs JWT ?
Session의 단점
서버에 부담이 크게 간다.
사용자가 로그인 할때마다 세션 저장소(서버나 DB)에 세션 ID가 저장되기 때문에 사용자가 많은 서버라면 부담이 간다.
또한 매 요청마다 서버는 DB에 접근 해야 한다.
Session의 작동방식
1. 사용자 로그인 → 서버는 세션 ID를 생성하고, 세션 저장소에 사용자 정보(userId, username..)를 저장한다.
- 메모리, DB, Redis 등에 저장될 수 있다.
2.브라우저는 세션 ID를 쿠키에 저장하여 요청을 보낸다.
3.서버는 요청마다 세션 ID를 확인하고, 세션 저장소에서 해당 데이터를 찾아 사용자 인증을 처리한다.
JWT의 장점
1. 서버에 세션을 저장할 필요가 없다. 그냥 토큰을 서버가 검증해서 올바르다면 안에 내용을 꺼내서 쓰면 된다.
그래서 서버의 부담을 줄여준다. (사용자 정보를 세션처럼 서버에 저장해줄 필요가 없음)
2. 토큰에 특정 권한을 심을 수 있다.
JWT의 단점
1. 많은 양의 data를 JWT에 저장하면 토큰의 크기가 커져 네트워크 부하가 발생할 수 있다.
2. 토큰이 한번 탈취당하면 대처가 어렵다. -> refreshToken 고려
3. 토큰의 페이로드는 디코딩이 가능하기 때문에 민감한 정보는 넣지 말아야 한다.
이를 정리해보면
로그인 성공 시
세션 - 세션 DB에 접근해 유저 정보를 저장하고 세션 ID 반환 (key : 세션ID, value:유저정보)
JWT - 토큰만 발급하면 된다.
로그인 후 요청
세션 - 늘 세션 ID가 유효한지 DB 조회
JWT - DB의 조회 필요 없이, 토큰만 검증하면 된다. (서명일치여부, 유효기간..)
로그아웃
세션 - 세션 DB에 해당 세션 ID에 해당하는 레코드 삭제
JWT - DB 블랙리스트에서 로그아웃한 계정의 Token 저장
'Spring > JWT' 카테고리의 다른 글
| [Spring] Spring Security 개념과 동작 (0) | 2025.02.28 |
|---|