Token 담을 위치 Cookie VS header authorization

[Kimhan-nah]

현재

• refresh token은 일단 없고 access token은 cookie에 담아 backend에서만 검증하고 있습니다

의견

• 로그인한 유저만 접근 가능한 페이지에서 토큰이 만료되어 없는 경우 프론트에서 request 보내지 않고 미리 처리할 수 있음
• 프론트가 위와 같이 미리 처리하려면 cookie를 확인하거나, header authorization에 토큰이 존재해야 함
• 전자의 경우(프론트에서 cookie 접근하려면) 외부 라이브러리를 사용해야 함
• token을 cookie에 담을지, header authorization에 담을지 얘기해보아요

틀린 부분 있거나 의견 있으면 알려주세용

[nyeoni]

저희가 현재 임시 토큰 / 엑세스 토큰 두 가지 종류 가 있는데 이 두 가지 토큰을 아래와 같이 처리하는 걸 건의 드립니다.

1. 임시 토큰

• 프론트에서 접근할 필요 X
• httpOnly + secure 쿠키에 저장

2. 엑세스 토큰

• 프론트에서 접근할 필요 O (auth 확인)
• Authorization 헤더에 엑세스 토큰을 넣어 전달

[nyeoni]

추가적으로 아까 얘기했던 refresh 토큰도 생각해보았는데, refresh 토큰 같은 경우는 secure cookie 로 저장해놓으면 로그아웃을 서버에서 해주어야 하는 문제가 해결될 것 같습니다.

[jis-kim]

작은 회의 결과 액세스 토큰은 로그인 요청 시 redirection url 에 query string 으로 붙여서 보내는 것으로 결정되었습니다.

• client 는 토큰 값을 읽어서 local storage 에 저장하고, 인증이 필요한 모든 요청에 Authorization: credential(참고) 형태로 헤더 설정하여 보냅니다.
• server 는 해당 헤더 필드를 검증 후 인증된 유저라면 데이터를 응답합니다.
  refresh token 이 추후 추가되었을 때, refresh 로 access token 발급 요청하는 api 도 필요할 것 같습니다!

[nyeoni]

수정) 클라이언트는 토큰 값을 메모리 변수에 저장하기로 하였습니다! ㅎㅎㅎ

[nyeoni]

추가로 클라이언트 리다이렉션 url 은 /auth 로 보내주심 됩니다

[Kimhan-nah]

[결론]

1. access token은 redirect url에 query로 담아서 response
2. client는 '메모리 변수 || storage'에 저장해서 사용
3. 이후 header authorization에 담아서 request

• unregistered를 위한 임시 token은 기존 그대로 cookie에 저장