JWT는 JSON Web Token의 약자로, 인증에 필요한 정보들을 암호화시킨 JSON 토큰을 말합니다.
그럼 여기서 토큰은 무엇일까요?
- 토큰은 예전에, 버스 요금을 낼 때 돈을 대신하여 내는 동전 모양의 주조물이라고 사전에 정의되어 있는데요. 다시 말해, 토큰은 동전입니다.
- 웹상에서의 토큰은 특정한 목적으로만 사용 가능한 동전에 일종의 권한을 주는 것을 의미하며, 본인 확인 수단으로 토큰을 사용하고 있습니다.
- 보안 목적으로 사용되는 데이터 조각의 일반적인 용어입니다.
그럼 토큰과 JWT는 무슨 관계인지 궁금하실 수 있을 것 같은데요.
토큰 기반의 인증 종류에는 2가지가 있습니다.
먼저 일반 토큰 기반의 인증은 의미 없는 문자열로 구성됩니다.
a9ace025c90c0da216slgnslkgns232345fgd776그러다 보니, 정보를 담을 수 없고, 발급된 토큰에 대해 만료를 시킬 수단이 없으며, 발급된 토큰을 검사하거나 처리할 때마다 DB에 접근하여 검사할 경우 부담이 생긴다는 문제점들이 있었습니다.
그래서 이러한 문제점을 해결하기 위해 나온 방식이 바로 클레임 토큰 기반의 인증인데요.
대표적으로 JWT가 있습니다.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
클레임이란 사용자 정보나 데이터 속성을 말합니다.
그래서 클레임 토큰은 토큰 안에 사용자 정보나 데이터 속성들을 담고 있는 토큰을 의미합니다.
JWT는 이 클레임을 JSON을 이용해서 정의하고 있습니다.
그렇다면 JWT는 어떤 식으로 구성되어 있을까요?
JWT는 크게 Header, Payload, Signature로 구성되어 있으며 온점 기준으로 이들을 구분하고 있습니다.
jwt.io 라는 사이트를 들어가시면, JWT가 어떻게 구성되어 있는지 한눈에 보실 수 있습니다.
그럼 본격적으로 Header, Payload, Signature는 각각 무슨 정보를 갖고 있는지 알아보겠습니다.
1) Header
먼저 Header는 해시 암호화 알고리즘과 토큰의 타입으로 구성되어 있습니다. alg은 Header를 암호화하는 것이 아니고, JWT를 Signature(서명)할 때 사용한 알고리즘을 명시하는 것이며, 대표적으로 HS256, RS256 이 있습니다.
{
"alg": "HS256",
"typ": "JWT"
}
2) Payload
JWT 구조에서 두 번째 부분에 해당하는 Payload는 사용자가 담고자 하는 정보를 담는 곳입니다.
다시 말해, Payload에는 토큰에서 사용할 정보의 조각들인 Claim들이 담겨있고, 각 클레임은 JSON(Key/Value) 형태의 한 쌍으로 이루어져 있습니다.
아래의 예시에 있는 sub, name, iat 말고도 더 많은 클레임이 존재합니다.
클레임의 종류는 크게 3가지가 있습니다.
2-1) 등록된 클레임
등록된 클레임이란, 토큰 정보를 표현하기 위해 이미 정해진 데이터 종류들로, 선택적으로 작성이 가능한 클레임입니다.
토큰 발급자 issuer, 토큰 제목 subject, 토큰 대상자 audience, 토큰의 만료 시간 expiration, 토큰 활성 날짜 not before, 토큰이 발급된 시간 issued at, JWT 고유 식별자 JWT ID가 있습니다.
2-2) 공개 클레임
사용자 정의 클레임으로, 공개용 정보를 위해 사용되는 클레임입니다. 충돌이 방지된 이름을 가져야 하며, 이를 위해 클레임 이름을 URI 형식으로 짓습니다.
2-3) 비공개 클레임
마찬가지로 사용자 정의 클레임이지만, 서버와 클라이언트 사이에 협의 하에 임의로 지정한 정보를 저장해 사용하는 클레임입니다. 공개 클레임과는 달리 이름이 중복되어 충돌이 될 수 있으니 사용 시에 유의해야 합니다.
3) Signature
JWT 구조에서 마지막 부분에 해당하는 Signature는 Header와 Payload를 합친 문자열에 대한 서명으로, 토큰을 인코딩하거나 유효성 검증을 할 때 사용하는 고유한 암호화 코드입니다.
Signature는 헤더(Header)와 내용(Payload)의 값을 각각 BASE64로 인코딩하고, 인코딩한 값을 비밀키(Secret Key)를 이용해 헤더에서 정의한 알고리즘으로 해싱을 하고, 이 값을 다시 BASE64로 인코딩하여 생성합니다. 서버에서는 이를 이용하여 토큰의 무결성을 검증합니다.
- 소셜 로그인 구현할 때 비밀키(Secret Key)는 해당 회사에 사용할 앱 등록할 때 받는 정보에 있습니다.
- 애플 소셜 로그인의 경우, 애플 측에서 준 AuthKey.p8 파일에 있는 private key가 비밀키(Secret Key) 였어요:)
payload에 있는 claim을 조금 수정하면 다음과 같은 JWT를 얻을 수 있습니다.
그렇다면, JWT은 왜 사용하는 것일까요? 그리고 사용할 때 어떤 점을 조심하면 좋을까요?
장점
- 쿠키를 사용함으로써 발생하는 보안 취약점 개선할 수 있습니다.
- 서버 자원 절약 가능 :
- JWT는 토큰에 필요한 모든 정보를 포함하고 있기 때문에 서버에서 별도의 상태 정보를 저장하지 않아도 됩니다. 인증 과정에서 다른 곳을 거칠 필요 없어 효율적이며, 인증 정보를 가진 특정 서버에만 트래픽이 몰릴 일도 없습니다. 다시 말해, 서버 부하를 줄이기 좋은 방식입니다.
- 확장성:
- 클라이언트 인증 정보를 저장하는 세션과 다르게, 서버는 무상태(StateLess)가 되어 서버 확장성이 우수해질 수 있습니다.
단점
- 토큰 길이:
- 토큰의 페이로드(Payload)에 3종류의 클레임을 저장하기 때문에, 정보가 많아질수록 토큰의 길이가 늘어나 네트워크에 부하를 줄 수 있습니다.
- Payload 인코딩:
- 페이로드(Payload) 자체는 암호화 된 것이 아니라, BASE64Url로 인코딩 된 것입니다. 중간에 Payload를 탈취하여 디코딩하면 데이터를 볼 수 있으므로, JWE로 암호화하거나 Payload에 중요 데이터를 넣지 않아야 합니다.
- 토큰 만료 시간:
- JWT는 상태를 저장하지 않기 때문에 한번 만들어지면 제어가 불가능합니다. 즉, 토큰을 임의로 삭제하는 것이 불가능하므로 토큰 만료 시간을 꼭 넣어주어야 합니다.
JWT로 로그인 구현하다 보면 등장하는 개념이 Access Token과 Refresh Token인데요.
둘 다 JWT입니다.
역할로 따지자면, Access Token은 접근에 관여하는 토큰이고, Refresh Token은 재발급에 관여하는 토큰입니다.
이렇게 이중으로 나눠서 인증을 하는 이유는 바로 제3자에게 토큰이 탈취될 위험성이 있기 때문인데요.
JWT를 발급할 때, 다시 말해 처음 로그인 성공했을 시에 서버는 클라이언트한테 Access Token과 함께 Refresh Token을 함께 발급합니다. Access Token은 1분, 3분의 짧은 시간을 부여하고 Refresh Token에는 일주일, 2주의 비교적 긴 만료시간을 부여하여 Access Token을 보장하는 겁니다. Access Token이 만료되면 Refresh Token으로 서버에게 새로운 Access Token을 발급하도록 하는 구조로 보안을 강화하고 있습니다.
JWT 생성 및 검증 라이브러리
JWT 생성 및 검증은 라이브러리를 통해 쉽게 하실 수 있습니다. 아래 링크 들어가셔서 현재 구현해야 하는 상황에 맞게 라이브러리 이용하시면 좋을 것 같습니다.
Reference
https://etloveguitar.tistory.com/101
https://mokpo.tistory.com/458?category=457116
https://dev-coco.tistory.com/103
https://inpa.tistory.com/entry/WEB-📚-Access-Token-Refresh-Token-원리-feat-JWT
https://velog.io/@hahan/토큰의-정의와-종류
https://mangkyu.tistory.com/56
https://velog.io/@gth1123/JWT-인증-방식
https://velog.io/@mygomi/TIL-50-JWT에-대해-발표해보겠습니다
'GDSC Sookmyung 활동 > 10 min Seminar' 카테고리의 다른 글
| 커스텀 데이터셋 만들기 (0) | 2023.03.05 |
|---|---|
| MVC vs MVVM (0) | 2023.02.27 |
| XML과 Compose의 차이점 (1) | 2023.02.27 |
| Spring Security Trivia (0) | 2023.02.21 |
| 메타버스 보안 기술 (0) | 2023.02.20 |