토큰 기반 자격 증명
세션(Session)
비 연결성(Connectionless) 과 비 상태성(Stateless) 특성을 가지고 있는 HTTP특성으로 인해 사용자 인증이 성공적으로 이루어졌을 때, 인증된 사용자의 요청 상태를 유지하기 위한 수단 중 하나
세션 기반 자격 증명 방식
- 서버 측에 인증된 사용자 정보를 세션 형태로 세션 저장소에 저장하는 방식
- 클라이언트 측에서 서버 측의 리소스를 요청하면 서버측에서는 정보를 주어도 괜찮은 클라이언트인지를 확인하기 위해 서버 측 세션 저장소에 저장된 세션 정보와 일치하는지 확인하는 방식
세션 기반 자격 증명의 특징
- 세션은 인증된 사용자 정보를 서버 측 세션 저장소에서 관리
- 생성된 사용자의 세션ID는 클라이언트의 쿠키에 저장되어 요청 전송 시 인증된 사용자인지 증명하는 수단
- 세션 ID만 클라이언트에서 사용하기 때문에 상대적으로 적은 네트워크 트래픽 사용
- 서버 측에서 세션정보를 관리하기 때문에 보안성 측면에서 조금 더 유리
- 서버의 확장성 측면에서 세션의 불일치 문제를 발생할 가능성 높음
- 세션 데이터가 많아질 수록 서버의 부담 가중
- SSR(Server Side Rendering) 방식의 애플리케이션에 적합한 방식
토큰 기반 자격 증명 방식
- 애플리케이션에서 사용되는 토큰은 인증된 사용자의 자격을 증명하는 동시에 접근 권한을 부여해 접근 권한이 부여된 특정 리소스에만 접근 할 수 있도록 하는 역할
토큰 기반 자격 증명의 특징
- 토큰에 포함된 인증된 사용자의 정보는 서버 측에서 별도의 관리를 하지 않음
- 생성된 토큰을 헤더에 포함한 요청 전송 시 인증된 사용자인지 증명하는 수단으로 사용
- 토큰 내에 인증된 사용자의 정보를 포함하기 때문에 세션에 비해 상대적으로 많은 네트워크 트래픽을 사용
- 서버 측에서 토큰을 관리하지 않기 때문에 보안성 측면에서 상대적으로 불리
- 서버의 확장성면에서 유리하고 세션 불일치와 같은 문제가 발생하지 않음
- 토큰이 만료되기 전까지 토큰을 무효화 시킬 수 없음
- CSR(Client Side Rendering) 방식의 애플리케이션에 적합한 방식
JWT (JSON Web Token) 란?
- JWT는 데이터를 안전하고 간결하게 전송하기 위해 고안된 인터넷 표준 인증 방식
- JSON 포맷의 토큰 정보를 인코딩 한 후, 인코딩 된 토큰 정보를 SecretKey로 서명한 WebToken 으로써 인증 과정에 사용
JWT의 종류
- 액세스 토큰(Access Token)
- 보호된 정보들(사용자의 이메일, 연락처, 사진 등)에 접근 할 수 있는 권한 부여에 사용
- 리프레시 토큰(Refresh Token)
- 액세스 토큰의 유효기간이 만료되면 리프레시 토큰을 이용해 새로운 액세스 토큰을 발급 받음 -> 다시 사용자 로그인 인증을 받을 필요 없음
클라이언트가 처음 인증을 받을 때, 액세스 토큰과 리프레시 토큰 모두 발급 받지만 실제로 권한을 얻는데 사용되는 토큰은 액세스 토큰
JWT 구조
- JWT는
.으로 나누어진 세부분으로 이루어져있음
- Header
{
"alg": "HS256",
"typ": "JWT"
}- Header는 이것이 어떤 종류의 토큰인지, 어떤 알고리즘으로 Sign할지 정의
- base64 방식으로 인코딩하면 JWT의 첫번째 블록이 완성
- Payload
- 서버에서 활용할 수 있는 사용자 정보를 담고있음
- 민감한 정보를 담지 않는 것이 좋음
{
"sub": "someInformation",
"name": "phillip",
"iat": 151623391
}- SON 객체를 base64로 인코딩하면 JWT의 두 번째 블록이 완성
- Signature
- 원하는 비밀키와 Header에서 지정한 알고리즘을 사용하여 Header와 Payload에 대해서 단방향 암호화를 수행
- 암호화된 메세지는 토큰의 위변조 유무를 검사하는데 사용
HMACSHA256(base64UrlEncode(header) + '.' + base64UrlEncode(payload), secret);토큰 기반 인증 절차
JWT의 장단점
장점
- 상태를 유지하지 않고(Stateless), 확장에 용이한(Scalable) 애플리케이션을 구현하기에 용이
- 서버는 클라이언트 정보를 저장할 필요가 없음
- 클라이언트는 요청을 전송할때 마다 토큰을 헤더에 포함하면 됨
- 클라이언트가 요청을 전송할 때 마다 자격 증명 정보를 전송할 필요가 없음
- HTTP Basic 같은 인증 방식은 요청을 전송할 때 마다 자격 증명 정보를 포함 해야 하지만 JWT의 경우 토큰이 만료되기 전까지는 한번의 인증만 수행하면 됨
- 인증을 담당하는 시스템을 다른 플랫폼으로 분리하는 것이 용이
- 사용자의 자격 증명 정보를 직접 관리 하지 않고, GitHub,Google 등 다른 플랫폼의 자격 증명 정보로 인증하는 것이 가능
- 토큰 생성용 서버를 만들거나, 다른 회사에게 토큰 관련 작업을 맡기는 등 다양한 활용이 가능
- 권한 부여에 용이
단점
- Payload는 디코딩이 용이
- base64로 인코딩 되기 때문에 토큰을 탈취하여 디코딩하면 토큰 생성 시 저장한 데이터를 확인하는 것이 가능
- 따라서 민감한 정보를 담는 것은 피해야함
- 토큰의 길이가 길어지면 네트워크에 부하를 줄 수 있음
- 토큰에 저장하는 정보가 많아질 수록 토큰의 길이가 길어짐
- 요청을 전송 할 때마다 길이가 긴 토큰을 같이 전송하면 네트워크에 부하를 줄 수 있음
- 토큰은 자동으로 삭제되지 않음
- 한번 생성된 토큰은 자동으로 삭제되지 않기 때문에 반드시 토큰 만료시간을 추가해야 함
- 토큰이 탈취된 경우 만료될때 까지 사용이 가능하므로 만료시간을 너무 길게 설정하지 않아야 함
