Spring Security 적용기 (3) JWT(JSON Web Tokens) 개념

이전 시간에는 Spring Security란 무엇이며, 어떻게 적용 가능한지에 대해 알아보았다. 

• 2024.04.22 - [Study/Java] - Spring Security 적용기 (1) Spring Security란?
• 2024.04.25 - [Study/Java] - Spring Security 적용기 (2) Spring Security Configuration

필자는 본 프로젝트에서 jwt를 활용한 인증방식을 사용하여 로그인 기능을 구현하고자 한다. 

jwt 설정에 들어가기 전에 jwt란 무엇인지 먼저 살펴보고자 한다. 

 

---

JWT(JSON Web Token)이란?

JWT(JSON Web Token)은  인증에 필요한 정보들을 암호화시킨 JSON 토큰을 의미한다.

JWT는 HMAC 알고리즘을 사용하여 비밀키로 서명하거나 RSA 또는 ECDSA를 사용하여 공개/개인키 쌍을 사용해 서명할 수 있다. 

 

HMAC 알고리즘에 대한 내용은 이전에 OTP  관련 포스팅에서 확인할 수 있다. 

https://danyoujeong.tistory.com/223

OTP의 동작 원리, HOTP와 TOTP 이해하기

---

JWT의 활용

JWT는 다음과 같은 상황에서 대표적으로 사용된다. 

 

1. 인증(Authorization)

2. 정보교환(Information Exchange)

 

1번의 인증(Authorization)은 JWT를 사용하는 가장 일반적인 상황이다. 

사용자가 로그인한 후 각 후속 요청, 예를 들면 주문/결제 등의 요청 헤더에 JWT가 포함되어 해당 토큰으로 허용된 경로, 서비스에 엑세스 할 수 있다. 

 

2번의 정보교환은 관계자 간 정보를 안전하게 전송할 수 있는 좋은 방법 중 하나이다. 

JWT는 위의 정의에서 언급했듯이 공개/개인키를 사용하여 서명할 수 있기 때문에 무결성을 검증할 수 있다. 

---

JWT 구조

JWT 는 ( . )을 기준으로 3 부분으로 나누어진다. 

1. Header

2. Payload

3. Signature

 

xxxxx.yyyyy.zzzzz

 

Header

Header에는 2가지 데이터로 구성된다. 

첫번째는 JWT와 같은 token의 타입을 명시하고, 두번째는 HMAC, SHA256, RSA와 같은 서명 알고리즘을 명시한다.

{
	"alg" : "HS256",
	"typ" : "JWT"
}

 

그리고 이 JSON은 Base64Url 인코딩되어 JWT의 첫번째 부분을 형성한다. 

 

Base64Url 인코딩
URL에서 안전한 문자 집합을 사용하여 데이터를 인코딩하는 방법
일반적인 Base64  인코딩에서는 '+', '/'와 같은 문자를 사용하지만 이는 URL에서 안전하지 않을 수 있다. 
따라서 '+'는 '-'로, '/'는 '_'로 대체하고, '='을 생략하여 URL에서 안전한 문자열로 인코딩하는 방식이다. 

 

Payload

Payload는 클레임을 포함하는 부분이다. 클레임(Claim)은 이름, 등급과 같은 개체(일반적으로 사용자)에 대한 데이터를 말한다. 

클레임은 3가지 종류가 있다. 

 

1. 등록된 클레임 : 의무적이지는 않지만 유용하고 상호 운용 가능한 클레임 집합. 발행자(iss), 만료 시간(exp), 주체(sub) 등을 의미한다. 클레임 이름은 JWT가 간결하게 되도록 세 글자로만 되어 있다.  

2. 공개 클레임 : JWT를 사용하는 사람이 자유롭게 정의할 수 있는 클레임이다. 

3. 비공개 클레임 : 사용자들이 사용에 동의한 정보를 공유하기 위해 만들어진 사용자 정의 클레임이다. 

 

{
	"sub": "1234567890",
	"name": "John Doe",
	"admin": true
}

 

 

페이로드는 Base64Url 인코딩되어 JSON Web Token의 두번째 부분을 형성한다.

서명된 토큰의 경우 페이로드의 정보는 변조를 방지하도록 보호되지만 누구나 읽을 수 있다. 

따라서 페이로드나 헤더 요소에 비밀 정보 혹은 암호화되지 않은 데이터를 넣어서는 안된다.

 

Signature

서명 부분을 생성하기 위해서는 인코딩된 헤더, 인코딩된 페이로드, 헤더에서 지정된 알고리즘을 가져와야 한다. 그 후 이를 서명한다. 

예를 들어 HMAC SHA256  알로리즘을 사용하면 아래와 같이 서명이 생성된다. 

HMACSHA256(
	base64UrlEncode(header) + "." +
	base64UrlEncode(payload),
	secret
)

 

서명(Signature)는 해당 메시지가 중간에 변경되지 않았음(데이터 무결성)을 확인하는 데 사용되며, 비공개키로 서명된 토큰의 경우 JWT의 발신자가 자신이 말한대로임을 검증할 수도 있다. 

 

아래의 사진은 JWT 구조를 보여준다. 

첫번째줄은 헤더를 Base64Url 인코딩한 부분이며,

두번째, 세번째 줄은 페이로드를 인코딩한 부분,

마지막줄은 아래 HMACSHA256과 같이 서명된 부분이다. 

HMACSHA256(
	base64UrlEncode(header) + "." +
	base64UrlEncode(payload),
	secret
)

---

JWT 작동 방식

인증 과정에서 사용자가 자격증명으로 사용하여 성공적으로 로그인하면 JSON Web Token이 반환된다. 

사용자가 보호된 경로 혹은 리소스에 접근하려는 경우 Bearer 스키마를 사용하여 Authorization 헤더에 JWT를 보내야 한다. 헤더의 내용은 아래와 같다. 

 

Authorization: Bearer <token>

 

서버는 Authorization 헤더에 유효한 JWT를 확인하고, 유효한 JWT가 존재하는 경우 보호된 리소스에 사용자가 접근할 수 있도록 한다. 

 

HTTP 헤더를 통해 JWT을 전송할 때 주의할 점은 너무 큰 데이터를 전송하면 안된다는 것이다. 일부 서버에서는 헤더에 8KB 이상의 데이터를 보내는 것을 수락하지 않는다. 이와 같이 JWT에 너무 많은 정보를 포함하면 안된다. 또한, JWT는 Authorization 헤더에 전송되는 경우 쿠키를 사용하지 않으므로 CORS 문제가 일어나지 않는다. 

 

 

1. 클라이언트가 Authorization 서버에 인가를 요청한다.
2. 권한이 부여된 Authorization 서버는 클라이언트에 엑세스 토큰을 반환한다.
3. 클라이언트는 Authorization 서버로 부터 받은 엑세스 토큰을 사용하여 보호된 리소스(API 등)에 접근할 수 있다. 

---

JWT의 장단점

장점

1. Header와 Payload의 데이터를 Secret 혹은 비밀키/공개키로 서명하므로 데이터 위변조를 막을 수 있다. 

2. 인증 정보에 대한 별도의 저장소가 필요없다. 

3. JWT는 토큰에 대한 기본 정보와 전달할 정보 및 토큰이 검증되었음을 증명하는 서명 등 필요한 모든 정보를 자체적으로 지니고 있다. 

4. 클라이언트 인증 정보를 저장하는 세션과 다르게 서버는 무상태(Stateless)가 되어 서버 확장성이 우수해질 수 있다. 

5. 토큰 기반으로 다른 로그인 시스템에 접근 및 권한 공유가 가능하다. 

6. OAuth의 경우 Facebook, Google 등 소셜 계정을 이용하여 다른 웹서비스에서도 로그인을 할 수 있다. 

7. 모바일 어플리케이션 환경에서도 잘 동작한다. (모바일은 세션 사용 불가능) 

 

단점

1. Self-contained : 토큰 자체에 정보를 담고 있으므로 양날의 검이 될 수 있다. 

2. 토큰 길이 : 토큰의 Payload에 3종류의 클레임을 저장하기 때문에 정보가 많아질수록 토큰의 길이가 늘어나 네트워크에 부하를 줄 수 있다. 

3. Payload 인코딩 : payload 자체는 암호화 된 것이 아니라 Base64로 인코딩된이므로 중간에 Payload를 탈취하여 디코딩하면 데이터를 볼 수 있으므로 payload에 중요 데이터를 넣으면 안된다. 

4. Store Token : stateless 특징을 가지므로 토큰은 클라이언트 측에서 관리하고 저장한다. 때문에 토큰 자체를 탈취 당하면 대처하기 어렵다. 

---

Refresh Token의 필요성

JWT를 이용해 개발을 하다 보면 OAuth 기반의 인증 체계(카카오, 구글 등)에서 Refresh Token을 사용하는 것을 볼 수 있다. Refresh Token을 사용하는 이유가 뭘까? 이는 JWT의 단점에서 살펴보았던 Store Token 특징과 관계가 있다. 

 

엑세스 토큰을 오랫동안 사용하면 해커가 이를 도용하여 악용할 수 있다. 따라서 엑세스 토큰을 장시간 사용하는 것은 권장하지 않는다. 그러나 그렇다고 엑세스 토큰을 너무 자주 발행하게 되면 사용자는 로그인을 자주해야 하므로 불편하다. 이러한 문제의 해결책으로 나타난 것이 'Refresh Token'이다. 

 

리프레시 토큰은 엑세스 토큰과 똑같은 형태의 JWT이다. 이 리프레시 토큰은 엑세스 토큰을 얻는데 사용된다. 

엑세스 토큰이 만료되면 리프레시 토큰을 사용하여 인증 컨트롤러부터 새로운 엑세스 토큰을 얻을 수 있다. 리프레시 토큰은 일반적으로 엑세스 토큰보다 수명이 훨씬 길다. 반면, 엑세스 토큰은 수명이 짧다. 

 

 

 

1. 사용자가 로그인을 하면 인증 서버에서 엑세스 토큰과 리프레시 토큰을 발급한다. 일반적으로 DB에 리프레시 토큰을 저장해둔다. 

2. 사용자는 리프레시 토큰을 안전한 저장소에 저장한 후, 액세스 토큰을 헤더에 실어 요청을 보낸다. 

3. 서번튼 엑세스 토큰을 검증하여 접근을 허용한다. 

4. 시간이 지나 엑세스 토큰이 만료된다. 

5. 사용자는 이전과 동일하게 엑세스 토큰을 헤더에 실어 요청을 보낸다. 

6. 서버는 엑세스 토큰이 만료되었음을 확인하고 권한 없음 신호를 보낸다. 

7. 사용자는 리프레시 토큰과 엑세스 토큰을 함께 서버로 보낸다. 

8. 서버는 엑세스 토큰이 조작되지 않았는지 확인 후 리프레시 토큰과 사용자에 DB에 저장되어 있던 리프레시 토큰을 비교한다. 토큰이 동일하고 유효기간도 지나지 않았다면 새로원 엑세스 토큰을 발급한다. 

9. 사용자는 새로운 액세스 토큰을 헤더에 실어 다시 API 요청을 진행한다. 

 

토큰 만료 유형 4가지와 그에 따른 재발급 방법
1. access token과 refresh token 모두 만료된 경우 
    - 에러 발생, 재로그인하여 둘 다 새로 발급
2. access token은 만료됐지만, refresh token은 유효한 경우
    - refresh token을 검증하여 access token 재발급
    - DB에 저장된 refresh token 정보와 클라이언트가 보낸 refresh token 비교
3. access token은 유효하지만, refresh token은 만료된 경우
    - access token 검증하여 refresh token 재발급
    - access token이 유효하다는 것은 이미 인증된 것이므로 바로 refresh token 재발급
4. access token과 refresh token 모두 유효한 경우 
    - 정상 처리

---

참고자료

https://jwt.io/introduction

JWT.IO

https://inpa.tistory.com/entry/WEB-%F0%9F%93%9A-JWTjson-web-token-%EB%9E%80-%F0%9F%92%AF-%EC%A0%95%EB%A6%AC#jwt_json_web_token_%EC%9D%B4%EB%9E%80

🌐 JWT 토큰 인증 이란? (쿠키 vs 세션 vs 토큰)

https://medium.com/@chauhanshubham19765/jwt-refresh-token-61823e888bc7

JWT Refresh Token