[💌 FEATURE REQUEST] Oauth Redirect Page 로직을 생성한다

멈춰! 🖐🏻 잠시 체크 들어갑니다~

[X] 다음 페이지에서 중복되지 않음을 확인했어요. 🙆🏻
[X] 다른 분들께서 허락해주신다면, 제가 구현해보고 싶어요! 🙆🏻‍♀️

배경 및 설명

슬슬 Oauth를 위해 본격적으로 움직이려 한다.

테스트 코드에 대한 자책에서 좀 벗어나서인지, 아직 마음은 복잡하지만 제대로 프로젝트를 할 마음은 생겼다. 일단 내일이면 디자인 패턴을 모두 공부하기 때문에, 심리적인 여유가 생겼다. 따라서 현재 씨유레터 백엔드 팀의 원활한 작업을 돕기 위해, 본격적으로 움직이려 한다.

JavaScript Applications obtaining tokens directly

이를 구현하기 위해 결과적으로 리다이렉트를 클라이언트 단에서 하기로 했다. 또한 토큰을 저장할 공간은 분명 필요해 보인다. 이를 최적화하기 위한 방안을 고민하여, 멋진 Oauth를 구현하려 한다.

기대결과

사용자는 Oauth 버튼을 누르면 Oauth 로그인 페이지로 이동한다.
[사용자는 정상적으로Oauth 로그인을 했다면Redirect Page`로 이동해야 한다.
Redirect Page는 code, state를 가져와야 한다.
state는 CSRF 공격을 효과적으로 차단하기 위해 string을 Random하게 생성하도록 설계해야 한다.
Redirect Page에 들어서면 바로 를 비교하도록 설계해야 한다.
state가 유효하면 Seeyouletter Auth Server에 code, state를 전달하는 API를 추가해야 한다. (현재: 모킹할 예정이다.)
모킹한 API가 true로 반환되면 IndexPage로 이동해야 한다.
모킹한 API가 false로 반환되면 모달로 에러메시지가 나오며 LoginPage로 replace되어야 한다.

대안 제시

Cache Storage API 사용

아직 써본 적은 없지만, HTTP 상에서 캐시를 저장하는 방법으로 가장 나은 대안이라고 알려져 있다. 사용해본 적은 없어서, 이참에 이 역시 공부를 해보고 적용해보고자 한다.

참고자료

@JengYoung 안녕하세요! 해당 이슈를 잘 읽어보았는데 이해가 되지 않는 부분이 몇 가지 있어서 여쭙고자 합니다! 🤔

"Oauth 버튼을 누르면 Oauth 로그인 페이지로 이동"은 CSR이 아닌 인증 서버 SSR 방식으로 이해가 되는데 맞을까요? 물론 일반적으로는 인증 서버에서 로그인 페이지를 렌더링하는 방식이 사용되고 있지만 피그마 기준으로 보았을 때, 씨유레터에서는 로그인 페이지를 CSR로 하는 것으로 이해했는데 해당 문구에서 혼란이 오는 것 같습니다.😂 만약 정해지지 않은 부분이라면 논의가 필요해보입니다 😀
authorization request에서 code_challenge, nonce 파라미터, token request에서 code_verifier 파라미터를 전달하는 로직이 추가적으로 필요할 것 같습니다! SPA(public client)에서 안전하게 엑세스 토큰을 발급받기 위해서는 PKCE의 사용이 필수적으로 보입니다 🙏

혹시 확인하셨는지는 모르겠지만 인증 flow diagram을 간단하게 그려보았습니다. 씨유레터 인증 서버에 로그인 후, 엑세스 토큰을 발급 받는 과정을 slient renew 과정부터라고 이해해주시면 될 것 같습니다. 아직 정리되지 않은 미완성 상태이지만 참고하시면 도움이 될 것 같습니다!

핳... 잘못 확인해서 시간을 꽁으로 날렸네요 😭 답변을 수정합니다!

@sinbom 엇, 우선 로직에 대한 이해가 서로 다른 것 같아보여요. 조정이 필요할 것 같습니다!

다르다고 생각한 부분

현재 작성해주신 피그마 방식

먼저 이해를 돕기 위해 작성해주신 점 감사드려요! 🙏🏻

제안하는 변경 방식

현재 클라이언트 측에서 생각하고 있는 로그인 방식은 다음과 같습니다!

수정한 부분은 하이라이트해서 표시했어요. 확인 부탁드려요! 다음은 질문에 대한 답변입니다 🙆🏻‍♀️🙆🏻

질문

"Oauth 버튼을 누르면 Oauth 로그인 페이지로 이동"은 CSR이 아닌 인증 서버 SSR 방식으로 이해가 되는데 맞을까요? 물론 일반적으로는 인증 서버에서 로그인 페이지를 렌더링하는 방식이 사용되고 있지만 피그마 기준으로 보았을 때, 씨유레터에서는 로그인 페이지를 CSR로 하는 것으로 이해했는데 해당 문구에서 혼란이 오는 것 같습니다.😂 만약 정해지지 않은 부분이라면 논의가 필요해보입니다 😀

authorization request에서 code_challenge, nonce 파라미터, token request에서 code_verifier 파라미터를 전달하는 로직이 추가적으로 필요할 것 같습니다! SPA(public client)에서 안전하게 엑세스 토큰을 발급받기 위해서는 PKCE의 사용이 필수적으로 보입니다 🙏

1. 인증 서버에서의 SSR이 아닌지?

헉, 제가 혼자 한다는 생각(...)에 모든 내용을 생략하고 설명했어요. 맞습니다! <Kakao, Naver>에서 제공하는 SDK는 SSR을 통해 자신들의 URI로 이동시키도록 해요.

다만 CSR 부분이 존재한다고 회의 때 설명을 드렸고, 이것이 커뮤니케이션 상의 문제점으로 발견된 것 같아요! 이에 대한 답변을 드리자면, redirect_uri에서 다시 또 <클라이언트>에서 <씨유레터 인증 서버>를 거치게 될 것이고, 여기서 리다이렉트 하는 부분을 CSR로 한다는 이야기였어요!

정리:

SSR로 카카오/네이버 로그인 페이지로 이동, SSR로 다시 redirect_uri로 이동해요.

CSR로 이후 요청에 따라 인덱스 페이지로 이동 or 실패 시 로그인 페이지로 이동해요.

2. 파라미터 여부

PKCE에 대한 내용은 지난 회의 시 합의를 했기 때문에, 알겠습니다!

인증 요청 시에는 code_challenge를 전달할게요. 🙃
토큰 요청 시에는 code_verifier을 전달할게요. 😉

다만 여기서 파생되는 궁금한 점이 생겼어요!

nonce 여부

저번 회의에서 nonce의 경우, Kakao에서는 지원하지만 Naver에서는 요청 시 파라미터를 요구하지 않는 것으로 말씀드렸던 것 같아요. Naver Login API 요청 변수명 명세 혹시 nonce를 자체적으로 사용할 것인지 궁금해요! 한다면, 프론트엔드 측에서는 무작위로 생성할까요?

PKCE에서 프론트엔드의 핸들링 범위

일단 피그마의 그림의 화살표를 볼 때, code_verifier은 서버에서 보내주는 것 같아요. 맞을까요? 하지만 IBM - PKCE를 예시로 살펴볼 때에는 보통 클라이언트에서 code_verifier를 생성 후, code_challenge를 생성하는 것 같더라구요. 대신, 어떤 방식으로 암호화할 것인지를 알려주는 방식으로code_challenge_method이라는 사용하는 것 같아요. 이는 Oauth Playground에서도 설명되어 있는 변수에요!

아무래도 이게 가장 정형화된 방식인 듯한데, 이러한 로직으로 다시 변경해야 할 필요성은 있을까요?

RedirectURI 응답 코드 여부

제가 아직 Oauth가 서툴어서 그런지, Oauth Playground - PKCE버전으로 다시 해봤는데요. 여기서는 redirect_uri 파라미터를 전달하고 있네요! 프론트엔드 입장에서는 리다이렉트할 대상을 직전 페이지로 history를 추적하면 해결 가능할 수 있으나, 해당 파라미터를 쓰실 것인지 궁금합니다! (물론 해주신다면 프론트엔드 측에서 나쁠 건 없읍니다! 🙇🏻‍♂️)

에구... 제 불찰로 인해 이전 답변을 보셨다면 답변에 혼동이 있을 수 있는 점 양해 부탁드립니다( ) 부족한 팀원이지만 잘 부탁드려요! 여유로우실 때 편하게 답변해주세요~ 🙇🏻‍♂️

답변이 잘 정리되어서 읽기 편했습니다. 감사합니다! 🙏 아무래도 처음에 제가 의문을 가지고 질문했던 부분들이 서로가 이해한 부분이 달라서 시작된 것 같습니다. 또한 다이어그램을 작성한 의도가 보는 사람에게도 잘 전달되지 않은 것 같습니다.(죄송,, 😂) 서로간의 정확한 이해를 위해 개념에 대한 정리를 다시 해보고 질문하신 내용에 대한 답변을 해보겠습니다!

개념에 대한 정리

씨유레터 로그인 or 3rd party 로그인을 각각 다른 diagram에 표현했습니다.

씨유레터 로그인 후, 토큰 발급 과정

authorization flow

SPA에서 렌더링한 로그인 페이지에서 인증 서버의 로그인 API를 호출하여 유저 세션을 생성하고 클라이언트로 리다이렉트합니다.
인증 서버로 authorization request를 하기 전에 클라이언트에서 state, nonce, code_challenge, code_verifier를 생성합니다.

state는 CSRF를 방지하기 위한 파라미터이며 클라이언트에서 생성한 랜덤 문자열입니다.

nonce는 Replay Attack을 방지하기 위한 파라미터이며 클라이언트에서 생성한 랜덤 문자열입니다.

code_verifier: code_verifier는 authorization code injection을 방지하기 위한 파라미터이며 클라이언트에서 생성한 특정 문자들로 이루어진 48~120자의 랜덤 문자열입니다.

code_challenge: Base64(SHA256(code_verifier)

인증 서버로 authorization request를 요청하며 state, nonce, code_challenge를 전달합니다.
인증 서버로 부터 code, state 값과 함께 리다이렉트를 받은 페이지에서 state 값이 동일한지 검증합니다.
인증 서버로 token request를 요청하며 code, code_verifier를 전달합니다.
인증 서버로 부터 access_token, id_token을 응답 받으며, id_token의 payload(claim)에 포함된 nonce를 검증합니다.

3rd party로 로그인 후, 토큰 발급 과정

authorization flow - 3rd party

3rd party(카카오/네이버) 로그인하기 버튼을 누르면 3rd party의 로그인 페이지로 이동합니다.
로그인 후, callback_url로 이동합니다.
인증 서버에서 3rd party 엑세스 토큰 발급 및 씨유레터 회원 가입 및 유저 세션을 생성합니다.
이 후의 과정은 위의 씨유레터 로그인 후, 토큰 발급 과정의 2번부터 6번 까지의 과정이 진행됩니다.

오해에 대한 정리

재영님께서 제안하는 변경 방식으로 첨부해주신 내용에 해당하는 flow는 3rd party로 로그인 후, 토큰 발급 과정에 해당하며 각 3rd party들의 구현이 다르므로 사용할 수 있는 파라미터들이 다르기 때문에 파라미터들을 표기하지 않았습니다. 또한 현재 주고 받는 파라미터에 대한 자세한 내용들은 기입되지 않은 미완성 상태입니다 😂
state, nonce는 code 값으로 token을 교환하는 callback을 수행하는 곳에서 생성하고 검증합니다. 3rd party 로그인 후에 callback은 회원가입 및 유저 세션 생성 등을 처리해야하므로 callback은 인증 서버에서 수행하게 됩니다. 그러므로 3rd party authorization request URI는 서버로 부터 받아서 사용해야 할 것 같습니다.