들어가기 전에
인증과 인가
인증은 사용자의 신원을 입증하는 과정이다. 예를 들어 회사에 지문이나 신분증으로 회사 사람인 것을 입증하는 것이다.
인가는 사이트의 특정 부분에 접근할 수 있는지 권한을 확인하는 작업이다. 예를 들어 내가 회사원이라고 해도 모든 곳에 접근 가능한 것은 아니다. 보안 담당자만이 접근할 수 있는 사무실은 들어가지 못한다. 일반 사원, 보안 담당자등 권한에 따라 접근할 수 있는지가 다르다.
JWT는 왜 필요할까?
인증/인가 방식 중에 하나이다.
stateless하므로 서버가 상태를 보관하고 있지 않은 특징이 있다. 서버는 한번 발급한 토큰에 대해서 제어권을 가지고 있지 않다.
그런데 JWT는 외부에 노출되는 경우 치명적인 보안 이슈가 발생할 수 있다. 서버는 탈취한 것을 알지 못한채 인증을 통과시키게 된다.
그렇기 때문에 탈취되더라도, 해커에 의해 남용될 수 있는 시간을 최소화 할 수 있도록 유효기간을 짧게한다.
그렇지만 로그인을 자주 하게 되어 사용자 경험적으로 좋지 않은데 어떻게 해야할까?
해결책은 유효기간이 다른 Access Token와 Refresh Token을 사용하면 된다.
Access Token과 Refresh Token
- Access Token
- 인증 인가 서비스 구현
- 유효기간이 짧다
- Refresh Token
- Access Token 재발급 용도
- 유효기간이 길다.
- 평소에 API 통신할 때는 Access Token을 사용하고, Refresh Token은 Access Token이 만료되어 갱신될 때만 사용한다.
즉, 통신과정에서 탈취당할 위험이 큰 Access Token의 만료 기간을 짧게 두고 Refresh Token으로 주기적으로 재발급함으로써 피해를 최소화한 것이다.
적절한 주기가 있을까?
Access Token : 보통은 시간단위로 2시간 정도 → 좀 더 생각생각해보기
Refresh Token : 2주 정도 → 한달로 하자
어디에 저장할까?
Frontend 에서 고려
Access Token
- Local storage
- 사용자가 지우지 않는 이상 계속 브라우저에 남아 있다
- Session Storage
- 윈도우나 브라우저 탭을 닫을 경우에 지워진다.
하지만 둘다 자바스크립트로 데이터를 저장하고 꺼낼 수 있기 때문에 XSS 공격에 취약하다는 단점이 있다
- Cookie
- 자바스크립트로 접근이 가능하지만,HTTP ONLY 옵션을 설정하여 접근하는 것을 방지할 수 있다.
- CSRF(cross-site Request Forgery) 공격에 취약하여 로그인된 상태에서 특정 동작을 요청하게 만든다.
결론 : CSRF는 쿠키에 저장된 토큰의 값을 직접적으로 가져오지는 않기 때문에 쿠키에 토큰을 저장하는 것이 합리적이다.
Backend 에서 고려
Refresh Token
- Redis
- 저장소가 필요
'Backend > JWT' 카테고리의 다른 글
[JWT] JWT 인증/인가 적용기(4) - AccessToken이 만료된 경우 (0) | 2024.02.28 |
---|---|
[JWT] JWT는 어디에 담아 클라이언트와 요청/응답할까 (0) | 2024.02.27 |
[JWT] JWT 인증/인가 적용기(3) - 로그인 (2) | 2024.02.27 |
[JWT] JWT 인증/인가 적용기(2) - Spring Security를 통한 JWT 적용 (0) | 2024.01.29 |
[JWT] JWT 인증/인가 구현기(1) - Spring Security 인증 구조 (0) | 2024.01.27 |