[Unity] 구글 소셜 로그인 연동(Firebase Auth) – 서버 검증(Token 인증), DB 저장까지 전체 흐름정리

이번 글에서는 Unity 환경에서 구글·페이스북 소셜 로그인을 구현하는 전체 흐름을 다룬다.
클라이언트 로그인 요청부터 서버 검증(Token 인증), 그리고 DB에 사용자 정보를 저장하는 단계까지 실제 프로젝트에서 사용할 수 있는 형태로 정리했다.

---

전체 흐름

 

---

1. 클라이언트(App ) 로그인요청 → 외부서버(Google)

• 클라이언트가 다른 서버에 (페이스북,구글) 로그인 요청

⬇️미리 Unity에서 Google 로그인 연동 적용 필요

[Unity] 구글 로그인 연동 적용(Google Sign-In, Firebase Auth)

 

 

 

Unity로 빌드한 App에서 GoogleSignIn으로 구글 로그인 시도(구글은 Unity Editor에서 테스트 불가)

---

2. 외부서버(Google) [유저정보] → 클라이언트(App)

• 다른 서버에서 (페이스북,구글) 로그인 승인을 클라이언트로 전달

로그인 성공하면 GoogleSignInUser를 받는데 서버에서 사용하려는건 IdToken

---

3. 클라이언트(App) [구글 토큰] → 서버(WebServer)

• 클라이언트가 웹 서버로 승인된 정보 전달

- 클라이언트에서 2번에서 수신 받은 Google IdToken을 FirebaseAuth에서 Credential로 자격 확인

 

- 이상없으면 웹서버로 전달

---

4. 서버(WebServer) [구글토큰] → 외부서버(Google)

• 웹 서버가 외부 서버에 (페이스북,구글) 정보가 맞는지 확인 요청

 

 

구글에 token 확인 요청할 때 아래와 같이 필요.

https://oauth2.googleapis.com/tokeninfo?id_token=XYZ123

백엔드 서버에서 인증  |  Google for Developers

 

---

5. 외부서버(Google) [확인정보] → 서버(WebServer)

• 외부 서버에서 (페이스북,구글)  웹서버로 확인된 정보 전달

전달받은 값을 JsonConvert.DeserializeObject으로 변환.

public class GoogleTokenData
{
    public string iss { get; set; } = string.Empty; // "https://accounts.google.com", (토큰 발급자)
    public string azp { get; set; } = string.Empty; // "앱의 client_id",
    public string aud { get; set; } = string.Empty; // "앱의 client_id",
    public string sub { get; set; } = string.Empty; // "123456789012345678901", 구글 유저 고유 ID
    public string email { get; set; } = string.Empty; // "user@gmail.com"
    public bool email_verified { get; set; }            // true,  이메일 검증 여부
    public string name { get; set; } = string.Empty;    // "홍길동",
    public string picture { get; set; } = string.Empty; // "https://lh3.googleusercontent.com/a-/profilepic",
    public string given_name { get; set; } = string.Empty;  // "길동",
    public string family_name { get; set; } = string.Empty; // 홍",
    public long iat { get; set; }                           // 1692432000, (발급/만료 시간)
    public long exp { get; set; }                           // 1692435600  (발급/만료 시간)
}

 

---

6. 서버(WebServer) → 저장소(DB)

• 해당 유저가 처음 접속한건지, 내가 관리하는 DB에서 확인하고 없으면 데이터 생성하고 관리

---

7. 서버(WebServer) [유저정보] → 클라이언트(APP)

• 로그인 성공 전달. 기존 유저면 기존 데이터 전달.

이후 클라이언트에서 처리.

---

 

DB  ↔  WEB  ↔  APP  적용 로그

 

---

✅ 결론

웹서버와 DB까지 직접 붙여보는 과정은 결코 쉽지 않았다.
클라이언트 로그인에서도 여러 이슈를 겪었고, 서버에서 토큰 검증과 DB 저장 단계에서는 예상치 못한 오류와 시행착오가 끊임없이 이어졌다.

그러나 퇴근 후 시간을 쪼개 꾸준히 도전한 끝에 마침내 전체 흐름을 완성할 수 있었다.

이 과정에서 서버에서의 토큰 검증 구현과 사용자 정보의 DB 저장·관리를 직접 다루면서 클라이언트–서버–DB로 이어지는

전체 서비스 구조를 몸소 이해하게 되었고, “이게 진짜 서비스 구조구나”라는 깨달음을 얻을 수 있었다.
단순한 로그인 연동을 넘어서, 보안 검증과 사용자 관리까지 책임지는 구조를 직접 구현해 본 경험은 개발자로서 확실히 한 단계 성장하는 계기가 되었다.