"구글로 로그인"은 어떻게 동작할까?

들어가며

"카카오로 로그인", "구글로 로그인" — 요즘 웹서비스에서 정말 흔하게 보이는 버튼이죠.

그런데 이 버튼을 누르면 내 뒤에서 무슨 일이 벌어지는 걸까요? 내 비밀번호를 그 서비스가 알게 되는 건 아닐까요?

그 비밀을 풀어주는 게 바로 OIDC(OpenID Connect)입니다.

---

먼저, OAuth 2.0을 알아야 해요

OIDC를 이해하려면 먼저 OAuth 2.0을 짚고 넘어가야 합니다.

OAuth 2.0은 "내 비밀번호를 알려주지 않고도, 특정 권한을 다른 서비스에게 위임"하는 프로토콜이에요.

예시를 들어볼게요.

어떤 앱이 "내 구글 드라이브 파일을 읽고 싶다"고 해요.

이때 내 구글 계정 비밀번호를 그 앱에 알려줄 순 없잖아요.

OAuth 2.0은 구글이 "이 앱은 드라이브 파일을 읽을 수 있다"는 허락증(Access Token)을 대신 발급해줍니다.

근데 여기서 문제가 생겼어요.

OAuth 2.0은 "권한 위임"에 집중하다 보니, "이 사용자가 누구인가"를 표준으로 정의하지 않았어요.

그래서 서비스마다 사용자 정보를 가져오는 방식이 제각각이었죠.

이 문제를 해결하기 위해 OAuth 2.0 위에 "사용자 인증" 기능을 표준으로 얹은 것이 바로 OIDC입니다.

---

OIDC의 등장인물

OIDC에는 3명의 주인공이 있어요.

역할	이름	실제 예시
사용자	End User	나 (로그인하는 사람)
내 정보를 관리하는 곳	Identity Provider (IdP)	구글, 카카오, 네이버
로그인을 요청하는 서비스	Relying Party (RP)	쇼핑몰, 블로그, 회사 앱

핵심은 이거예요.

내 비밀번호는 IdP(구글)만 알고, RP(쇼핑몰)는 절대 알 수 없다.

---

OIDC 흐름 한눈에 보기

아래는 "구글로 로그인" 버튼을 눌렀을 때 실제로 일어나는 일이에요.

sequenceDiagram actor 나 participant 쇼핑몰 participant 구글 나->>쇼핑몰: 로그인 버튼 클릭 쇼핑몰->>구글: 인증 요청 (client_id, scope=openid ...) 구글-->>나: 구글 로그인 화면 표시 나->>구글: ID/PW 입력 + 권한 허용 구글-->>나: 쇼핑몰로 리다이렉트 (code 전달) 나->>쇼핑몰: code 도착 쇼핑몰->>구글: code로 토큰 요청 (서버↔서버) 구글-->>쇼핑몰: ID Token + Access Token 발급 쇼핑몰-->>나: 로그인 완료!

단계별로 차근차근 살펴봅시다.

---

단계 1 — 인증 요청 (Authorization Request)

쇼핑몰이 구글에게 이렇게 요청해요.

https://accounts.google.com/o/oauth2/auth
  ?client_id=쇼핑몰_ID
  &redirect_uri=https://shop.example.com/callback
  &response_type=code
  &scope=openid email profile
  &state=abc123

주요 파라미터를 해석하면:

• client_id : 쇼핑몰이 구글에 등록된 ID
• redirect_uri : 로그인 후 사용자를 어디로 보낼지
• scope=openid : "OIDC를 쓸게요" 라는 선언. 이게 있어야 OIDC예요
• scope=email profile : 이메일, 이름도 알고 싶어요
• state : 나중에 위조 요청 방어에 쓰는 랜덤 값

---

단계 2 — 사용자 로그인

구글 로그인 화면이 뜨고, 사용자가 아이디/비밀번호를 입력해요.

구글은 인증에 성공하면 이런 화면을 보여줄 수도 있어요.

"쇼핑몰이 이메일과 이름을 요청합니다. 허용하시겠어요?"

---

단계 3 — Authorization Code 전달

사용자가 허락하면, 구글은 아까 쇼핑몰이 알려준 redirect_uri로 사용자를 보내요.

https://shop.example.com/callback
  ?code=4/P7q7W91a
  &state=abc123

여기서 code는 일회용 코드예요. 그 자체로는 아무것도 아니고, 토큰으로 교환해야 비로소 의미가 생겨요.

---

단계 4 — 토큰 발급 (Token Exchange)

쇼핑몰 서버는 이 code를 가지고 구글에게 직접 토큰을 요청해요.

POST https://oauth2.googleapis.com/token

code          = 4/P7q7W91a
client_id     = 쇼핑몰_ID
client_secret = 쇼핑몰_비밀키
redirect_uri  = https://shop.example.com/callback
grant_type    = authorization_code

이 요청은 브라우저가 아니라 서버끼리 직접 이루어지기 때문에, 사용자가 볼 수 없어요.

구글은 이에 응답으로 두 가지 토큰을 줘요.

{
  "access_token": "ya29.xxx",
  "id_token":     "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9..."
}

---

OIDC의 핵심 — ID Token

OIDC에서 가장 중요한 것은 바로 ID Token이에요.

access_token이 "이 사람이 어떤 걸 할 수 있다"는 허가증이라면,
id_token은 "이 사람이 누구다"를 증명하는 신분증이에요.

ID Token은 JWT(JSON Web Token) 형식이에요. 점(.)으로 구분된 세 파트로 이루어져 있어요.

# 헤더 — 어떤 알고리즘으로 서명했는지
eyJhbGciOiJSUzI1NiJ9

# 페이로드 — 실제 사용자 정보 (Claims)
eyJzdWIiOiIxMjM0NTY3ODkwIn0

# 서명 — 위조 방지
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

페이로드를 Base64로 디코딩하면 이런 정보가 나와요.

{
  "iss":   "https://accounts.google.com",  // 발급자 (구글)
  "sub":   "1234567890",                  // 사용자 고유 ID
  "aud":   "쇼핑몰_ID",                   // 이 토큰을 받을 대상
  "exp":   1716153600,                    // 만료 시간
  "iat":   1716150000,                    // 발급 시간
  "email": "user@example.com",
  "name":  "홍길동"
}

이 정보들을 Claims라고 불러요.

---

서명은 왜 중요한가요?

ID Token의 세 번째 파트인 서명 덕분에, 쇼핑몰은 이 토큰이 진짜 구글이 발급했는지 검증할 수 있어요.

구글은 자신의 공개 키를 공개해 두는데, 쇼핑몰은 이 키로 서명을 확인해요.

누군가 토큰 내용을 살짝 바꾼다면? → 서명이 맞지 않아서 즉시 탄로나요.

이 덕분에 쇼핑몰이 직접 사용자 정보 DB를 가지지 않아도, 구글이 "이 사람 맞아요"라고 보증해주는 구조가 만들어져요.

---

정리 — OIDC가 해결한 것

문제	OIDC의 해결책
내 비밀번호를 서비스에 알려줘야 하나?	비밀번호는 IdP(구글)에만 입력, 서비스는 절대 모름
서비스마다 사용자 정보 가져오는 방식이 다름	ID Token이라는 표준 형식으로 통일
토큰이 위조될 수 있지 않나?	JWT 서명으로 위조 즉시 탐지
"이 사람이 누구야?"를 어떻게 알아?	sub claim이 사용자 고유 식별자 역할

---

마치며

"구글로 로그인"은 단순해 보이지만, 뒤에서는 꽤 정교한 흐름이 돌아가고 있어요.

핵심만 기억하세요.

• 내 비밀번호는 구글만 알고, 다른 서비스는 절대 모른다
• 구글은 ID Token(신분증)을 발급해서 "이 사람 맞아요"를 보증해준다
• ID Token은 JWT 형식이라 위조가 불가능하다

이 세 가지만 이해해도 OIDC의 절반은 이해한 거예요.