24/07/30(화) 88번째 TIL : Access token & Refresh token 요청/응답 방식과 양식

 

 

문제

액세스 토큰과 리프레쉬 토큰을 어떤 응답 방식과 양식으로 담아야 하는지. 

---

상황

얼마 전 개인 프로젝트에서 인증 부분을 실제 서비스를 염두에 둔다면 어떤 식으로 처리를 할지 고민했던 적이 있다. 

 

JWT로 Access token, Refresh token을 이용해서 인증 방식을 택했고, 로그인 시

• 액세스 토큰을 응답 헤더의 Access-Token 키에,
• 리프레쉬 토큰을 HttpOnly 쿠키로 Refresh-Token 키에

넣어서 보내주었다. 

 

액세스 토큰을 헤더에, 리프레쉬 토큰을 쿠키에 넣은 이유는 아래와 같았다. 

1. 프론트에서는 액세스 토큰을 로컬스토리지에 저장하게 하고, 리프레쉬 토큰은 쿠키 저장소에 저장되어 저장소를 분리시켰다. 만약 한 저장소가 뚫려도 다른 저장소의 토큰은 안전하도록 의도를 담았다.
2. 리프레쉬 토큰을 HttpOnly 로 하여 JS가 접근 불가하게 막으면서, 특별한 처리를 하지 않아도 요청 쿠키에 자동으로 리프레쉬 토큰을 보관하도록 했다.

---

해결

하지만 오늘 튜터님에게 물어보니 보통은 로컬스토리지에 모두 담는다고 했다. 이유는 다음과 같다. 

1. 쿠키에 담으면 웹 외의 클라이언트에서는 접근할 수 없다. 
2. 시크릿 모드를 사용하는 사용자는 인증할 수 없다. 

 

그리고 또 한 가지 안 사실은 OAuth2 표준에서는 인증 요청 시에 액세스 토큰을 요청 헤더의 Authorization 키에 Bearer <Access token> 으로 넣어야 한다. (출처 RFC 6750 - section 2.1)

 

또한 액세스 토큰과 리프레쉬 토큰의 응답으로는 응답 바디에 보관하여 보내는 것 같다. (출처 RFC 6750 - section 4)

OAuth2 더 공부해야할듯.. 

또 액세스 토큰을 재발급 받을 시에는 요청 바디에 refresh token을 넣어서 보낸다. (출처 RFC 6749 - section 6)

---

정리 

1. 인증 시 응답 바디에 Access token과 Refresh token을 함께 응답한다. 
2. 프론트에서 요청 시 HTTP 요청 헤더의 Authorization 키에 Access token 을 넣어서 요청한다.
3. 만약 Access token이 만료되었다면 프론트는 재발급 요청을 요청 바디에 Refresh token을 넣어서 요청한다.