서버가 클라이언트를 식별하고 정보를 유지하기 위해 사용하는 인증 방식에는 쿠키, 세션 그리고 토큰이 있다
사용자가 어떠한 웹 사이트를 방문할 경우, 그 사이트가 사용하고 있는 서버에서 사용자의 컴퓨터에 저장하는 작은 기록 정보 파일이다
세션은 클라이언트의 인증 정보를 쿠키가 아닌 서버 측에 저장하고 관리한다
클라이언트가 서버에 접속을 하면 서버에서 해당 클라이언트에게 인증되었다는 의미로 토큰을 부여한다
요청을 보낼 때, 서버에서는 클라이언트로부터 받은 토큰을 서버에서 제공한 토큰과의 일치 여부를 체크하여 인증 과정을 처리하게 된다
인증에 필요한 정보들을 암호화시킨 JSON 토큰을 의미한다
JWT는 . 을 구분자로 나누어지는 세 가지 문자열 Header, Payload, Signature
의 조합이다
주로 클라이언트의 고유 ID 값 및 유효 기간 등 서버와 클라이언트가 주고받는 시스템에서 실제로 사용될 정보에 대한 내용을 담고 있는 영역이다
페이로드는 정해진 데이터 타입은 없지만, 대표적으로 Registered claims, Public claims, Private claims 세 가지로 나뉜다
- Registed claims : 미리 정의된 클레임
iss (Issuer)_토큰 발급자
sub (Subject)_토큰 제목, 토큰에서 사용자에 대한 식별값이 됨
aud (Audience) : 토큰 대상자
exp (Expiration Time)_토큰 만료 시간
nbf (Not Before)_토큰 활성 날짜 (이 날짜 이전의 토큰은 활성화 되지 않음을 보장)
iat (Issued At)_토큰 발급 시간
jti (JWT Id)_JWT 토큰 식별자 (issuer가 여러명일 때 이를 구분하기 위한 값)
- Public claims : 사용자가 정의할 수 있는 클레임 공개용 정보 전달을 위해 사용
(공개 클레임들은 충돌이 방지된 (collision-resistant) 이름을 가지고 있어야 하고, 충돌을 방지하기 위해서 클레임 이름을 URI 형식으로 한다)
https://velog.io/@lheun : true
- Private claims : 해당하는 당사자들 간에 정보를 공유하기 위해 만들어진 사용자 지정 클레임 외부에 공개되도 상관없지만 해당 유저를 특정할 수 있는 정보들을 담는다
username : lheun
꼭 모두 포함해야하는 것이 아니고, 상황에 따라 해당 서버가 가져야할 인증 체계에 따라 사용하면 된다
토큰 기반 시스템의 구현 방식은 시스템마다 크고작은 차이가 있겠지만, 대략적으로 보면 다음과 같다
클라이언트는 서버로부터 받은 JWT를 로컬 스토리지에 저장한다 (쿠키나 다른 곳에 저장할 수도 있음)
클라이언트가 서버에 요청할 때 Authorization header에 Access Token을 담아서 보낸다
서버는 토큰 안에 들어있는 정보가 무엇인지 아는게 중요한 것이 아니라 해당 토큰이 유효한 토큰인지 확인하는 것이 중요하다
ex) User JWT : 🔴(Header) + 🟡(Payload) + 🟠(Signature)
JWT는 토큰에 대한 기본 정보와 전달할 정보 및 토큰이 검증됬음을 증명하는 서명 등 필요한 모든 정보를 자체적으로 지니고 있다
클라이언트 인증 정보를 저장하는 세션과 다르게, 서버는 무상태(StateLess)가 된다
확장성이 우수하다
토큰 기반으로 다른 로그인 시스템에 접근 및 권한 공유가 가능하다 (쿠키와의 차이)
OAuth의 경우 Facebook, Google 등 소셜 계정을 이용하여 다른 웹서비스에서도 로그인을 할 수 있다
모바일 어플리케이션 환경에서도 잘 동작한다 (모바일은 세션 사용 불가능)
쿠키/세션과 다르게 JWT는 토큰의 길이가 길어, 인증 요청이 많아질수록 네트워크 부하가 심해진다
Payload 자체는 암호화되지 않기 때문에 유저의 중요한 정보는 담을 수 없다 (비밀번호 등)
JWT의 넓은 범용성, 무결성 보장, 필요한 값을 자체 포함할 수 있는 성질 때문에 많은 곳에서 JWT를 사용하고 있다
이전의 Session 방식이나 Cookie방식의 인가(Authenticate)를 사용하든 JWT를 사용하든 각각 장단점은 존재한다
장점 | 단점 | |
---|---|---|
쿠키(Cookie) & 세션(Session) | Cookie만 사용하는 방식보다 보안 향상 서버 쪽에서 Session 통제 가능 네트워크 부하 낮음 | 세션 저장소 사용으로 인한 서버 부하 |
JWT | 인증을 위한 별도의 저장소가 필요 없음 별도의 I/O 작업 없는 빠른 인증 처리 확장성이 우수함 | 토큰의 길이가 늘어날수록 네트워크 부하 특정 토큰을 강제로 만료시키기 어려움 |
[WEB] 📚 JWT 토큰 인증 이란? - 💯 이해하기 쉽게 정리