post-custom-banner

🧐 JWT 사용배경

  • 세션 기반 인증방식
    : 서버에서 클라이언트에게 세션 ID 부여, 이 ID를 사용하여 사용자를 인증하고 권한 부여하는 식으로 처리한다.
    🚨 하지만, 세션 기반의 인증 방식은 서버 측에서 상태 유지 --> 확장성 & 분산처리에 제한이 있다.
    또 서버 측에서 상태를 유지하기 때문에 서버 부하가 크고 여러 서버를 사용할 경우 동기화 문제도 발생한다.

💡 JWT란?

  • JSON Web Token의 약어로 웹 애플리케이션에서 사용자 인증 및 권한 부여를 위한 인증 방식 중 하나이다.
  • 클라이언트와 서버 간의 통신에서 사용
  • 자가수용적: 필요한 모든 정보를 자체적으로 지니고 있음, JWT 시스템에서 발급된 토큰은 토큰에 대한 기본정보, 전달할 정보, 토큰이 검증됐다는 것을 증명해주는 Signature 포함
  1. 클라이언트 -> 로그인 요청
  2. 서버 -> 사용자 정보를 기반으로 JWT 생성 및 클라이언트에게 반환
  3. 클라이언트 -> 받은 JWT를 이후 요청에서 '인증 헤더'에 추가하여 서버가 해당 요청을 수락 할 수 있도록 함 즉, 이후 요청에서 JWT를 사용하여 자신이 인증된 사용자임을 증명함
  4. 서버 -> JWT검증, 해당 사용자에 대한 요청 수락

🌟JWT
클라이언트-> 상태 유지
서버-> 인증 처리

  • 확장성과 분산처리에 용이 , 클라이언트와 서버 간의 통신에서 암호화된 문자열만 사용하기 때문에 동기화 문제도 발생하지 않는다.
  • 따라서 JWT는 세션 기반의 인증 방식보다 보안적으로 강력하고, 확장성과 분산처리에 용이하며, 클라이언트 측에서 유지되므로 서버 부하도 줄일 수 있는 장점이 있어서 널리 사용되고 있다

🫥 JWT 구성요소

  • JWT 토큰이 어떤 종류인지와 어떤 알고리즘을 사용하여 서명이 되었는지를 나타내는 부분이다.
    -typ: 토큰 타입 지정
    -alg: Signature 해싱 알고리즘 지정
    {"alg": "HS256", "typ": "JWT"}

Payload

  • JWT 토큰에서 실제로 전송하고자 하는 정보를 담고 있는 부분이다.
    {"sub": "1234567890", "name": "John Doe", "iat": 1516239022}
    -sub: JWT 토큰이 발급된 사용자를 구분할 수 있는 고유한 값
    -name: 사용자의 이름
    -iat: JWT 토큰이 발급된 시간

Signature

  • JWT 토큰이 서명되어 있는 부분
  • Signature는 Header와 Payload를 조합한 후, 서버에서 사용하는 시크릿 키를 이용하여 해싱된 값
    HmacSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)

📚 관련 라이브러리

Okta와 OAuth 2.0은 모두 인증과 권한 부여를 관리하는 데 사용되는 프로토콜이나 서비스

1. Okta

클라우드 기반의 IDaaS(Identity as a Service) 서비스

  • 개발자는 인증 및 권한 부여를 간편하게 관리
  • Okta는 SAML, OAuth 2.0, OpenID Connect와 같은 표준 기반 인증 및 권한 부여 프로토콜을 지원하며, API를 통해 애플리케이션과 Okta를 통합가능

2.OAuth 2.0

인증 및 권한 부여를 위한 프로토콜

  • OAuth 2.0을 사용하면 사용자가 애플리케이션에 로그인할 때, 애플리케이션이 사용자의 권한을 위임받아 API나 다른 서비스에 접근
  • OAuth 2.0은 간편한 인증 및 권한 부여를 제공하며, 인증 및 권한 부여를 위한 여러 프로토콜을 제공
  • 예를 들어, OAuth 2.0은 Authorization Code Grant, Implicit Grant, Client Credentials Grant 등 다양한 인증 방식을 지원

Okta는 OAuth 2.0을 사용하여 인증 및 권한 부여를 처리한다.
Okta는 OAuth 2.0을 지원하기 때문에, OAuth 2.0을 사용하는 다른 애플리케이션과도 통합이 용이

😶 JWT한계

1.JWT는 사용자 정보를 암호화하여 포함하고 있기 때문에, JWT의 크기가 큼
-> 네트워크 대역폭을 낭비하고, 클라이언트와 서버 간의 통신 성능을 낮춤

해결 방법: JWT의 크기를 줄이기 위해 필요한 정보만 포함시키도록 페이로드(payload)를 최적화하고, 필요한 정보만 요청하는 등의 방법을 사용가능

2. JWT는 한 번 발급되면 만료되기 전까지 계속 사용
->만약 JWT가 탈취되거나 조작된다면, 해당 사용자의 모든 정보가 노출될 수 있다.

해결 방법: JWT의 만료 시간을 짧게 설정하여 보안성을 높일 수 있음 또는, JWT를 발급할 때마다 서버 측에서 고유한 랜덤한 값을 추가하여, 조작 방지

3. JWT는 서명되어 있지만, 데이터가 암호화되어 있지는 않음
->JWT를 가로채면 내용을 볼 수 있다.
해결 방법: JWT의 페이로드(payload)를 암호화하여 내용을 보호할 수 있습니다. 이를 위해 JWE(Json Web Encryption)를 사용

4. JWT를 사용하면, 클라이언트 측에서 인증을 처리하기 때문에, XSS(Cross-Site Scripting)와 CSRF(Cross-Site Request Forgery)와 같은 공격에 노출위험
해결 방법: XSS와 CSRF와 같은 공격을 방지하기 위해서는, 적절한 보안 정책을 설정 및 클라이언트 측에서 JWT를 안전하게 보호
이를 위해 쿠키를 사용하거나, CSRF 토큰을 사용하는 등의 방법 있음

출처 🙇‍♀️

https://velog.io/@mygomi/TIL-50-JWT%EC%97%90-%EB%8C%80%ED%95%B4-%EB%B0%9C%ED%91%9C%ED%95%B4%EB%B3%B4%EA%B2%A0%EC%8A%B5%EB%8B%88%EB%8B%A4

https://velog.io/@dnjscksdn98/JWT-JSON-Web-Token-%EC%86%8C%EA%B0%9C-%EB%B0%8F-%EA%B5%AC%EC%A1%B0

post-custom-banner

0개의 댓글