토큰 기반 자격 증명이란?
http는 request 전송후 response를 수신하면 연결이 끊어지는 비연결성(Connectionless)과, request와 response의 상태를 저장하지않는 비상태성(Stateless) 의 특성을 가진다.
- 로그인 인증이 성공적으로 수행되었다 하더라도 서버 측에서는 매번 request를 수신할 때마다 이 request가 인증된 사용자가 보낸 request인지 알 방법이 없다.
- 이런 http 특성으로 사용자의 인증이 성공했을때, 인증된 사용자의 requset의 상태를 유지하기 위한 수단이 세션이다.
세션 기반 자격 증명 방식
서버 측에 인증된 사용자의 정보를 세션 형태로 세션 저장소에 저장하는 방식을 의미함.
✅ 세션 기반 자격 증명의 특징
- 세션은 인증된 사용자 정보를 서버 측 세션 저장소에서 관리.
- 생성된 사용자 세션의 고유 ID인 세션 ID는 클라이언트의 쿠키에 저장되어 request 전송 시, 인증된 사용자인지를 증명하는 수단으로 사용된다.
- 상대적으로 적은 네트워크 트래픽을 사용한다.
- 서버 측에서 세션 정보를 관리하므로 보안성 측면에서 조금 더 유리하다.
- 서버의 확장성 면에서는 세션 불일치 문제가 발생할 가능성이 높다.
- 세션 데이터가 많아질수록 서버의 부담이 가중될 수 있다.
- SSR(Server Side Rendering) 방식의 애플리케이션에 적합한 방식이다.
토큰 기반 자격 증명 방식
- "토큰은 출입 카드와 같다"
애플리케이션에서 사용되는 토큰 역시 인증된 사용자의 자격을 증명하는 동시에 접근 권한을 부여해 접근 권한이 부여된 특정 리소스에만 접근할 수 있게 하는 역할을 한다.
✅ 토큰 기반 자격 증명의 특징
- 토큰에 포함된 인증된 사용자 정보는 서버 측에서 별도의 관리를 하지 않는다.
- 생성된 토큰을 헤더에 포함해 request 전송 시, 인증된 사용자인지를 증명하는 수단으로 사용된다.
- 세션에 비해 상대적으로 많은 네트워크 트래픽을 사용한다.
- 기본적으로 서버 측에서 토큰을 관리하지 않으므로 보안성 측면에서 조금 더 불리하다.
- 인증된 사용자 request의 상태를 유지할 필요가 없기 때문에 서버의 확장성 면에서 유리하고, 세션 불일치 같은 문제가 발생하지 않는다.
- 토큰에 포함되는 사용자 정보는 토큰의 특성상 암호화가 되지 않기 때문에 공격자에게 토큰이 탈취될 경우, 사용자 정보를 그대로 제공하는 셈이 된다. 따라서 민감한 정보는 토큰에 포함하지 말아야 한다.
- 기본적으로 토큰이 만료되기 전까지는 토큰을 무효화시킬 수 없다.
- CSR(Client Side Rendering) 방식의 애플리케이션에 적합한 방식이다.
JWT(JSON Web Token)란?
- 인터넷 표준 인증방식
- 토큰 인증 방식에서 가장 범용적으로 사용됨.
- JSON 포맷의 토큰 정보를 인코딩 후, 인코딩 된 토큰 정보를 Secret Key로 서명(Sign)한 메시지를 Web Token으로써 인증 과정에 사용합니다.
종류
- 액세스 토큰(Access Token)
- 보호된 정보들(사용자의 이메일, 연락처, 사진 등)에 접근할 수 있는 권한 부여에 사용
- 클라이언트가 처음 인증을 받게 될 때(로그인 시), Access Token과 Refresh Token 두 가지를 다 받지만, 실제로 권한을 얻는 데 사용하는 토큰은 Access Token이다.
- 권한 부여에는 액세스 토큰만 있으면 된다.
- 엑세스토큰에는 짧은 유효 기간의 부여가 필수적임
- 리프레시 토큰(Refresh Token)
- 엑세스 토큰의 유효기간이 만료된 경우 새로운 엑세스 토큰을 발급받기 위해 사용한다. > 사용자는 다시 로그인 인증이 필요 없음.
JWT 구조
헤더, 페이로드, 시그니처로 구성
- Header
- 어떤 종류의 토큰인지, 어떤 알고리즘으로 sign할지 정의한다.
- json 포맷 형태로 정의
- 해당 json 객체를 base64 방식으로 인코딩하면 JWT의 첫 번째 부분이 완성된다.
- Payload
- 서버에서 활용할 수 있는 사용자의 정보가 담김( 권한이나 사용자의 이름 등)
- 시그니처를 통해 유효성이 검증되는 정보다.
- 민감한 정보는 담지 않는게 좋다.
- 똑같이 base64로 인코딩
- Signature
- 원하는 비밀 키(Secret Key)와 Header에서 지정한 알고리즘을 사용하여 Header와 Payload에 대해서 단방향 암호화를 수행
- 이렇게 암호화된 메시지는 토큰의 위변조 유무를 검증하는 데 사용
JWT 장단점
장점
- 상태를 유지하지 않고(Stateless), 확장에 용이한(Scalable) 애플리케이션을 구현하기 용이하다.
- 클라이언트가 request를 전송할 때마다 자격 증명 정보를 전송할 필요가 없다.
- 인증을 담당하는 시스템을 다른 플랫폼으로 분리하는 것이 용이하다.
- 권한 부여에 용이하다
단점
- Payload는 디코딩이 용이해 민감한 정보가 노출될 수 있다.
- 토큰의 길이가 길어지면 네트워크에 부하를 줄 수 있다.
- 토큰은 자동으로 삭제되지 않는다.
