01 JWT란 무엇인가? 02 JWT는 언제, 왜 필요한가? 03 JWT의 장점, 단점, 주의할 점

1. 01 JWT란 무엇인가?
02 JWT는 언제, 왜 필요한가?
03 JWT의 장점, 단점, 주의할 점

2. JWT(JSON Web Token)이란 무엇인가?

3. JWT란무엇인가?
용어 정의
• 클레임(Claim) : 토큰 주체에 대한 사실 정보를 담고 있는 키/값 쌍. 예를 들어, 사용자 정보, 테넌트, 권한 등
• Ex. “name” : “Gildong”, “role” : “admin”
JWT의 정의
• 디지털 서명(Digitally Signed)을 통해 서로 다른 시스템간의 정보를 보안 상 문제가 없도록 JSON 객체 형태로 주고받는
오픈 스탠다드 (RFC 7519)

4. JWT의특징
Signing의 두 가지 방식
1. Secret(서버가 가지고 있음) 정보를 이용하여 HMAC 알고리즘으로 signing (대칭키)
2. RSA, 또는 ECDSA를 이용하여 공개키/개인키 쌍으로 signing (비대칭키)
○ 여러 대의 서버에서 Token에 대한 검증(verify)이 필요한 경우, secret 정보를 모두 공유하는 것에 따르는
보안상의 위험
Token 암호화의 두 가지 방식
1. Signed Token (JWS – RFC7515) : 내부에 포함된 클레임(claim)들의 무결성(integrity)을 확인할 수 있음
2. Encrypted Token (JWE – RFC7516) : 다른 시스템(party)으로 부터 내부 클레임 정보를 숨길 수 있음

5. JWT의구조
Header, Payload, Signature 3가지 요소가 점(.)으로 연결되어 있음. (ex. xxxxx.yyyyy.zzzzz 와 같은 형식)

6. JWT의구조
Header (Base64Url Encoded)
(일반적으로) 두 개의 정보로 구성 됨. (이 두 가지 정보를 담고 있는 JSON 객체가 Base64URL Encoded 됨)
1. typ : 토큰의 종류 (ex. JWT)
2. alg : 사용된 서명 알고리즘 종류 (ex. HS256(HMAC + SHA256), RSA)

7. JWT의구조
Payload (Base64Url Encoded)
클레임(Claim) 정보를 가지고 있음. 클레임은 엔티티(보통은 사용자)에 대한 정보와 그 외의 추가적인 정보를 담고 있음.
세 가지 종류의 클레임(Claim)이 있음
1. Registered claims : 미리 정의된 클레임. 필수는 아니지만 상호 운용성(interoperable)을 위해 권고되는 정보.
1. iss : issuer (ex. https://client.logi-spot.com/api/v1/xxxx)
2. exp : expiration time
3. aud : audience
4. others
2. Public claims : JWT를 사용하는 사람들이 필요에 의해서 정의해서 사용하는 공통 클레임. 하지만 충돌을 방지하기
위해서 IANA JWT Registry에 등록하거나 namespace 등을 이용해서 구분하는 것이 좋음
3. Private claims : 커스텀 클레임. 정보를 주고 받는 당사자(ex. 클라이언트/서버) 끼리만 약속해서 사용하면 됨.

8. JWT의구조
Signature
Base64Url Encoded된 Header와 Payload 정보, 그리고 secret 정보와 Header에 명시된 서명 알고리즘을 이용해서 생성됨
• 이 Signature는 Token의 내용이 변조되었는지 확인하는 용도로 사용됨 (Private Key를 이용한 경우에는 이 Token을
보내온 주체가 실제 해당 주체임을 확인할 수 있음)
• Example
• HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
• base64UrlEncode(RSASHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload)))

9. JWTRefreshToken-Type1.일반적인 케이스

10. JWTRefreshToken-Type2.LaravelTymonJWTImplementation

11. JWT는 언제, 왜필요한가?

12. JWT는언제,왜필요한가?
Session을 이용한 방식
Client는 Session ID만을 가지고 있고, 서버에서 세션의 정보를 가지고 있기 때문에 별도의 공유 세션 스토어를 두지 않는
이상 서버의 Scale out이 어려움
암호화된 Cookie를 이용한 방식
서로 다른 호스트 간의 인증 정보를 공유할 때 CORS(Cross-Origin Resource Sharing) 이슈가 발생할 수 있음

13. JWT는언제,왜필요한가?
Authorization
인증 뿐만 아니라 특정 route, service, resource 접근에 대한 권한을 체크할 때 유용. 최근들어 SSO에서 JWT를 많이
이용함. 그 이유는 작은 오버헤드, 서로 다른 도메인에 쉽게 이용될 수 있기 때문)
Information Exchange
JWT는 정보를 보안적으로 주고 받을 때 유용함. 예를 들어, 공개키와 개인키로 서명된 토큰은 해당 토큰을 보내온
클라이언트가 실제 해당 토큰을 서명한 당사자임을 보장할 수 있다. 또한, signature는 토큰의 헤더정보와 payload를
이용해서 계산되기 때문에 토큰의 컨텐츠가 변조되지 않았음을 확인할 수 있다.

14. JWT의 장점, 단점, 주의할 점

15. JWT사용시주의할점
1. 필요이상으로 TTL(Time to live) 값을 길게 가져가면 안됨
○ 일반적으로 Session을 관리하던 방식과 차이가 있는데, Session의 경우 interaction이 일어나면 expiration
시간이 연장되는 개념이지만 Token 방식은 그렇지 않음.
2. 노출되면 안되는 중요한 정보를 Payload에 담으면 안됨 (JWT 문자열은 변조할 수 없을 뿐이지 내부의 내용을 볼 수
없는 것은 아님)

16. JWT의장단점
장점
1. JWT Payload에 권한체크에 필요한 적당한 정보를 담고 있다면 Resource에 대한 접근권한을 체크하기 위해서 다시
Database를 조회할 필요가 없음
2. Authorization 정보를 header에 보내는 경우, Cookie를 사용할 필요가 없기 때문에 CORS(Cross-Origin Resource
Sharing) 이슈가 발생하지 않음
3. 서버에서 정보를 가지고 있지 않아도 되기 때문에 Scale out이 용이함
단점
1. 서버에서 강제로 Revoke 하기가 어려움 (사용자가 비밀번호를 변경하거나, 계정이 정지되어도 Token 자체는 유효한
상태로 남아서 Resource에 대한 접근이 가능함. (중복 검사하지 않는 이상))
○ Webhook을 이용한 "Refresh Token Revoke Event” 방식으로 해결할 수는 있음