JWT 토큰 기반 개념 알아보기

 

 

세션 기반 인증

•  서버 기반 인증은 사용자가 로그인하면 서버가 세션을 생성하고, 클라이언트에게 세션 ID를 발급하는 방식
  서버는 이 세션 ID를 통해 클라이언트의 상태를 관리함
• 동작 방식
  • 사용자가 로그인하면 서버는 세션을 생성하고, 해당 세션 ID를 클라이언트에 쿠키로 전달한다.
  • 클라이언트는 이후 요청마다 이 세션 ID를 서버에 전달하여 인증을 확인한다.
  • 서버는 세션 저장소에서 세션 ID를 확인하고, 클라이언트를 인증한다.
• 장점: 서버에서 관리되므로 보안이 비교적 쉽다.
• 단점: 서버에 세션을 저장해야 하므로 서버의 자원이 많이 사용된다.
  서버가 상태를 유지해야 하므로, 서버 간 세션 동기화 문제가 발생할 수 있다.

 

토큰 기반 인증

• 클라이언트가 로그인하면 서버가 인증 토큰을 생성하여 클라이언트에게 제공하고,
  클라이언트는 이후 요청마다 이 토큰을 사용해 인증을 받는 방식.
• 동작 방식:
  • 사용자가 로그인하면 서버는 유일한 값인 토큰을 생성하여 클라이언트에 전달한다.
  • 클라이언트는 이후 요청을 보낼 때 이 토큰을 함께 포함시켜 서버에 전달한다.
  • 서버는 이 토큰을 검증하여 클라이언트가 유효한 사용자임을 확인한다.
• 장점: 서버가 클라이언트의 상태를 유지할 필요가 없으며, 서버 확장이 용이합니다. 또한, 서버에 별도의 세션 저장소가 필요하지 않습니다.
• 단점: 토큰이 유출되면 보안 문제가 발생할 수 있으며, 토큰의 유효기간이 짧아야 하므로 자주 갱신해야 하는 번거로움이 있습니다.

 

• 대표적 사용자 인증 확인 방법으로 서버 기반 인증, 토큰 기반 인증
• 스프링 시큐리티에서는 기본적으로 세션 기반 인증 제공
• 토큰, 서버에서 클라이언트를 구분하기 위한 유일한 값
• 서버가 토큰을 생성하여 클라이언트에게 제공하고, 클라이언트는 이 토큰을 갖고 있다가 여러 요청을 이 토큰과 함께 신청하여 유효한 사용자인지 서버가 검증

---

스프링 시큐리티에서 세션 기반 인증

스프링 시큐리티에서는 기본적으로 세션 기반 인증을 제공한다. 로그인 후 세션을 생성하고, 세션 ID를 사용해 클라이언트를 인증하는 방식이다. 하지만, 토큰 기반 인증도 스프링 시큐리티에서 구현할 수 있으며, JWT(JSON Web Token) 등을 사용하여 클라이언트를 인증하는 방식이 많이 사용된다.

 

---

토큰 기반의 특징

• 무상태성
  사용자의 인증 정보가 담겨 있는 토큰이 서버가 아닌 클라이언트에 있으므로 서버에 저장 할 필요 없음. 서버 자원을 낭비하지 않게 됨
  클라이언트의 인증 정보를 저장하거나 유지하지 않아도 되기에 완전한 무사태로 효율적인 검증 가능
• 확장성
  추후 서버 확정에도 용이하다.
• 무결성
  토큰 발급 이후 토큰 정보를 변경 할 수 없다. 만약 토큰의 한 글자라도 변경하면 서버는 유효하지 않은 토큰이라 판단

---

JWT

JSON Web Token (JWT) 은 웹표준 (RFC 7519) 으로서 두 개체에서 JSON 객체를 사용하여 가볍고 자가수용적인 (self-contained) 방식으로 정보를 안전성 있게 전달해줍니다.

 

 

jwt 구조

https://velopert.com/2389

헤더(Header)

• 토큰의 타입과 해싱 알고리즘을 지정하는 정보 담음

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

 

이름	설명
typ	토큰의 타입 지정. JWT 라는 문자열이 들어가게 됨
alg	해싱 알고리즘 지정

 

 

내용(payload)

• 내용에는 토큰과 관련된 정보를 담는다.
• 클레임claim
  
  • 내용의 한 덩어리
  • 키값의 한 쌍으로 이루어짐
  • 등록된 클레임, 공개 클레임, 비공개 클레임으로 나눌 수 있다.

 

등록된 클레임

이름	설명
iss	토큰 발급자(issuer)
sub	토큰 제목 (subject)
aud	토큰 대상자(audience)
exp	토큰의 만료시간(expiraton). 시간 NumericDate 형식으로 하며, 항상 현재 시간 이후로 설정합니다.
nbf	토큰의 활성 날짜와 비슷한 개념으로 nbf는 Not Before 의미. NumericDate 형식으로 날짜를 지정하며, 이 날짜가 지나기 전까지는 토큰이 처리 되지 않습니다.
iat	토큰이 발급된 시간으로 iat은 issued at을 의미
jti	JWT의 고유 식별자로서 주로 일회용 토큰에 사용

 

공개 클레임

• 공개되어도 상관 없는 클레임
• 충돌 방지할 수 있는 이름을 가져야함. 보통 클레임 이름을 URI로 지음

 

비공개 클레임

• 공개되면 안되는 클레임을 의미
• 클라이언트와 서버 간의 통신에 사용

jwt예시

{
  "iss": "example@gmail.com",  // 등록된 클레임
  "iat": 1622370878,  // 등록된 클레임
  "exp": 1622372678,  // 등록된 클레임
  "https://rara.com/jwt_claims/is_admin": true,  // 공개 클레임
  "email": "example@gmail.com",  // 비공개 클레임
  "hello": "Hello world"  // 비공개 클레임
 }

 

성명(signature)

• 해당 토큰이 조작되었거나 변경되지 않았음을 확인하는 용도
• 헤더의 인코딩값과 내용의 인코딩 값을 합친 후 주어진 비밀키를 사용해 해시값을 생성

---

 

토큰의 유효기간

대부분의 인증 시스템에서는 보안을 위해 액세스 토큰의 유효기간을 짧게 설정

하지만 유효기간이 짧기 때문에, 사용자가 계속해서 새로운 액세스 토큰을 얻어야 할 필요함이 생긴다.

이때, 사용자는 다시 로그인할 필요 없이 리프레시 토큰을 사용해 새로운 액세스 토큰을 받을 수 있다.

 

액세스 토큰 Access Token

• 사용자가 특정 자원에 접근할 수 있는 권한을 부여받았다는 것을 나타내는 인증 토큰
• 서버가 사용자의 신원을 확인하고, 해당 사용자가 요청한 자원에 접근할 수 있는 권한이 있는지 확인할 때 사용
• 리프레시 토큰에 비해 짧은 만료 기간

 

리프레시 토큰 Refresh Token

• 액세스 토큰과 별개의 토큰
• 클라이언트가 액세스 토큰이 없거나 만료시 리프레시 토큰을 통해 서버에 요청하여 새로운 액세스 토큰을 발급 받을 수 있다.
• Access Token에 비해서 긴 만료 기간
• 외부에 노출되지 않도록 관리를 위해서 데이터베이스에 저장

 

JWT 인증과정

출처 : https://velog.io/@yh20studio/토큰-기반-인증-시스템-JWT

 

 

 

1. 클라이언트가 서버에 인증 요청
2. 서버는 클라이언트에서 전달한 정보를 바탕으로 인증정보 유효한지 확인 후,
   액세스 토큰과 리프레시 토큰 생성 후 클라이언트에게 전달. 클라이언트는 전달 받은 토큰 저장
3. 서버에서 생성한 리프레시 토큰 DB 저장
4. 인증을 필요로 하는 API를 호출할 때, 클라이언트는 저장된 액세스 토큰과 함께 API를 요청
5. 서버에서 전달받은 액세스 토큰 유효한지 검사한 후 유효하다면 클라이언트에서 요청한 내용 처리
6. 액세스 토큰이 만료된 뒤에 클라이언트가 만료된 엑세스 토큰과 함께 API를 요청
7. 서버는 액세스 토큰이 유효한지 검사. 만료된 토큰이면 토큰이 만료되었다는 에러 전달
8. 클라이언트는 저장해둔 리프레시 토큰과 함께 새로운 엑세스 토큰을 발급하는 요청을 서버에게 전송
9. 서버는 전달받은 리프레시 토큰 유효한지, DB에서 리프레시 토큰 조회 후 저장해둔 리프레시 토큰과 같은지 확인
10. 만약 유효한 리프레시 토큰일 경우 새로운 액세스 토큰을 생성한 뒤 응답
    그 이후 클라이언트는 다시 API 요청을 하게된다.

 

---

참고

해당 글은 아래 도서의 내용을 참고하며 정리한 개인학습용 글입니다. 
스프링 부트 3 벡엔드 개발자 되기 - 자바 편, 신선영

 

https://velopert.com/2389

https://velog.io/@yh20studio/토큰-기반-인증-시스템-JWT

https://velog.io/@summer_today/9.1-JWT-기본-이해