JWT토큰을 알아보기 위해 쿠키,세션,토큰에 대해서 알아보았습니다.
그러면 마지막으로 JWT토큰에 대해서 알아보겠습니다.
JWT토큰
JWT(JSON Web Token)은 웹에서 사용되는 인증 및 인가에 필요한 정보를 암호화하여 JSON형식의 토큰으로 안전하게 전송합니다.
JWT토큰 구조
JWT는 일반적으로 아래의 구조를 따릅니다.
xxxxx.yyyyy.zzzzz
"."을 기준으로 왼쪽부터 Header,Payload,Signature를 의미합니다.
Header
일반적으로 2가지 정보를 담고있습니다.
{
"alg" : Signature을 만드는데 사용한 알고리즘 정보 (ex,"HS256")
"typ" : Token의 타입(ex, "JWT")
}Payload
인증에 필요한 실질적인 정보들 가지고 있습니다.(Claim 이 담겨있다.)
즉, 서버와 클라이언트가 주고받는 시스템에서 실제로 사용될 정보에 대한 내용을 담고 있는 섹션이다.
(참고)
Claim : Payload에 담긴 정보 하나 하나를 Claim이고, key-value 형식으로 이루어진
한 쌍의 정보를 말한다.
그리고 총 3가지 종류의 Claim이 존재합니다.
Registered Claims
: JWT 표준으로 지정된 Claim 입니다. 총 7가지의 Registered Claim이 존재하며, 해당 Claim을 무조건 전부 사용해야 되는 것은 아니고 적절히 상황게 맞게 사용하면 됩니다.
- iss: 토큰 발급자
- sub: 토큰 제목
- aud: 토큰 대상자
- exp: 토큰 만료시간
- iat: 토큰 발급 시간
- nbf: 토큰 활성화 시간
- jti: JWT의 고유 식별자
Public Claims
: 사용자가 정의할 수 있는 클레임 공개용 정보 전달을 위해 사용하면 됩니다.
그러나 기존에 이미 등록되어 있는 Claims와 충돌을 방지하려면 IANA JSON Web Token 레지스트를 참고하거나 UUID, OID, 도메인 이름 등을 사용해야 합니다.
Private Claims
: 정보를 공유하기 위해 만들어진 사용자 지정 클레임입니다. 외부에 공개되도 상관없지만
해당 유저를 특정할 수 있는 정보들을 담는다
<예시>
{
"sub": "1234567890" //Registered Claims
"exp": "1695782400" //Registered Claims
"https://velog.io/@trtw9889": true, //Public Claims
"user_id" : 12345123 //Private Claims
}Signature
: 문자 그대로 JWT의 서명 부분이고 토큰이 유효하고 변조되지 않았음을
확인하기 위해 사용됩니다.
Header의 인코딩된 내용과 Payload의 인코딩된 내용을 더한 뒤에 Secret Key와 알고리즘을 이용하여 암호 된 값을 나타냅니다.
서버에서 관리하고 있는 Secret Key가 아닌 다른 Key로 JWT를 발급한다면 Signature가 달라지기 때문에 해당 JWT는 신뢰할 수 없는 토큰입니다.
위의 링크에 접속하시면 직접 JWT토큰을 생성해보실 수 있습니다.
Access Token & Refresh Token
JWT토큰도 탈취의 위험성이 있기 때문에 Access Token과 Refresh Token을 사용하여 역할을 나누어 사용합니다.
Access Token
: 클라이언트가 사용자의 정보를 담고 있는 특별한 토큰입니다. 클라이언트가 서버에 요청을 보낼 때, 서버는 이 Access Token 안에 있는 정보를 사용하여 해당 사용자에게 맞는 응답을 생성합니다.
다만, 이러한 토큰은 짧은 시간 동안만 유효하며, 주로 인증된 사용자의 신원을 확인하는 데 사용됩니다.
Refresh Token
: Refresh Token은 Access Token을 갱신하는 데 사용됩니다. Access Token의 유효 기간이 만료되면, 클라이언트 애플리케이션은 Refresh Token을 사용하여 새로운 Access Token을 발급받을 수 있습니다.
Access Token보다 오랜 시간 동안 유효하고 민감한 정보를 포함하고 있으므로 안전하게 보호되어야 합니다. 누군가가 Refresh Token을 획득하면 그 사람이 사용자의 이름으로 새로운 Access Token을 얻을 수 있기 때문입니다.
즉, Access Token은 접근을 허용하는 역할을 하고, Refresh Token은 Access Token을 갱신하여 사용자의 인증을 유지하는 역할을 합니다.
Access Token & Refresh Token 인증과정
<추가설명>
- 3~4번 : 로그인이 완료되면 Access Token, Refresh Token을 발급합니다.
이때, 일반적으로 회원DB에 Refresh Token을 저장해둡니다. - 5,9번 : 5,9번은 모두 Access Token을 헤더에 실어 요청을 보냅니다.
- 10~11번 : 서버는 Access Token이 만료됨을 확인하고 권한없음을 신호로 보냅니다.
- 12번 : 사용자는 Refresh Token과 Access Token을 함께 서버로 보냅니다.
- 13번 : 서버는 받은 Access Token이 조작되지 않았는지 확인한후, Refresh Token과 사용자의 DB에 저장되어 있던 Refresh Token을 비교합니다.
Refresh Token이 동일하고 유효기간도 지나지 않았다면 새로운 Access Token을 발급해줍니다.
<참고한 자료>
