JWT
- Json Web Token
- Header, payload, signature로 이루어짐
- Header은 어떤 방식, 알고리즘을 사용해서 토큰화했는지 명시
- Payload는 사용자가 담고자 하는 정보를 담는 곳
- Signature는 토큰의 유효성 여부에 대한 정보를 담는 곳
- 피싱하는 사이트나 앱들은 Token 탈취보다는 개인 정보를 탈취해서 password를 가져가려는 것이 목표
- 중요한 비즈니스 로직에 2FA, OTP 같은 것을 추가로 걸어서 최대한 방어하려고 한다.
- 결제나 암호/개인저보와 관련된 부분에 접근할 때에는 패스워드를 다시 입력하거나(토큰 재발행), 전화 OTP 인증, Authenticator 등을 이용
Token
- 충분히 정보를 옮기는 데이터 조각
- 사용자의 신원 또는 행위를 수행하기 위한 인가를 결정하는 유용한 과정
- 인증, 인가 과정에서 사용
- Access Token, Refresh Token이 있다.
- Access Token
- 로그인을 하면 access token이 생긴다.
- 어떤 작업 또는 자원을 수행하기 위해 인증이 필요한데 access token은 서버에게 이 클라이언트가 인증을 받았다고 알려준다.
- bearer 토큰이다. 누군가가 토큰을 사용할 수 있다. 😮
- 해결방안
- access token의 생명주기를 짧게한다.(하루 또는 한 시간)
- 해결방안
- JS 로컬 변수에 저장하고, HTTP 헤더에 bearer 토큰으로 담아서 매 요청마다 보내기
- Refresh Token
- Refresh Token이 유효하고 만료되지 않았으면 새로운 Access Token을 발급한다.
- 매번 Access Token을 갱신해가면서 사용하는 로직
- silent token refresh
- 유저가 다시 로그인을 하지 않아도 된다.
- 보안성, 사용성에 도움을 준다.
- Refresh Token은 무한히 사용할 수 있다.
- 해결방안
- 새로운 Access Token을 발급 후에 Refresh Token도 새롭게 갱신되면 된다.
- 해결방안
- 유효기간은 2주로도 잡기도 한다.(상황에 따라서 설정한다.)
- secure HTTP only cookie에 저장
- Refresh Token이 유효하고 만료되지 않았으면 새로운 Access Token을 발급한다.
- Access Token
Token을 저장하는 방법
LocalStorage | XSS 공격에 취약 | |
Cookies | CSRF 공격에 취약 | refresh token을 secure HTTP only cookie에 저장 |
Memory | 웹페이지를 새로고침하거나 브라우저를 새로 열면 사라진다. | access token을 memory에 저장 cookie에 있는 refresh token을 이용해서 다시 access token을 발급받기 |
Silent Refresh
브라우저가 새로고침되거나 access token이 만료되었을 때 유효한 refresh token을 이용해서 자동으로 새로운 access token을 생성하는 매커니즘
client side에서 이것을 다루도록 한다.
server side에서 다루도록 하는 것은 좋은 아이디어가 아니라고 한다.
참고 👇
https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/
https://dev.to/itsnikhil/implementing-silent-refresh-of-jwt-4h7
반응형
'Web' 카테고리의 다른 글
Swagger (0) | 2023.01.14 |
---|---|
nGrinder 설치 (0) | 2023.01.03 |
CORS (0) | 2022.10.07 |
CSRF (0) | 2022.09.15 |
[Error] Request method 'DELETE' not supported (0) | 2022.06.04 |