RefreshToken & AccessToken

1. 공통점 및 차이점

• 두 토큰 모두 JWT 기반이다
• Access Token은 API요청을 할 때 검증용 토큰으로 사용된다. 즉, 인증이 필요한 APi를 사용할때는 꼭 Access Token을 Header에 넣어서 보내야한다. ex) 유저 정보 수정, 회사 채용 공고 지원 인원 확인 등
• Refresh Token은 Access Token을 추가로 발급할 때 사용된다. Access Token을 새로고침(Refresh)하는 기능이 있기 때문에 Refresh Token 이라고 부른다.
• Access Token은 유효기간이 짧고, Refresh Token은 유효기간이 길다.
• 자주 노출되는 Access Token은 유효기간을 짧게 해서 Token이 탈취돼도 해커가 오래 사용하지 못하도록 방지할 수 있다.
• 상대적으로 노출이 적은 Refresh Token의 경우 Access Token을 새로 발급받을때만 사용되기 때문에 탈취 가능성이 적다.

2. 토큰 기반 인증의 이점

• 서버 리소스 절약과 확장성: 토큰 기반 인증은 사용자의 인증 정보를 서버가 아닌 클라이언트에 저장합니다. 이는 서버가 사용자의 세션 상태를 유지할 필요가 없어 서버 리소스를 절약하고, 여러 서버에 걸쳐 애플리케이션을 쉽게 확장할 수 있게 해줍니다.
• 무상태(stateless) 아키텍처와의 호환성: RESTful API는 상태 정보를 유지하지 않는 무상태 프로토콜을 사용합니다. 토큰 기반 인증은 이러한 아키텍처에 잘 맞으며, 각 요청이 독립적으로 처리될 수 있도록 해줍니다.

3. JWT (JSON Web Tokens)의 구조

• Header, Payload, Signature: JWT는 세 부분으로 구성됩니다. Header는 토큰의 타입과 사용된 알고리즘을 명시합니다. Payload에는 클레임(사용자에 대한 정보 및 추가 데이터)이 포함되어 있습니다. Signature는 토큰의 무결성을 보장하고, 서버에서만 생성할 수 있습니다.
• JWT 사용의 장점: JWT는 자체적으로 사용자 정보를 포함하기 때문에 별도의 데이터베이스 조회 없이도 사용자의 인증 상태를 검증할 수 있습니다. 이는 처리 속도를 향상시키고, 시스템의 효율성을 높입니다.

4. Access Token과 Refresh Token의 보안 측면

• Access Token의 위험성: 짧은 유효기간은 Access Token이 탈취되더라도 공격자가 제한된 시간 동안만 사용할 수 있게 합니다. 이는 잠재적인 피해를 최소화하는 중요한 보안 조치입니다.
• Refresh Token의 보안 관리: Refresh Token은 더 긴 유효기간을 가지므로, 안전한 저장소에 보관하고, 액세스 토큰이 필요할 때만 사용하여 보안 위험을 최소화해야 합니다.

5. 토큰 갱신 과정

• 단계별 갱신 과정: 사용자의 Access Token이 만료되면, 클라이언트는 저장된 Refresh Token을 사용하여 인증 서버에 새 Access Token을 요청합니다. 인증 서버는 Refresh Token의 유효성을 검증한 후 새 Access Token을 발급합니다.
• 보안 문제와 해결 방법: 갱신 과정 중 Refresh Token이 탈취될 위험이 있으므로, SSL/TLS 같은 안전한 통신 채널을 사용하고, Refresh Token도 정기적으로 갱신하는 방법을 사용할 수 있습니다.

6. 토큰 기반 인증의 한계와 해결책

• 토큰 무효화 문제: 토큰 기반 인증 시스템의 한계 중 하나는 유효한 토큰이 탈취되었을 때, 이를 즉시 무효화하기 어렵다는 점입니다. 세션 기반 인증에서는 서버 측에서 사용자 세션을 즉시 종료시킬 수 있지만, 토큰은 클라이언트에 저장되므로 서버가 직접 제어할 수 없습니다.
  • 해결책: 이 문제를 해결하기 위해, 일부 시스템에서는 토큰의 유효기간을 매우 짧게 설정하고, 필요 시 자동으로 갱신합니다. 또한, "토큰 블랙리스트" 시스템을 구현하여 서버 측에서 무효화된 토큰 목록을 관리할 수 있습니다.
• 토큰 저장의 보안성: 클라이언트 측에서 토큰을 안전하게 저장하는 것도 중요한 과제입니다. 특히, XSS(크로스 사이트 스크립팅) 공격을 통해 토큰이 탈취될 수 있습니다.
  • 해결책: 토큰을 HTTPOnly 쿠키에 저장하여, JavaScript를 통한 접근을 차단함으로써 XSS 공격으로부터 토큰을 보호할 수 있습니다. 또한, CSP(Content Security Policy)를 사용하여 안전하지 않은 스크립트 실행을 방지할 수 있습니다.

7. 표준과 권장 사항

• OAuth 2.0과 OpenID Connect: OAuth 2.0은 인증 및 권한 부여를 위한 개방형 표준 프로토콜로, 사용자가 자신의 정보에 대한 접근 권한을 안전하게 타사 애플리케이션에 부여할 수 있도록 설계되었습니다. OpenID Connect는 OAuth 2.0 위에 구축된 인증 계층으로, 단순히 권한 부여를 넘어 사용자 인증을 처리할 수 있습니다.
  • 이점: 이 표준들을 사용함으로써, 개발자는 보안성이 검증된 프로토콜을 기반으로 인증 시스템을 구축할 수 있으며, 사용자는 다양한 서비스에 걸쳐 일관된 인증 경험을 가질 수 있습니다.
• 구현 시 고려사항: OAuth 2.0과 OpenID Connect를 구현할 때는 몇 가지 중요한 고려사항이 있습니다. 예를 들어, "리다이렉션 URI"는 서비스에 등록된 주소와 정확히 일치해야 하며, "Access Token"과 "Refresh Token"의 저장 및 관리 방법을 신중히 고려해야 합니다.
  • 권장 사항: 토큰의 안전한 전송과 저장을 위해 항상 HTTPS를 사용하고, 가능한 경우 토큰에 대한 암호화 처리를 고려해야 합니다. 또한, 정기적인 보안 감사와 토큰의 유효기간 관리를 통해 시스템의 보안을 유지해야 합니다.