일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- 디자인 패턴
- 디자인패턴
- JavaScript
- 단기개발자코스
- 빈 충돌
- Python
- TiL
- 파이썬
- 프로그래머스 이중우선순위큐
- KPT회고
- jwttoken
- 코딩테스트 준비
- 개발자부트캠프추천
- DesignPattern
- 구글 OAuth login
- 99클럽
- 개발자 취업
- Spring multimodule
- infcon 2024
- @FeignClient
- 항해99
- jwt
- 1주일회고
- 전략패턴 #StrategyPattern #디자인패턴
- spring batch 5.0
- 취업리부트코스
- 커스텀 헤더
- 인프콘 2024
- 프로그래머스
- 빈 조회 2개 이상
- Today
- Total
m1ndy5's coding blog
ALL ABOUT REFRESH TOKEN 본문
JWT 로그인을 공부하고 구현하면서 Refresh Token의 필요성, 저장 위치와 같은 의문점이 들어 정리하는 글이다.
Refresh Token이란?
JWT 토큰은 사용자의 신원이나 권한의 정보를 담고 있는 토큰이다.
따라서 사용자는 이 JWT 토큰을 사용하여 안전하게 통신할 수 있다.
하지만 이 토큰의 가장 큰 문제점은 탈취를 당할 수 있다는 것이다!!
해커가 토큰을 탈취해 서버에 접근한다면 서버 입장에서는 토큰의 주인이 접근한다고 생각할 것이다.
만약 이 토큰에 유효기간이 없다면 해커는 언제고 이 탈취한 토큰을 가지고 멀쩡한 사용자 행세할 것이다!
이를 막기 위해 토큰의 유효기간을 짧게 두고, 토큰의 유효기간이 끝나면 Refresh Token을 가지고 새로운 토큰 발행을 요청한다.
동작 과정
로그인 성공 -> 유효기간이 짧은 Access Token과 유효시간이 더 긴 Refresh Token을 발급 -> 인가가 필요한 요청에 Access Token 사용 -> Access Token의 유효기간이 끝남 -> Refresh Token을 사용해 Access Token 재발급 -> Refresh Token이 만료되면 재인증 진행
하지만 이런 의문이 들었다.
프로젝트를 진행하면서 Access Token과 Refresh Token 둘 다 쿠키에 저장을 했다.
Access Token을 빼갈정도의 능력이면 같이 저장되어 있는 Refresh Token도 빼갈 수 있지 않을까??
Refresh Token은 왜 필요할까?
Refresh Token의 필요성
물론 Refresh Token이 Access Token과 마찬가지로 쿠키에 저장되어 있다면 Refresh Token도 탈취될 가능성이 존재한다.
실제로 Refresh Token이 Access Token보다 더 많은 권한을 갖고 있어 Refresh Token이 유출될 경우 보안 위험은 더욱 커질 수 있다.
하지만 Refresh Token을 사용하면 Access Token이 단독으로 탈취됐을 때 영향을 최소화할 수 있다.
또한 Access Token을 주기적으로 갱신함으로써 사용자 입장에서 자주 로그인해야하는 경험을 줄여줄 수 있다.
마지막으로 Refresh Token을 사용하여 새로운 Access Token을 발급받을 때 사용자의 권한을 다시 확인하고 필요한 경우에만 새로운 Access Token을 발급할 수 있어 권한 부여에 대해 더 많은 제어를 가능하게 한다.
앞서 말했듯이 탈취될 가능성은 존재하기에 완벽하게 보안을 제공한다고는 할 수 없다.
따라서 Refresh Token을 안전하게 저장 및 전송해야하고 적절한 만료 시간을 설정해야 한다.
그렇다면 Refresh Token은 어디에 저장하는 것이 좋을까??
Refresh Token의 저장 방법
- HTTP Only 쿠키: Refresh Token을 클라이언트 측에서 직접 접근할 수 없도록 HTTP Only 쿠키에 저장한다. 이렇게 하면 JavaScript를 통한 접근이 불가능하며, 대부분의 XSS(Cross-Site Scripting) 공격으로부터 보호된다.
- Secure 쿠키: Refresh Token을 HTTPS 연결을 통해만 전송되도록 Secure 쿠키를 사용한다. 이렇게 함으로써 네트워크를 통한 중간자 공격을 방지할 수 있다.
- 토큰 저장소: 클라이언트 측에서 Refresh Token을 직접 저장하는 대신, 서버 측에 안전한 저장소를 사용하여 토큰을 저장한다. 이를 통해 클라이언트 측에서 토큰을 안전하게 저장하고, 서버 측에서 토큰을 관리할 수 있다.
- 토큰 암호화: Refresh Token을 암호화하여 저장하고, 필요할 때만 서버에서 해당 토큰을 해독하여 사용한다. 이를 통해 토큰이 노출되었을 때에도 토큰을 해독할 수 없도록 보안을 강화할 수 있다.
- 토큰 만료 시간 관리: Refresh Token의 만료 시간을 적절히 관리하여, 오래된 토큰이 사용되지 않도록 한다. 또한, 사용자가 로그아웃할 때나 일정 기간 이상 사용하지 않을 때 Refresh Token을 무효화하여 보안을 강화할 수 있다.
이러한 방법들을 통해 Refresh Token을 안전하게 저장하고 관리할 수 있다.
Refresh Token이 가지고 있어야하는 정보들
리프레시 토큰에는 사용자를 식별하고 인증하는 데 필요한 최소한의 정보가 포함되어야 한다.
이러한 정보는 서버 측에서 토큰을 검증하고 사용자의 신원을 확인하는 데 사용된다.
1. 사용자 식별자 : 사용자를 고유하게 식별할 수 있는 정보 ex) ID, 이메일 등
2. 토큰 타입 : 어떤 종류의 토큰인지 나타내는 정보 ex) 리프레시 토큰 등
3. 토큰 발급일(iat) : 토큰이 발급된 시간
4. 토큰 만료 시간(exp) : 토큰이 만료되는 시간 -> 토큰의 유효성 검증
5. 클라이언트 정보 : 리프레시 토큰을 사용하여 새로운 엑세스 토큰을 발급할 때, 클라이언트 정보가 필요할 수 있음 ex) 클라이언트 ID, 클라이언트 Type
이 외에도 추가적인 정보가 포함될 수 있지만 보안을 고려한다면 최소한의 정보만을 포함하는 것이 좋고 민감한 정보는 포함하지 않아야 한다. 추가적인 정보가 필요한 경우에는 애플리케이션의 보안 요구사항에 맞게 정확히 설계해야한다.
'백엔드 with java > spring' 카테고리의 다른 글
JWT Login과 Cookie (feat. Redirect) (0) | 2024.05.19 |
---|---|
About Setter (feat. Builder) (0) | 2024.01.17 |
Entity 대신 DTO를 반환해야하는 이유 (0) | 2024.01.17 |
UnsatisfiedDependencyException (feat.영한님 강의) (2) | 2023.12.05 |
Spring Security UserDetails, UserDetailsService (1) | 2023.10.11 |