JWT? 장단점? 왜쓸까?

 

 

 

3줄 요약

1. JWT(Json Web Token)이란 JSON 객체에 인증(Authentication), 인가(Authorization) 정보를 담아 서버-클라이언트 간 안전하게 데이터를 주고받기 위한 매개체 => 주된 사용처는 로그인!

2. 장점 : JWT로 로그인 구현시 서버에 부담이 적고, 수평 확장에 용이 

3. 단점 : Payload에 너무 많은 정보다가 담기면 네트워크 사용량이 증가, 클라이언트에 토큰이 저장되어 서버에서 조작 불가

 

 

1. JWT(Json Web Token) 이란?

• 유저의 인증(Authentication)과 인가(Authorization) 정보를 서버와 클라이언트 간에 안전하게 주고받기 위해서 사용합니다.  
• JWT 토큰은 웹에서 Authorization HTTP HEADER를 Bearer <토큰> 형태로 설정하여 클라이언트 -> 서버로 전송되며, 서버에서는 토큰에 포함되어 있는 서명(singnature) 정보를 통해 위변조 여부를 빠르게 검증합니다.
• JWT 토큰은 eyJ와 같이 긴 문자열로 되어있는데 이는 Base64로 인코딩 되어 있고, 온라인 디버거로 쉽게 JSON 형태로 디코딩할 수 있습니다.
• JWT 토큰은 네트워크 전송되는데 공간을 최대한 줄이기 위해 JSON 형식으로 저장하면서 키(KEY)를 3글자로 줄여 사용하는 관행이 있습니다.

• JWT(Json Web Token)는 RFC 7519] 웹 표준을 따르고 있으며 (웹 표준을 따르기 때문에 다른 언어에서도 지원), JSON객체를 사용해 정보를 전달합니다. 아래 URL 참고

RFC 7519: JSON Web Token (JWT)

 

 

---

 

 

 

 

 

2.  JWT 구조(헤더. 페이로드. 서명)

 

※ 토큰 예시

• 왼쪽이 인코딩 된 토큰입니다.
• 오른쪽이 인코딩 된 토큰을 디코딩한 결괏값입니다. 
  • 헤더와 페이로드, 시그니처에 해당하는 값을 동일한 색상으로 비교 가능합니다.

 

 

1) Header(인코딩 : Base64) : 알고리즘과 토큰 유형 정보를 가지고 있음

 

 

• 헤더에서는 해시 알고리즘과 토큰의 타입을 정의합니다.
• 토큰의 유형은 첫 부분은 JWT를 나타내고, 두 번째는 HMAC, SHA256, RSA와 같은 해시 알고리즘을 나타냅니다.
• HS256은  HMAV SHA 256을 의미하며, 해시 알고리즘 중 한 가지입니다.
• 타입은 "JWT"로 지정하면 됩니다.

 

2) Payload(페이로드) : 데이터 정의

•  페이로드에는 전달하고자 하는 데이터를 추가합니다.
• 데이터에서 Key는 Claim이라고 부르며, claim은 사용자가 원하는 Key : Value로 구성할 수 있습니다.
• Claim 종류
• registered claim : 등록된 클레임
  • 3글자로 정의하며, 필수사항은 아니나 사용을 권장합니다.
  • 종류
    • sub 키: 인증 주체(subject)
    • iss 키: 토큰 발급처
    • typ 키: 토큰의 유형(type)
    • alg 키: 서명 알고리즘(algorithm)
    • iat 키: 발급 시각(issued at)
    • exp 키: 만료 시작(expiration time)
    • aud 키: 클라이언트(audience)

RFC 7519: JSON Web Token (JWT)

 

• public claim : 공개 클레임
• 사용자가 자유롭게 정의할 수 있습니다.
• 단, 충돌 방지를 위해 IANA JSON 웹 토큰 레지스트리에 정의돼 있거나 충돌이 방지된 네임스페이스를 포함하는 URI로 정의해야 합니다.
• 사용 예시

 

 

• private claim : 비공개 클레임
  • 커스터마이징 된 클레임 

! 주의사항
PAYLOAD는 단순 Base64 인코딩이 된 부분으로 누구나 쉽게 디코딩하여 데이터 열람이 가능합니다.
PASSWORD와 같은 중요 데이터는 PAYLOAD에 담아선 안됩니다.

 

 

3) SIGNATURE(서명)

• 서명 파트는 위와 같이 Base64 인코딩 된 HEADER.PAYLOAD 에 추가로 SECRET이 필요합니다.
• SECRET은 유저가 지정하는 비밀키입니다.

 

 

 

---

 

 

 

 

 

 

 

 

3.  JWT를 통한 인증(Authorization)과 인가(Authentication)

 

! INFO
실무에서는 OAuth나 OIDC 프로토콜과 함께 API 인증, 인가를 위해 주로 JWT를 사용합니다.

 

1. 유저는 서버에 로그인 요청을 합니다.
2. 서버는 회원 DB에 있는 회원 정보를 확인하여 해당 사용자 정보가 올바른지 확인합니다.
3. 확인이 완료되면 서버는 Secret Key를 통해 Access 토큰을 발급합니다.
4. Access를 담은 결과를 클라이언트에 Response 합니다.
5. 이후부터 클라이언트는 데이터를 요청할 때 헤더에 JWT 토큰을 담아 서버에 요청을 보냅니다.
6. 서버는 헤더에 담긴 Access 토큰 정보만 확인하고 요청받은 데이터를 전달합니다.

 

 

---

 

 

 

 

4. JWT 장점 vs 단점

장점	단점
기존에는 로그인시 쿠키와 세션을 이용한 사용자 인증을 구현했었습니다. 이는 서버에 많은 부하를 주는데 매번 요청 할때마다 사용자의 세션을 DB나 캐시에 저장해두고 요청받은 세션 ID를 검증해야했습니다. JWT 경우 사용자 정보가 토큰안에 있기 때문에 서버는 매번 클라이언트 요청이 있을 때 헤더에 담겨있는 JWT 토큰에 있는 사용자 정보를 검증하면 되기 때문에 서버에 부담이 적습니다. 중앙 인증서버, 데이터 스토어에 대한 의존성이 없고 시스템의 수평 확장에 유리합니다. Base64 URL Safe Encoding 을 URL, Cookie, Header 모두에 사용가능합니다.	* Payload의 정보가 많아지면 네트워크 사용량이 증가하고, 데이터 설계를 고려해야합니다. * 토큰이 클라이언트에 저장되기 때문에, 서버에서 클라이언트의 토큰을 조작할 수 없습니다.

 

 

 

 

 

---

 

느낀 점과 부족한 점

 

사이드프로젝트를 할 때 매번 세션만 이용해 개발했었는데, 단순히 개발만이 아니라 내가 왜 이 기술을 썼는지에 대해 생각해 보는 시간이 많지 않았습니다. 어떤 기술에 대해 학습할 때는 얇고 넓은 지식이 아닌 깊고 좁은 형태의 학습이 개발자에게 필요하지 않나 생각하게 되었습니다.

로그인 구현 시 세션을 이용한 이유가 무엇인지? 다른 방법은 어떤 것이 있는지? 다른 방법의 장단점은 무엇이고 어떤 환경에선 어떤 기술이 적합한지? 등 항상 자기 자신에게 질문을 던지고 그에 합당한 답변을 할 줄 알아야 함을 다시 한번 느꼈습니다.

위 이론적인 내용을 기반으로 실제 Springboot 프레임워크 환경에서 구현방법은 어떻게 되는지 학습 후 포스팅을 남길 예정입니다.

 

 

 

 

 

 

※ 본 포스팅에서 참고한 블로그 및 사이트

• JWT 공식 홈페이지 : https://jwt.io/introduction
• 참고 블로그 1 : https://velog.io/@vamos_eon/JWT%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80-%EA%B7%B8%EB%A6%AC%EA%B3%A0-%EC%96%B4%EB%96%BB%EA%B2%8C-%EC%82%AC%EC%9A%A9%ED%95%98%EB%8A%94%EA%B0%80-1
• 참고 블로그 2 : http://www.opennaru.com/opennaru-blog/jwt-json-web-token/
• 참고 블로그 3 : https://www.daleseo.com/jwt/
• 참고 블로그 4 : https://brunch.co.kr/@jinyoungchoi95/1
• 참고 블로그 5 : https://velog.io/@chuu1019/%EC%95%8C%EA%B3%A0-%EC%93%B0%EC%9E%90-JWTJson-Web-Token