croissant_code

구글 SSO 인증과 이메일 기반 인증 본문

SW

구글 SSO 인증과 이메일 기반 인증

crossfit_wod 2025. 7. 2. 14:16

 

신규 플랫폼을 만들면서 일반적인 회원가입 방법을 이메일 인증 기반의 회원가입으로 적용했다. 그 후 구글 SSO를 적용해, 사용자가 간편하게 인증을 해서 자사의 서비스를 경험하도록 만들었다. 따라서 이와 관련한 내용을 정리하려고 한다.


일단 설명에 앞서 자사의 플랫폼은 FastAPI를 사용하고 있다. 이유는 AI를 활용을 하다보니 AI에 최적화된 프로그래밍 언어인 Python이 필요했고 빠른 개발 속도를 원했기 때문이다. 그래서 Python과 FastAPI를 선택했다. 또한 Java와 Spring Boot에 익숙한 사람으로서 빠르게 개발하면서 안정성을 어느정도 확보하는 Type 형 지정이 필요했다.

이메일 기반의 일반 회원가입 및 로그인

내가 생각한 이메일 기반의 회원가입은 아래 순서와 같다.

 

1. 사용자가 필수 값을 넣고 회원가입 버튼을 누른다.

2. 사용자가 입력한 이메일로 인증버튼을 함께 보낸다.

3. 사용자가 해당 이메일의 인증버튼을 누르면 사용자는 로그인 상태가 된다.

 

그 결과 API 2개가 필요했다. 먼저, 회원가입을 했을 때, 사용자의 정보를 임시로 DB에 넣는 API가 필요했고, 이메일 인증이 완료되는 즉시 해당 ROW를 update하는 API가 필요했다.

 

이때 이메일에 인증버튼은 아래와 같은 형태를 가진다.

https://{domain_name}/auth/v1/verify?token={{ .TokenHash }}&type=email&redirect_to=https://example.com/path

 

여기서 사용자가 이메일의 인증버튼을 클릭하면,
1. 프론트에서 해당 이메일 URL을 GET 하면서 내부적으로 token, type, redirect_url을 상태관리에 저장한다.

2. token을 받아서 백엔드로 이메일 인증 완료 확인 POST API로 보낸다.

3. 백엔드에서 이메일 인증 완료 확인 응답과 사용자 정보 그리고 헤더에 access_token과 refresh_token을 제공한다.

4. 프론트는 redirect_url로 사용자 페이지를 옮기면서, 스토리지에 access_token과 refresh토큰을 저장한다.

이메일 기반의 구글 회원가입 및 로그인

구글 SSO의 경우는 약간 복잡한 비즈니스 로직을 가지고 있다. Client 측에서 구글 SSO 인증을 한번에 처리해서 Server쪽에서 할 필요가 없는 방법도 있지만, 자사의 플랫폼의 경우에는 유저가 회원가입 시, 무료 코인을 제공하는 비스니스 로직이 필요하기 때문에 모든 SSO 비즈니스 로직을 Server에서 처리해야 했다.

 

1. CLIENT ======> GOOGLE

  • client_id(구글 창을 만들 수 있게 하는 ID)
  • redirect_uri(callback 주소)
  • response_type
  • scope

2. CLIENT <====== GOOGLE

  • redirect_uri, code(1회성)
  • ...?code=... 형태를 가진다.

3. CLIENT ======> SERVER

  • GET redirect_uri

4. SERVER ======> GOOGLE

  • client_id
  • client_secret
  • redirect_uri
  • code(디코딩 된)
  • token_uri(엑세스 토큰 요청 주소)
  • grant_type

5. SERVER <====== GOOGLE

  • token_data
    • access_token
    • expire_in
    • refresh_token
    • scope
    • token_type
    • id_token

6. SERVER ======> GOOGLE

  • access_token

7. SERVER <====== GOOGLE

  • id
  • verified_email
  • email
  • name
  • give_name
  • family_name
  • picture
  • locale:KO

8. CLIENT <====== SERVER

  • access_token
  • redirect_uri

{FRONTEND_BASE_URL}/google-login-confirm?access_token={access_token}&refresh_token={refresh_token}&prev_url={previous_url}&id={user_id}&username={username}

 

최종적으로는 위의 형태로 redirect_uri를 담아서 응답해주면 된다. 해당 정보에는 access_token과, refresh_token, previous_url, id, username이 존재하고, 프론트는 previous_url을 통해서 로그인 후 보내 줄 페이지로 유저를 이동시키면 된다.

 

위에 와 같은 순서로 SSO 인증을 설계했다. 여기서 중요한 점은 구글 인증을 할 때 기존에 있던 페이지에서 이동을 시키는 것인지 아니면 새로운 창을 생성해서 진행을 시킬 것인지이다.

 

만약 새로운 창을 띄워서 SSO 인증을 진행 시, 기존 로컬 스토리지에 있던 정보들이 날라가기 때문에 좋지 않다고 판단했고, 같은 창을 사용하면서 previous_url을 이용해서 SSO 인증 전의 페이지로 돌려보내야 하기 때문에 redirect_uri가 반드시 필요한 방법을 선택했다.

'SW' 카테고리의 다른 글

IT 이직하기 위한 단어 정리  (2) 2025.07.12
결제 시스템  (1) 2025.07.02
QA 엔지니어  (0) 2025.05.28
supabase - auth.users  (0) 2025.05.26
토스페이 입점심사  (1) 2025.05.12