Jason Web Token

Token

웹 애플리케이션에서 클라이언트와 서버 간의 안전한 통신을 위해 토큰이 사용됩니다. 

 

웹 보안에서 토큰(Token)은 클라이언트와 서버 간의 상태를 유지하지 않는(HTTP가 상태를 유지하지 않는 프로토콜이기 때문) 통신 환경에서, 사용자의 인증 정보, 세션 정보, 또는 기타 사용자 정의 데이터를 안전하게 전송하기 위해 사용되는 암호화된 문자열을 의미합니다. 이 토큰은 사용자가 서버에 로그인하는 과정에서 인증 후, 서버에 의해 생성되며, 이후 사용자의 요청마다 해당 토큰을 서버에 전송하여 사용자를 인증하고 권한을 확인합니다.

 

토큰의 핵심 기능과 목적:

1. 인증(Authentication): 토큰은 사용자가 누구인지 서버에 알려주는 역할을 합니다. 사용자가 처음 로그인할 때, 서버는 사용자의 인증 정보 (예: 아이디와 비밀번호)를 검증한 후, 해당 사용자에 대한 토큰을 생성하고 반환합니다.
2. 세션 관리(Session Management): 전통적인 세션 기반 인증 시스템에서는 서버가 사용자의 로그인 상태를 추적하기 위해 세션을 유지합니다. 반면, 토큰 기반 시스템에서는 클라이언트가 서버로부터 받은 토큰을 저장하고 있으며, 각 요청마다 이 토큰을 서버에 전송하여 사용자가 누구인지를 알립니다. 이 방법은 서버의 리소스를 절약할 수 있습니다.
   
3. 권한 부여(Authorization): 토큰은 사용자가 특정 리소스에 접근할 수 있는 권한이 있는지 없는지를 검증하는 데 사용됩니다. 토큰 내부에는 사용자의 권한 수준에 대한 정보가 포함될 수 있으며, 이를 통해 서버는 사용자가 요청한 작업을 수행할 수 있는지를 결정합니다.
   
4. 보안(Security): 토큰은 일반적으로 안전한 방식으로 생성되며, 서버만이 토큰의 진위를 검증할 수 있는 정보를 포함합니다. 이를 통해 CSRF(Cross-Site Request Forgery) 공격과 같은 웹 보안 취약점을 방지할 수 있습니다.
   
5. 5. 크로스 도메인 요청(Cross-Domain Requests): 토큰 기반 인증은 CORS(Cross-Origin Resource Sharing) 정책에 따라 다른 도메인의 리소스에 접근할 때 사용될 수 있으며, 쿠키를 사용하는 방식보다 유연하고 안전합니다.

 

토큰의 생성과 전송 과정

1. 인증 과정: 사용자가 로그인을 하면 서버는 사용자의 자격 증명을 확인하고, 이를 바탕으로 토큰을 생성하여 반환합니다. 이 토큰은 주로 JSON Web Token (JWT) 형식으로, 서버만이 검증할 수 있는 서명(Signature)과 인증에 필요한 정보를 포함하고 있습니다.

2. 토큰의 구조: JWT를 예로 들면, 토큰은 다음과 같은 세 부분으로 구성됩니다.
  ⦁ Header: 토큰 유형과 암호화 방식을 정의합니다.
  ⦁ Payload: 사용자 ID, 권한, 만료 시간 등 인증 및 권한 부여에 필요한 정보를 담고 있습니다.
  ⦁ Signature: Header와 Payload를 서버의 비밀 키로 해싱하여 생성된 값으로, 토큰의 무결성을 보장합니다.

3. 토큰 전송: 클라이언트는 이후 요청마다 이 토큰을 서버에 전송하여 본인을 인증합니다. 토큰은 HTTP 헤더(예: Authorization: Bearer [토큰])나 쿠키, URL 파라미터 등을 통해 전송되며, 서버는 이를 검증하여 요청을 처리할 수 있는 권한이 있는지 확인합니다.

4. 서버의 토큰 검증: 서버는 토큰이 위조되지 않았는지 확인하기 위해 Signature 검증을 수행하며, 만료 시간도 함께 확인합니다. 유효하지 않거나 만료된 토큰이 있을 경우 서버는 요청을 거부하고, 필요 시 재로그인을 요청하거나 Refresh Token을 통해 토큰을 재발급할 수 있습니다.

 

토큰 사용 시 고려해야 할 보안 요소

1. 무결성 검증: 토큰은 클라이언트가 수정할 수 없도록 서명을 포함하여 생성됩니다. 서버는 이 서명을 검증하여 토큰이 위조되지 않았음을 확인합니다.
2. 암호화: 토큰은 안전하게 생성되며, HTTPS를 통해 전송하여 중간에 탈취되는 것을 방지합니다. 특히 사용자 정보가 담긴 토큰의 경우, 민감 정보 보호를 위해 암호화된 형식이 필요합니다.
   
3. 토큰 저장 위치: 클라이언트는 토큰을 안전하게 저장해야 하며, 쿠키에 저장할 경우 HttpOnly 및 Secure 속성을 설정하여 XSS 공격을 방지하는 것이 좋습니다.
   
4. 토큰의 만료 시간: 토큰의 만료 시간을 짧게 설정하여 보안을 강화하며, Access Token과 Refresh Token을 함께 사용하여 만료된 토큰의 자동 갱신이 가능합니다.
   
5. 탈취 위험 관리: 탈취된 토큰이 악용되지 않도록 정기적으로 재발급하거나 블랙리스트를 사용해 특정 토큰을 무효화하는 방법을 고려해야 합니다.

 

토큰의 종류:

1. JSON Web Token (JWT): 가장 널리 사용되는 토큰 형식 중 하나로, 자가 포함(Self-contained) 방식으로 사용자 정보를 JSON 객체 형태로 안전하게 전달합니다.
2. OAuth 2.0 토큰: 외부 서비스(예: 구글, 페이스북)를 통한 인증에 사용되며, 사용자가 자신의 계정 정보를 직접 입력하지 않고도 외부 서비스의 인증을 통해 애플리케이션에 로그인할 수 있게 해줍니다.
   
3. Refresh Token: JWT와 같은 토큰은 만료 기간이 있으며, Refresh Token은 만료된 액세스 토큰을 새로 발급받기 위해 사용됩니다.

 

토큰 기반 인증 방식의 장점과 한계

⦁ 장점:

• 서버 부담 감소: 상태 비저장 방식으로 서버의 세션 저장 부담을 덜어주며, 분산 서버 환경에서도 유연하게 인증을 유지할 수 있습니다.
• 확장성: 서버가 사용자 세션을 관리하지 않기 때문에 서버 확장이 용이합니다.
  

⦁ 한계:

• 보안 리스크: 토큰이 탈취될 경우 악용될 가능성이 있으므로, 클라이언트가 이를 안전하게 저장하고 전송하는 방식이 중요합니다.
• 토큰 무효화의 어려움: 토큰을 강제로 무효화하거나 폐기하는 데 한계가 있습니다. 이를 해결하기 위해 블랙리스트 관리나 주기적인 토큰 갱신을 고려해야 합니다.
  

토큰은 웹 애플리케이션의 인증, 세션 관리, 권한 부여를 안전하고 효율적으로 처리하기 위한 핵심적인 수단입니다. 토큰 기반 인증은 서버의 확장성을 높이며, 클라이언트와 서버 간의 상태 비저장 통신을 가능하게 하여, 현대 웹 애플리케이션에서 필수적인 보안 메커니즘으로 자리잡고 있습니다.

 

Self-contained Token

Self-contained Token은 인증에 필요한 정보를 토큰 자체에 포함하는 방식입니다. 즉, 클라이언트가 인증 서버에 요청하여 얻은 토큰을 서버가 따로 저장하지 않고도 유효성을 검증할 수 있도록, 토큰 안에 필요한 정보를 모두 포함합니다. 일반적으로 이는 stateless 방식의 인증을 가능하게 합니다. 이 방식을 사용하면 서버가 확장 가능해지고, 서버 간의 상태 동기화 부담이 줄어들게 됩니다.

이러한 Self-contained Token의 대표적인 예가 바로 JWT입니다.

 

JWT(JSON Web Token)

JSON 웹 토큰(JSON Web Token, JWT, "jot”)은 선택적 서명 및 선택적 암호화를 사용하여 데이터를 만들기 위한 인터넷 표준으로, 페이로드는 몇몇 클레임(claim) 표명(assert)을 처리하는 JSON을 보관하고 있습니다. 토큰은 비공개 시크릿 키 또는 공개/비공개 키를 사용하여 서명됩니다. 이를테면 서버는 "관리자로 로그인됨"이라는 클레임이 있는 토큰을 생성하여 이를 클라이언트에 제공할 수 있습니다. 그러면 클라이언트는 해당 토큰을 사용하여 관리자로 로그인됨을 증명합니다. 이 토큰들은 한쪽 당사자의 비공개 키(일반적으로 서버의 비공개 키)에 의해 서명이 가능하며 이로써 해당 당사자는 최종적으로 토큰이 적법한지를 확인할 수 있습니다. 일부 적절하고 신뢰할만한 수단을 통해 다른 당사자가 상응하는 공개키를 소유하는 경우 이 경우 또한 토큰의 적법성 확인이 가능합니다. 토큰은 크기가 작고 URL 안전으로 설계되어 있으며 특히 웹 브라우저 통합 인증(SSO) 컨텍스트에 유용합니다. JWT 클레임은 아이덴티티 제공자와 서비스 제공자 간(또는 비즈니스 프로세스에 필요한 클레임)의 인가된 사용자의 아이덴티티를 전달하기 위해 보통 사용할 수 있습니다.

Claim
JWT(JSON Web Token)에서 클레임(Claim)은 토큰이 담고 있는 정보의 한 조각을 의미합니다. 클레임은 토큰 사용자나 발행자에 대한 데이터, 토큰의 유효성 검증에 필요한 정보, 그리고 토큰이 부여된 권한에 대한 세부 사항 등을 포함할 수 있습니다. 클레임은 이름/값 쌍으로 구성되며, JWT의 페이로드(Payload) 부분에 위치합니다.
클레임은 JWT가 다양한 목적으로 활용될 수 있도록 유연성을 제공합니다. 예를 들어, 인증 토큰으로 사용될 때는 사용자 식별 정보나 권한을 담는 데 사용될 수 있으며, 정보 교환의 수단으로 사용될 때는 필요한 어떠한 데이터도 포함시킬 수 있습니다. 이러한 클레임의 활용은 JWT를 웹 기반 인증 및 권한 부여에 매우 유용하게 만듭니다.

 

JWT의 좋은 특징 중 하나는 다양한 방식으로 보안을 강화할 수 있다는 것입니다. JWT는 암호학적으로 서명될 수 있습니다(이를 JWS라고 부릅니다) 또는 암호화될 수 있습니다(JWE라고 함). 이것은 JWT에 강력한 검증 가능성의 계층을 추가합니다 - JWS 또는 JWE의 수신자는 서명을 검증하거나 암호를 해독함으로써 높은 수준의 신뢰성을 가질 수 있습니다. 이러한 검증 가능성의 특징은 신원 주장과 같은 안전한 정보를 전송 및 수신하는데 JWT를 좋은 선택으로 만듭니다.

마지막으로, 인간의 가독성을 위한 공백이 포함된 JSON은 좋지만, 매우 효율적인 메시지 형식을 만들지는 않습니다. 따라서 JWT는 HTTP 헤더나 URL과 같이 웹을 통해 보다 효율적으로 전송될 수 있도록 - 기본적으로 Base64URL로 인코딩된 문자열로 - 최소한의 표현으로 압축(심지어 압축될 수도 있음)될 수 있습니다.

[참고]

JWT의 구조

JWT는 세 부분으로 구성되어 있으며, 각 부분은 점 ('.')으로 구분됩니다:
1. Header (헤더)
2. Payload (페이로드)
3. Signature (서명)

 

JWT 토큰의 구조. 헤더와 본문은 리소스 서버가 토큰의 진위성을 검증하고 권한 부여 제약을 적용하는 데 필요한 세부 정보를 포함하고 있다.

1. Header

헤더는 토큰의 타입 (주로 JWT)과 사용된 알고리즘 (예: HMAC SHA256, RSA)을 명시하는 두 가지 정보를 담고 있는 JSON 객체입니다. 이 정보는 Base64Url로 인코딩되어 JWT의 첫 번째 부분을 형성합니다.

2. Payload

페이로드는 토큰에 담길 클레임(claims)을 담고 있는 JSON 객체입니다. 클레임은 토큰에 대한 속성 정보들이며, 세 가지 유형으로 나뉩니다:

• 등록된 (Registered) 클레임: 서비스에서 필요하지 않은 경우라도 이름이 충돌하지 않는 것이 보장된 클레임들입니다 (예: iss (issuer), exp (expiration time), sub (subject), aud (audience)).
• 공개 (Public) 클레임: 충돌을 방지하기 위해 IANA JSON Web Token Registry에 등록하거나 URI 형태로 정의할 수 있습니다.
• 비공개 (Private) 클레임: 두 개체 간의 합의 하에 사용되며, 등록된 이름이나 공개 클레임과 충돌하지 않는 이름을 사용합니다.

페이로드도 Base64Url로 인코딩되어 JWT의 두 번째 부분을 형성합니다.

 

Registered Claim Names

다음 클레임 이름들은 섹션 10.1에 의해 설립된 IANA "JSON Web Token Claims" 레지스트리에 등록되어 있습니다. 아래에 정의된 클레임들은 모든 경우에 필수적으로 사용하거나 구현되어야 하는 것은 아닙니다. 오히려, 이들은 유용하고 상호 운용 가능한 클레임 세트를 위한 출발점을 제공합니다. JWT를 사용하는 애플리케이션들은 어떤 특정 클레임을 사용하는지, 그리고 이들이 필수적인지 혹은 선택적인지를 정의해야 합니다. 모든 이름들은 JWT의 표현이 컴팩트해야 한다는 핵심 목표 때문에 짧습니다.

• iss (Issuer) Claim : iss (발행자) 클레임은 JWT를 발행한 주체를 식별합니다. 이 클레임의 처리는 일반적으로 애플리케이션에 특정됩니다. iss 값은 대소문자를 구분하는 문자열로, StringOrURI 값을 포함합니다. 이 클레임의 사용은 OPTIONAL 입니다. "이 클레임의 처리는 일반적으로 애플리케이션에 특정된다"는 말은, iss (발행자) 클레임을 어떻게 다룰지는 해당 애플리케이션의 목적이나 필요에 따라 달라진다는 의미입니다. 다시 말해, JWT가 사용되는 각각의 애플리케이션 또는 시스템은 iss 클레임을 포함하여, 어떤 클레임을 사용할지, 그리고 각 클레임을 어떻게 해석하고 처리할지에 대해 자체적인 규칙이나 로직을 정의할 수 있습니다.
  예를 들어, 특정 애플리케이션에서는 iss 클레임을 사용하여 토큰을 발행한 서버의 신뢰성을 검증할 수 있으며, 다른 애플리케이션에서는 이 클레임을 무시할 수도 있습니다. 또한, 특정 애플리케이션에서는 iss 클레임의 값을 특정 발행자들로 제한하여, 그들로부터 발행된 토큰만을 수락할 수도 있습니다.
  결국 이 표현은 JWT의 유연성을 강조합니다; 각 애플리케이션은 자신의 보안 요구, 로직, 그리고 상호 운용성의 요구에 맞게 클레임을 맞춤 설정하고 처리할 수 있다는 것을 의미합니다.
• sub (Subject) Claim : sub (주제) 클레임은 JWT의 subject가 되는 principal 를 식별합니다. JWT 내의 클레임들은 보통 principal에 대한 진술입니다. 이 subject 값은 발행자의 컨텍스트에서 지역적으로 고유하거나 전 세계적으로 고유해야 합니다. 이 클레임의 처리는 일반적으로 애플리케이션에 특정됩니다. "sub" 값은 대소문자를 구분하는 문자열로, StringOrURI 값을 포함합니다. 이 클레임의 사용은 OPTIONAL 입니다.
• aud (Audience) Claim : aud(audience : 토큰 대상) 클레임은 JWT의 대상 수신자를 식별합니다. JWT를 처리하려는 각 주체는 대상 클레임의 값으로 자신을 식별해야 합니다. 이 클레임이 존재할 때 클레임을 처리하는 주체가 aud 클레임의 값으로 자신을 식별하지 않으면 JWT를 거부해야 합니다. 일반적인 경우 aud 값은 각각 StringOrURI 값을 포함하는 대소문자 구분 문자열의 배열입니다. JWT에 하나의 대상이 있는 특별한 경우에 aud 값은 StringOrURI 값을 포함하는 대소문자를 구분하는 단일 문자열일 수 있습니다. 대상 값의 인터프리테이션은 일반적으로 애플리케이션에 따라 다릅니다. 이 클레임의 사용은 OPTIONAL 입니다.
• exp (Expiration Time) Claim : exp (만료 시간) 클레임은 이 JWT가 처리되어서는 안 되는 만료 시간을 식별합니다. exp 클레임의 처리는 현재 날짜/시간이 exp 클레임에 나열된 만료 날짜/시간 이전이어야 한다는 것을 요구합니다. 구현자는 시간 차이를 고려하여 소량의 여유 시간을 제공할 수 있으며, 보통 몇 분을 넘지 않습니다. 그 값은 NumericDate 값을 포함하는 숫자여야 합니다. 이 클레임의 사용은 OPTIONAL 입니다.
• nbf (Not Before) Claim : nbf (not before) 클레임은 JWT가 처리되어서는 안 되는 시간을 명시합니다. nbf 클레임의 처리는 현재 날짜/시간이 nbf 클레임에 명시된 not-before 날짜/시간 이후거나 같아야 합니다. 구현자는 시계 오차를 고려하여 소량의 여유를 둘 수 있으며, 이는 보통 몇 분을 넘지 않습니다. 그 값은 NumericDate 값을 포함하는 숫자여야 합니다. 이 클레임의 사용은 선택적입니다.
• iat (Issued At) Claim : iat (issued at) 클레임은 JWT가 발급된 시간을 식별합니다. 이 클레임은 JWT의 연령을 판단하는 데 사용될 수 있습니다. 그 값은 NumericDate 값을 포함하는 숫자여야 합니다. 이 클레임의 사용은 선택적입니다.
• jti (JWT ID) 클레임 : jti (JWT ID) 클레임은 JWT에 대한 고유 식별자를 제공합니다. id 값은 다른 데이터 객체에 우연히 동일한 값이 할당될 확률이 무시할 만큼 작도록 할당되어야 합니다. 만약 애플리케이션이 여러 발급자를 사용하는 경우, 다른 발급자들이 생성한 값 사이의 충돌도 방지해야 합니다. jti 클레임은 JWT가 재사용되는 것을 방지하는 데 사용될 수 있습니다. jti 값은 대소문자를 구분하는 문자열입니다. 이 클레임의 사용은 선택적입니다.

예를 들어,

String jws = Jwts.builder()

    .issuer("me")
    .subject("Bob")
    .audience().add("you").and()
    .expiration(expiration) //a java.util.Date
    .notBefore(notBefore) //a java.util.Date
    .issuedAt(new Date()) // for example, now
    .id(UUID.randomUUID().toString()) //just an example id

    /// ... etc ...

 

 

Public Claim Names

클레임 이름은 JWT를 사용하는 이들이 원하는 대로 정의할 수 있습니다. 그러나, 충돌을 방지하기 위해, 새로운 클레임 이름은 섹션 10.1에 의해 설립된 IANA "JSON Web Token Claims" 레지스트리에 등록되거나 충돌 방지 이름을 포함하는 공개 이름이어야 합니다. 각 경우에, 이름이나 값을 정의하는 사람은 클레임 이름을 정의하는데 사용하는 네임스페이스의 일부를 제어하고 있다는 것을 확실히 하기 위해 합리적인 예방 조치를 취해야 합니다.

 

Custom Claims

위에서 보여준 표준 설정 메소드 클레임과 일치하지 않는 하나 이상의 사용자 정의 클레임을 설정해야 하는 경우, 필요에 따라 한 번 이상 JwtBuilder의 claim 메소드를 호출하기만 하면 됩니다.

String jws = Jwts.builder()

    .claim("hello", "world")

    // ... etc ...

 

claim이 호출될 때마다, 그것은 단순히 내부 Claims 빌더에 키-값 쌍을 추가하며, 기존에 동일한 이름을 가진 키/값 쌍을 잠재적으로 덮어쓸 수 있습니다.

명백하게, 표준 클레임 이름에 대해서는 claim을 호출할 필요가 없으며, 이는 가독성을 향상시키므로 표준적인 각각의 타입-안전한 명명된 빌더 메소드를 대신 호출하는 것이 권장됩니다.

 

3. Signature

서명은 헤더의 인코딩된 값과 페이로드의 인코딩된 값을 합친 후, 제공된 비밀키 혹은 공개/비공개 키 쌍을 사용하여 알고리즘에 따라 생성됩니다. 이 서명은 토큰이 중간에 변조되지 않았음을 검증하는 데 사용됩니다.

 

HMAC tag는 비밀 키를 사용하여 인코딩된 JSON claims를 기반으로 계산됩니다. 그런 다음, HMAC tag 자체를 URL-safe Base64 형식으로 인코딩하고, 토큰에 추가하며 구분 기호로 period(.)을 사용합니다. period는 Base64 인코딩에서 유효한 문자가 아니므로, 나중에 이 구분 기호를 사용해 tag를 찾을 수 있습니다.

 

JWT의 사용 방법

1. 인증: 사용자가 로그인을 하면, 서버는 사용자의 정보를 기반으로 JWT를 생성하고 이를 사용자에게 반환합니다. 사용자는 이후의 요청에 이 토큰을 포함시켜 서버에 보냄으로써 자신을 인증할 수 있습니다.
2. 정보 교환: JWT는 두 개체 사이에서 안전하게 정보를 교환할 수 있는 방법을 제공합니다. 서명이 있기 때문에, 정보가 보내는 도중에 변경되었는지 확인할 수 있습니다.

장점

• 자가 포함(Self-contained): JWT는 필요한 모든 정보를 자체적으로 갖고 있어, 데이터베이스 등의 외부 소스에 다시 접근할 필요가 없습니다.
• 간결함(Compact): JWT는 매우 컴팩트하여 HTTP 헤더에 쉽게 포함시켜 전송할 수 있습니다.
• 모바일 친화적: 모바일 환경에서도 잘 작동합니다.
• 크로스 도메인 인증: 쿠키를 사용하지 않으므로 크로스 도메인 요청에 유용합니다.

단점

• 보안: 페이로드는 암호화되지 않고 Base64 인코딩만 되므로, 중요한 정보는 페이로드에 넣지 않아야 합니다. 필요한 경우, JWT 전체를 암호화해야 합니다.
• 토큰 길이: 데이터가 많을수록 JWT의 길이가 길어질 수 있어, 네트워크 오버헤드가 증가할 수 있습니다.
• 상태 유지: JWT는 상태를 유지하지 않는 토큰이므로, 일단 발급되면 만료 시간이 될 때까지 유효합니다. 따라서 서버 측에서 토큰을 무효화하는 것이 복잡할 수 있습니다.

 

Refresh Token

JWT(JavaScript Web Token)의 Refresh Token은 주로 인증 시스템에서 사용자의 세션을 안전하게 유지하고, 액세스 토큰(Access Token)이 만료되었을 때 새로운 액세스 토큰을 발급받기 위해 사용됩니다. 이 과정은 사용자의 로그인 상태를 오랜 시간 동안 유지하기 위해 필요합니다. 여기서 액세스 토큰과 리프레시 토큰의 역할을 구분하는 것이 중요합니다.

• 액세스 토큰: 사용자가 인증 후 서버로부터 받는 토큰으로, 보통 짧은 유효 기간을 가집니다. 이 토큰은 사용자가 리소스에 접근할 때마다 인증을 위해 사용됩니다.
• 리프레시 토큰: 액세스 토큰과 함께 발급되며, 보통 훨씬 더 긴 유효 기간을 가집니다. 액세스 토큰이 만료되었을 때, 사용자가 다시 로그인하지 않고도 이 리프레시 토큰을 사용해 새로운 액세스 토큰을 발급받을 수 있습니다.

사용되는 상황

1. 액세스 토큰 만료: 사용자의 액세스 토큰이 만료되었지만, 사용자가 여전히 서비스를 이용하고 싶어 할 때, 리프레시 토큰을 사용하여 새로운 액세스 토큰을 발급받을 수 있습니다.
2. 보안 강화: 짧은 유효 기간을 가진 액세스 토큰을 사용함으로써 보안성을 강화할 수 있으며, 리프레시 토큰을 사용해 장기간 인증 상태를 유지할 수 있습니다. 이는 액세스 토큰이 탈취당하더라도, 짧은 유효 기간 동안만 유효하기 때문에 보안 위험을 줄일 수 있습니다.
3. 사용자 경험 향상: 사용자가 자주 로그인하는 번거로움 없이 서비스를 지속적으로 이용할 수 있도록 돕습니다. 사용자는 리프레시 토큰 덕분에 오랜 기간 동안 자동으로 세션이 유지될 수 있습니다.

리프레시 토큰의 사용은 토큰 기반 인증 시스템에서 중요한 역할을 하며, 사용자의 편의성과 보안 모두를 향상시키는 데 기여합니다.

 

리프레시 토큰 관리

리프레시 토큰을 데이터베이스에 저장하는 주된 이유는 보안, 관리, 유효성 검증을 강화하기 위함입니다. 여기에는 몇 가지 중요한 측면이 포함됩니다:

1. 보안 강화

• 토큰 도난 방지: 데이터베이스에 리프레시 토큰을 저장하면, 만약 토큰이 도난 당하더라도 도난당한 토큰을 즉시 무효화할 수 있습니다. 이는 시스템이 도난당한 토큰의 사용을 감지하고, 해당 토큰을 데이터베이스에서 삭제하거나 무효화함으로써 가능합니다.
• 안전한 토큰 재발급: 리프레시 토큰이 데이터베이스에 저장되어 있으면, 애플리케이션은 토큰 재발급 요청이 유효한지를 검증하기 위해 데이터베이스에 저장된 정보를 사용할 수 있습니다. 이는 안전한 토큰 재발급 과정을 보장합니다.

2. 중앙 집중식 관리

• 토큰 라이프사이클 관리: 데이터베이스에 토큰을 저장하면, 애플리케이션은 리프레시 토큰의 생성, 갱신, 만료 및 삭제를 쉽게 관리할 수 있습니다. 이는 토큰 라이프사이클을 효과적으로 관리하는 데 도움이 됩니다.
• 사용자별 토큰 관리: 사용자별로 발급된 리프레시 토큰을 관리할 수 있으며, 필요한 경우 특정 사용자의 토큰을 무효화하거나 갱신할 수 있습니다.

3. 유효성 검증

• 토큰 유효성 검증: 데이터베이스에 저장된 토큰과 요청으로 받은 토큰이 일치하는지 확인함으로써, 토큰의 유효성을 검증할 수 있습니다. 이는 토큰의 안전한 사용을 보장합니다.
• 토큰 만료 관리: 데이터베이스에 토큰의 만료 시간을 함께 저장함으로써, 만료된 토큰을 쉽게 식별하고 처리할 수 있습니다. 만료된 토큰은 자동으로 무효화되거나 시스템에서 삭제될 수 있습니다.

4. 규정 준수 및 감사

• 감사 및 로깅: 데이터베이스에 리프레시 토큰을 저장하면, 토큰 발급 및 사용에 대한 로깅과 감사 트레일을 유지할 수 있습니다. 이는 규정 준수 및 보안 감사에서 중요한 요소입니다.

리프레시 토큰을 데이터베이스에 저장하는 것은 애플리케이션의 보안을 강화하고, 토큰 관리를 용이하게 하며, 보다 안전한 사용자 인증 메커니즘을 구현하는 데 중요한 역할을 합니다.