JWT (JSON Web Token)는 이름 그대로 JSON 포맷을 사용하여
데이터를 안전하고 간결하게 전송하는 표준 인증 방식이다.
JSON 포맷의 토큰 정보를 인코딩 하고, 인코딩 된 토큰 정보를
비밀키로 서명한 메시지를 Web Token으로 인증 과정에 사용한다.
JWT의 종류
Access Token
사용자의 이메일, 연락처, 사진 등과 같은
보호된 정보에 접근할 수 있는 권한 부여에 사용된다.
클라이언트가 처음 인증을 받으면
Access Token과 Refresh Token을 모두 받지만
실제 권한을 얻는데 사용되는 토큰은 Access Token이다.
사실상 권한을 부여 받을 때는 해당 토큰만 있어도 상관 없지만
해당 토큰을 탈취 당하는 경우에는 탈취한 쪽에서도
해당 토큰을 사용해 권한을 얻을 수 있기 때문에
이 토큰의 유효 기간은 짧게 지정해둔다.
Refresh Token
실제 권한을 얻을 때 사용되지는 않지만
유효 기간이 짧은 Access Token을 재발급 받을 때 사용한다.
별도의 재인증 없이 해당 토큰을 사용하여
Access Token 토큰을 재발급 받을 수 있다는 장점이 있지만
재인증 없이 다시 기존의 권한들을 사용할 수 있다는 것이
보안적으로는 좋지 않기도 하다.
그렇기 때문에 사용자의 편의를 중요하게 생각하면
Refresh Token을 사용하여 재발급을 편하게 할 수도 있고
보안을 더 중요하게 생각하면 해당 토큰을 사용하지 않기도한다.
JWT의 구조
aaaaaa.bbbbbb.cccccc
(Header).(Payload).(Signature)
JWT는 위와 같이 점으로 세 부분으로 구분된다.
JSON 객체를 base64 방식으로 인코딩하면 JWT의 각 부분이 완성된다.
Header
{
"alg": "HS256",
"typ": "JWT"
}
해당 토큰이 어떤 종류의 토큰이고 어떤 알고리즘으로 Sign할지 정의하는 부분이다.
Payload
{
"sub": "someInformation",
"name": "phillip",
"iat": 151623391
}
서버에서 활용 가능한 사용자의 권한이나 정보 같은 데이터 등을 담을 수 있다.
가급적 민감한 정보는 담지 않는 것이 좋다.
Signature
Signature에서 원하는 비밀키와 Header에서 지정한 알고리즘으로
Header와 Payload의 데이터를 단방향 암호화 한다.
암호환된 메시지는 토큰의 위변조 유무 검증에 사용된다.
토큰 기반 인증 절차
- 클라이언트가 서버에 로그인 정보를 담아 요청을 보냄
- 로그인 정보 일치 확인
- 일치하면 암호화된 토큰 생성 (Access Token, Refresh Token)
- Refresh Token은 Access Token을 재발급 하는 용도기 때문에 같은 정보를 담지 않음
- 토큰을 클라이언트에 전송
- 클라이언트는 로컬 저장소, 세션 저장소, 쿠키 등에 토큰을 저장
- 클라이언트는 이후 HTTP Header나 쿠키에 토큰을 담아 요청에 사용
장점
확장에 유리하다
서버가 클라이언트에 대한 정보를 저장하지 않고 검증만 한다.
세션은 여러 대의 서버를 이용한 서비스인 경우에는
서버마다 세션에 대한 정보를 저장하고 있어야 하지만
토큰을 사용하면 그럴 필요가 없다.
클라이언트의 요청마다 인증을 할 필요가 없다
세션 같은 경우는 요청을 전송할 때마다 쿠키에 인증 정보를 포함하지만
토큰은 만료되기 전까지 한 번의 인증만으로 충분하다.
인증 시스템을 서버와 분리할 수 있다
구글이나 카카오 같은 다른 플랫폼의 자격 증명 정보로 인증하는 것이 가능하다.
토큰 생성용 서버를 만들거나 다른 플랫폼에 토큰 관련 작업을 맡기는 등
다양한 활용이 가능하다.
권한 부여에 용이하다
Payload에 사용자의 권한 정보를 포함하는 것이 용이하다.
단점
디코딩이 용이하다
Payload는 base64로 인코딩 되어 디코딩하기도 쉽기 때문에
민감한 정보는 포함하지 않는 것이 좋다.
토큰의 길이가 네트워크에 부하를 준다
토큰에 저장하는 데이터가 많아질수록 토큰의 길이가 늘어나는데
요청을 전송할 때마다 토큰을 전송하기 때문에
길이가 긴 토큰을 전송하는 것은 네트워크에 부하를 준다.
자동으로 삭제되지 않는다
한 번 생성된 토큰은 자동으로 삭제되지 않아서 만료 시간을 반드시 지정해야 한다.
너무 길지도 짧지도 않은 적당한 기간을 지정하는 것이 좋다.
'Back-End > Security' 카테고리의 다른 글
OAuth 2.0 (0) | 2023.07.17 |
---|---|
[스프링 시큐리티] 스프링 시큐리티 구조 분석 - 1 (0) | 2023.07.16 |
토큰 기반 자격 증명 (0) | 2023.07.11 |
[스프링 시큐리티] 접근 제어 표현식 (0) | 2023.07.11 |
[스프링 시큐리티] 인증 및 인가 처리 흐름 (0) | 2023.07.11 |