소셜 로그인, OAuth 2.0만으로 붙이면 안 되는 이유 — 인증과 인가부터 구분하기

😀 개요

안녕하세요 😀

구글·카카오·네이버 로그인을 처음 붙일 때, 검색해 보면 방법이 두 갈래로 갈립니다.

• "access token 받아서 프로필 API 부르면 로그인 끝나요."
• "그렇게 하면 안 돼요. PKCE 쓰고 OIDC의 id_token을 검증해야 해요."

여기에 response_type=code, code_verifier, nonce 같은 파라미터가 쏟아지면, 도대체 뭘 기준으로 붙여야 안전한지 막힙니다.

결론부터 말하면, OAuth 2.0은 "로그인(인증) 프로토콜"이 아닙니다. OAuth는 "이 앱이 당신 자원에 접근해도 될까요?"를 다루는 인가(authorization) 규격이고, "이 사람이 누구인가?"를 다루는 인증(authentication) 은 그 위에 얹는 OpenID Connect(OIDC) 의 몫입니다. 이 둘을 섞어서 이해하니까, access token으로 로그인을 판단하는 위험한 코드가 나옵니다.

이 글은 지난 세션 vs JWT 인증, 뭘 쓰고 토큰은 어디에 저장하나 끝에서 예고했던 후속입니다. 소셜 로그인 흐름이 실제로 어떻게 도는지, 그리고 무엇을 고르면 되는지 기준을 잡아 드립니다.

🎯 오늘 정리하는 것

이 글을 다 읽으면 아래를 스스로 판단할 수 있습니다.

• OAuth 2.0(인가)과 OpenID Connect(인증)의 차이를 한 문장으로 설명할 수 있습니다.
• "access token을 디코드해서 로그인"이 왜 위험한지 말할 수 있습니다.
• 내 서비스(서버 웹앱·SPA·모바일 앱)에 어떤 플로우가 맞는지 조건으로 고를 수 있습니다.
• 구글·카카오·네이버가 실제로 무엇이 다른지(누가 id_token을 주는지) 구분할 수 있습니다.

특정 라이브러리 설정법이 아니라, 어떤 방식을 왜 고르는지 판단하는 기준을 손에 넣는 것이 목적입니다.

🧭 근거부터 짚고 갑니다

미리 말씀드리면, 이 글은 제 특정 서비스의 운영 경험담이 아니라 표준 규격과 공식 문서에서 확인해 정리한 것입니다. 근거로 삼은 자료는 다음과 같습니다.

• RFC 6749 / 6750(OAuth 2.0 · Bearer 토큰) — 인가 프레임워크의 뼈대
• RFC 7636(PKCE) — 인가 코드 가로채기 방어
• RFC 8252(네이티브 앱용 OAuth) — 모바일 앱의 로그인 방식
• RFC 9700(OAuth 2.0 보안 Best Current Practice, 2025) — implicit 폐기·PKCE 권고
• OpenID Connect Core 1.0 — 인증 계층과 ID Token
• Google Identity · Kakao Developers · Naver Developers — 각 제공자 공식 문서

개념과 판단 기준은 표준이라 잘 바뀌지 않지만, 제공자별 세부 동작과 엔드포인트는 확인일(2026년 7월 24일 기준) 이며, 실제 적용 전에는 본인이 붙이는 제공자의 현재 공식 문서로 확인하시는 편이 안전합니다.

🧩 OAuth는 "로그인 프로토콜"이 아닙니다

가장 먼저 풀어야 할 오해가 이것입니다. 많은 소셜 로그인 튜토리얼이 이렇게 끝납니다. "access token을 받아서 그걸로 프로필 API를 부르고, 응답에 온 사용자 ID로 로그인 처리하세요." 그런데 이건 인증을 인가 도구로 대신한 것입니다.

용어부터 나눠 보겠습니다.

• 인가(authorization) — "이 앱이 사용자의 무엇에(예: 이메일, 캘린더) 접근해도 되는가"의 위임입니다. OAuth 2.0이 다루는 영역이고, 그 결과물이 access token입니다.
• 인증(authentication) — "지금 로그인한 이 사람이 누구인가"의 확인입니다. OAuth 2.0에는 이걸 위한 규격이 없습니다.

RFC 6749는 OAuth 2.0을 자원에 대한 제한적·위임된 접근을 위한 프레임워크로 정의하고, 클라이언트에게 사용자의 신원을 알려 주는 방법은 정의하지 않습니다. 즉 OAuth는 인가만 다룹니다.

문제는 access token의 성격입니다. access token은 클라이언트 입장에서는 속을 알 수 없는(opaque) 값이고, 애초에 클라이언트가 받아 열어 보라고 만든 게 아닙니다. RFC 6749는 access token의 대상(audience)이 클라이언트가 아니라고 보며, 클라이언트가 그 내용을 해석하지 말아야 한다고 봅니다. 게다가 access token은 bearer 토큰이라, 쉽게 말하면 가진 사람이면 누구나 쓸 수 있는 "소지자용" 값이라(RFC 6750) 그 자체로는 누가 제시했는지(신원)를 증명하지 못합니다.

그래서 "access token으로 로그인"은 실제 공격으로 이어집니다. OpenID Connect 규격이 토큰 치환(token substitution) 이라 부르는 시나리오인데, 쉽게 말하면 다른(악의적인) 앱을 위해 발급된 access token을 슬쩍 끼워 넣으면, 순진한 클라이언트가 엉뚱한 사용자로 로그인시켜 버리는 문제입니다. access token에는 "이 토큰이 어느 앱을 위한 것인지"를 클라이언트가 검증할 장치가 없기 때문입니다.

정리하면, 로그인은 access token이 아니라 뒤에서 볼 OIDC의 ID Token으로 판단해야 합니다. 이 한 가지만 잡아도 소셜 로그인 사고의 큰 축을 피합니다.

🔑 인가 코드 흐름은 왜 이렇게 도나

그럼 표준 소셜 로그인은 어떻게 도는지 보겠습니다. 웹 앱의 기본은 Authorization Code(인가 코드) 방식입니다. 등장인물은 넷입니다(RFC 6749).

• 자원 소유자 — 로그인하는 사용자 본인
• 클라이언트 — 우리가 만드는 앱(서버 또는 프런트)
• 인가 서버 — 구글·카카오처럼 로그인을 처리하고 토큰을 발급하는 쪽
• 자원 서버 — access token으로 접근하는 API(예: 프로필 API)

여기서 핵심은 인가 코드(authorization code) 라는 중간 표입니다. 이건 토큰이 아니라, 아주 짧게 살고(최대 10분 권장) 한 번만 쓸 수 있는(RFC 6749) 일회용 교환권입니다. 왜 굳이 코드를 한 단계 끼울까요? 그래야 진짜 토큰이 브라우저를 거치지 않기 때문입니다.

그림 1. 소셜 로그인의 표준 흐름. 브라우저(front channel)로는 code_challenge를 담은 인가 요청과, 돌아오는 짧은 인가 코드만 오갑니다. 실제 토큰 교환은 서버끼리(back channel)에서 code_verifier와 함께 이뤄지고, 이때 인가 서버가 인증용 ID Token과 인가용 access token을 함께 내줍니다. 그래서 access·ID 토큰은 브라우저에 노출되지 않습니다.

흐름을 말로 풀면 이렇습니다. 앞부분은 브라우저를 통하는 front channel, 뒷부분은 서버끼리 직접 통하는 back channel로 나뉩니다.

• ① 인가 요청 (front channel) — 앱이 사용자를 인가 서버 로그인 화면으로 보냅니다. 이때 response_type=code, client_id, redirect_uri, state, 그리고 뒤에 볼 code_challenge를 함께 보냅니다.
• ② 로그인·동의 — 사용자가 인가 서버(구글·카카오)에서 로그인하고 권한에 동의합니다. 비밀번호는 우리 앱이 아니라 인가 서버에만 들어갑니다.
• ③ 인가 코드 반환 (front channel) — 인가 서버가 redirect_uri로 짧은 인가 코드만 돌려줍니다.
• ④ 토큰 교환 (back channel) — 앱 서버가 그 코드와 code_verifier를 인가 서버의 토큰 엔드포인트로 보냅니다. 이 통신은 브라우저를 안 거칩니다.
• ⑤ 토큰 발급 — 인가 서버가 access token(인가용)과, OIDC라면 ID Token(인증용)을 함께 내줍니다.
• ⑥ 검증 — 앱이 ID Token의 서명과 값을 검증하고 나서야 로그인을 확정합니다.

이 구조 덕분에 access token은 브라우저 주소창·기록에 남지 않습니다. 참고로 access token을 자원 서버에 보낼 때는 Authorization: Bearer 헤더로 보내고, URL 쿼리스트링에 담지 않습니다. 쿼리스트링은 로그·Referer 헤더·브라우저 기록으로 새기 쉬워 규격도 권장하지 않습니다(RFC 6750 §2.3).

🛡️ PKCE는 이제 모두가 씁니다

방금 흐름에서 code_challenge와 code_verifier가 나왔습니다. 이게 PKCE(쉽게 말하면 "인가 코드가 중간에 탈취돼도 못 쓰게 묶어 두는 장치")입니다. 원래는 모바일·SPA 같은 public 클라이언트(코드가 사용자 기기에 있어 비밀을 숨길 수 없는 앱)의 인가 코드 가로채기를 막으려고 나왔습니다(RFC 7636).

동작은 간단합니다.

• 앱이 무작위 문자열 code_verifier를 만들고, 그걸 해시한 code_challenge = BASE64URL(SHA256(code_verifier))를 ① 인가 요청에 담아 보냅니다.
• 진짜 code_verifier는 ④ 토큰 교환 때만 보냅니다.
• 인가 서버는 받은 code_verifier를 다시 해시해, 처음 받은 code_challenge와 맞는지 대조합니다(RFC 7636 §4.6).

그래서 인가 코드를 중간에서 훔쳐도, code_verifier가 없으면 토큰으로 바꿀 수 없습니다. 해시 방식은 S256을 씁니다. 규격도 "S256을 쓸 수 있으면 반드시 S256, plain은 SHA-256이 불가능할 때만"으로 못박습니다(RFC 7636 §4.2).

# ① 인가 요청 (브라우저 리다이렉트, front channel)
GET /authorize?
  response_type=code
  &client_id=MY_APP
  &redirect_uri=https://myapp.com/callback   # 등록값과 "정확히" 일치해야 함
  &scope=openid profile email                # openid 를 넣어야 OIDC(로그인)
  &state=xyz...          # CSRF 방어용 임의값 (돌아올 때 대조)
  &nonce=abc...          # ID Token 재전송 방어용 (OIDC)
  &code_challenge=BASE64URL(SHA256(code_verifier))
  &code_challenge_method=S256

# ④ 토큰 교환 (서버 → 인가 서버, back channel)
POST /token
  grant_type=authorization_code
  &code=RECEIVED_CODE
  &redirect_uri=https://myapp.com/callback
  &client_id=MY_APP
  &code_verifier=원본_무작위값   # 서버가 challenge 와 대조
  # confidential 클라이언트면 여기서 client_secret 로 인증

여기서 요즘 가장 많이 바뀐 부분입니다. PKCE는 이제 모바일·SPA 전용이 아닙니다. OAuth 2.0 보안 BCP(RFC 9700)는 모든 클라이언트가 Authorization Code 방식에 PKCE를 쓰라고 하며, public 클라이언트는 필수, 서버 웹앱 같은 confidential 클라이언트도 권고입니다(§2.1.1). client_secret이 있어도 PKCE는 인가 코드 주입 공격을 따로 막아 주니, 둘은 겹치는 게 아니라 보완 관계입니다.

반대로, 예전 글에서 흔히 보이던 두 방식은 이제 쓰면 안 됩니다.

• implicit 방식(response_type=token, 인가 서버가 토큰을 브라우저로 바로 던지는 방식) — RFC 9700이 쓰지 말라(SHOULD NOT) 고 하고(§2.1.2), 다음 버전인 OAuth 2.1 초안은 아예 제거합니다. SPA도 이제 implicit이 아니라 Authorization Code + PKCE를 씁니다.
• ROPC 방식(사용자 아이디·비번을 앱이 직접 받아 토큰으로 바꾸는 방식) — RFC 9700이 금지(MUST NOT) 합니다(§2.4). 소셜 로그인을 흉내 내려고 남의 서비스 비번을 우리 앱이 받는 순간, 그건 소셜 로그인이 아니라 비번 유출 통로입니다.

그림 2. RFC 9700(OAuth 2.0 Security Best Current Practice · BCP 240 · 2025년 1월). RFC 6749/6750/6819를 갱신하며 "안전하지 않다고 판단되는 일부 동작 방식을 폐기(deprecate)한다"고 초록에 명시합니다. 오른쪽 목차의 2.1.2 Implicit Grant와 2.4 ROPC가 그 대상입니다.

🪪 소셜 로그인은 OIDC의 ID Token으로

이제 인증입니다. OpenID Connect(OIDC) 는 쉽게 말하면 OAuth 2.0 위에 "이 사람이 누구인지"를 얹은 얇은 인증 계층입니다(OIDC Core §1). 앞의 인가 요청 scope에 openid 를 넣으면, 인가 서버가 토큰과 함께 ID Token을 내줍니다.

ID Token은 서명된 JWT입니다. (JWT가 왜 "암호화가 아니라 서명"인지, base64 디코드만으로 내용이 읽히는 이유는 지난 세션 vs JWT 글에서 다뤘습니다.) 필수로 담기는 값은 iss(발급자), sub(사용자 고유 ID), aud(이 토큰을 받을 대상=우리 client_id), exp(만료), iat(발급 시각)입니다(OIDC Core §2). 이 중 sub가 우리가 사용자 식별에 써야 할 안정적인 키입니다. 이메일은 바뀔 수 있으니 기준으로 삼지 않습니다.

그림 3. OpenID Connect Core 1.0 규격. OIDC는 OAuth 2.0 위에서 클라이언트가 "인가 서버가 수행한 인증에 근거해 최종 사용자의 신원을 검증"하게 해 주는 계층이라고 정의합니다. 즉 로그인(인증)은 OAuth가 아니라 이 계층의 몫입니다. 

중요한 건, ID Token을 그냥 디코드해서 믿으면 안 된다는 점입니다. 받은 즉시 아래를 검증해야 합니다(OIDC Core §3.1.3.7).

• 서명 검증 — 제공자가 공개한 키(JWKS)로 JWT 서명을 확인합니다. 서명 검증 없이 payload만 읽는 건 위조에 무방비입니다.
• iss — 우리가 기대한 발급자와 정확히 일치하는가.
• aud — 우리 client_id가 대상에 포함되는가(다른 앱용 토큰 거부).
• exp — 만료되지 않았는가.
• nonce — ①에서 보낸 nonce와 같은 값이 담겨 있는가.

여기서 nonce와 state는 자주 헷갈리는데, 막는 게 다릅니다. state는 CSRF(요청 위조)를 막는 값이고, nonce는 ID Token 재전송(replay) 을 막으려고 토큰과 내 세션을 묶는 값입니다(OIDC Core §3.1.2.1). PKCE가 코드 가로채기를 막는 것과도 또 다릅니다. 셋을 "다 넣는다"고 생각하면 편합니다.

사용자 정보를 더 받고 싶으면 access token으로 UserInfo 엔드포인트를 부를 수 있는데, 이건 ID Token 검증을 대체하는 게 아니라 보조합니다. 이때도 UserInfo 응답의 sub가 ID Token의 sub와 같은지 확인해야 합니다(OIDC Core §5.3.2).

🧭 내 앱엔 어떤 방식이 맞나

정리하면 결정은 두 단계입니다. 먼저 목적, 그다음 클라이언트 유형입니다.

그림 4. 목적(인증인지 자원 접근인지)을 먼저 정하고, 그다음 클라이언트 유형에 맞는 플로우를 고릅니다. 대부분의 경우 답은 "Authorization Code + PKCE"로 모입니다.

1단계 — 목적이 무엇인가

• "이 사람이 누구인지" 로그인 → OIDC를 씁니다. scope에 openid를 넣고, ID Token을 검증해 로그인 처리합니다.
• "그 사용자의 자원에 접근"(예: 구글 캘린더 읽기) → OAuth access token으로 자원 서버 API를 부릅니다.
• 대부분의 소셜 로그인은 둘 다입니다. 로그인은 ID Token, 부가 자원 접근은 access token 으로 역할을 나눕니다.

2단계 — 클라이언트 유형에 맞는 플로우

• 서버 웹앱(confidential) — Authorization Code + PKCE. client_secret은 서버에만 두고 토큰 교환도 서버에서 합니다.
• SPA(브라우저 단독, public) — Authorization Code + PKCE. secret은 프런트에 두지 않습니다. 받은 토큰을 브라우저 어디에 둘지는 지난 글의 저장 위치 기준을 따릅니다.
• 네이티브 모바일 앱(public) — Authorization Code + PKCE. 그리고 반드시 시스템 브라우저(또는 인앱 브라우저 탭)로 로그인하고, 임베디드 웹뷰는 쓰지 않습니다(RFC 8252). 웹뷰는 사용자의 비번을 앱이 엿볼 수 있어 신뢰가 깨집니다.
• 서버 대 서버(M2M, 사용자 없음) — 여기만 예외로 Client Credentials 방식을 씁니다. 사용자가 없으니 OIDC 로그인이 아닙니다.

그리고 유형과 무관하게 공통으로 지킬 것: redirect_uri는 등록값과 정확히 일치해야 합니다(부분·와일드카드 매칭 금지, RFC 9700 §2.1). 그리고 implicit·ROPC는 쓰지 않습니다.

🇰🇷 구글·카카오·네이버는 실제로 다릅니다

같은 "소셜 로그인"이라도 세 제공자가 주는 게 다릅니다. 특히 ID Token(OIDC)을 주느냐가 갈립니다. 아래는 각 공식 문서 기준(확인일 2026-07-24)이며, 세부 파라미터·엔드포인트는 반드시 각 제공자 최신 문서로 확인하세요.

제공자	기본 플로우	OIDC ID Token	로그인 판단 방법
구글	Authorization Code	발급 (OIDC 지원)	ID Token 검증(iss·aud·exp·서명·nonce)
카카오	Authorization Code (코드→토큰 2단계)	옵션(기본 꺼짐)	OIDC 켜고 openid scope → id_token, 아니면 프로필 API
네이버	OAuth 2.0 (code + state)	없음	access token으로 프로필 API 조회

• 구글은 OpenID Connect를 정식 지원해 ID Token(JWT) 을 내줍니다. 로그인은 이 ID Token을 검증해서 판단하면 됩니다.
• 카카오는 OIDC를 지원하지만 기본적으로 꺼져 있습니다. 앱 설정에서 OpenID Connect를 켜고 scope에 openid 를 넣어야 id_token이 나옵니다. 켜지 않으면 access token만 나오고, 사용자 정보는 별도 프로필 API로 조회합니다.
• 네이버는 OIDC ID Token을 발급하지 않습니다. 자체 access token을 준 뒤 프로필 API로 사용자 정보를 조회하는 구조입니다. 그래서 네이버는 "OIDC id_token 검증" 대신, access token 취급에 주의(전송 중 유출·범위)하고 state로 CSRF를 막는 데 초점을 둡니다.

핵심은, "구글에서 되던 id_token 코드가 네이버엔 없다" 같은 상황이 정상이라는 점입니다. 제공자가 OIDC를 주는지부터 확인하고 붙이면 헤매지 않습니다.

✅ 소셜 로그인 붙이기 전 체크리스트

새 소셜 로그인을 설계할 때 이 순서로 짚으면 됩니다. 필요하면 복사해서 쓰세요.

[목적 — 무엇을 하려는가]
- [ ] 로그인(인증)이면 OIDC를 쓰고 ID Token으로 판단하나? (access token 아님)
- [ ] 자원 접근(인가)만 필요하면 그 scope의 access token만 받나?

[플로우 — 클라이언트 유형]
- [ ] 서버 웹앱/SPA/모바일 모두 Authorization Code + PKCE 인가?
- [ ] implicit(response_type=token)·ROPC(비번 직접 수집)를 쓰고 있지 않나?
- [ ] 모바일 앱은 임베디드 웹뷰가 아니라 시스템 브라우저로 로그인하나?
- [ ] client_secret 을 프런트/모바일 코드에 넣지 않았나? (public = secret 불가)

[PKCE]
- [ ] code_challenge_method 를 S256 으로 고정했나? (plain 금지)
- [ ] code_challenge 는 인가 요청, code_verifier 는 토큰 요청에만 보내나?

[ID Token 검증 — OIDC일 때]
- [ ] 서명(JWKS)·iss·aud·exp 를 모두 검증하나? (디코드만 믿지 않기)
- [ ] 보낸 nonce 와 토큰의 nonce 가 일치하는지 확인하나?
- [ ] 사용자 식별은 이메일이 아니라 sub 로 하나?

[공통]
- [ ] redirect_uri 를 등록값과 "정확히" 일치시켰나? (와일드카드 금지)
- [ ] state 로 CSRF 를 막고, access token 은 헤더로만 보내나? (쿼리스트링 금지)
- [ ] 붙일 제공자가 OIDC id_token 을 주는지 공식 문서로 확인했나? (네이버는 없음)

결정을 내렸다면 다음 한 발은 이렇습니다. 붙일 제공자의 OAuth/OIDC 개발 문서에서 authorize·token 엔드포인트와 openid scope 지원 여부부터 찾고, 쓰는 언어의 OIDC 클라이언트 라이브러리(ID Token 검증을 대신 해 줍니다)를 고르시면 자연스럽게 이어집니다.

🫡 마무리

정리하면, 소셜 로그인에서 먼저 잡을 두 가지는 이것입니다. 첫째, OAuth 2.0은 인가고 인증이 아니다 — 로그인은 access token이 아니라 OIDC의 ID Token을 검증해서 판단합니다. 둘째, 플로우는 (거의 항상) Authorization Code + PKCE 이고, implicit과 ROPC는 폐기됐습니다.

이 두 가지와, "제공자마다 id_token을 주는지 다르다"는 것만 기억해도 대부분의 소셜 로그인 사고를 피할 수 있습니다.

같은 웹 인증·보안 묶음으로, 토큰을 어디에 저장하고 JWT 서명을 어떻게 다루는지는 세션 vs JWT 인증, 뭘 쓰고 토큰은 어디에 저장하나에서 이어집니다. 로그인 요청이 다른 출처로 오갈 때 나는 CORS 에러나, 그 아래의 Socket과 HTTP 통신 비교, HTTP 상태 코드 제어도 같은 결의 글입니다.

읽어 주셔서 감사합니다 🙇

참고 자료

• RFC 6749: The OAuth 2.0 Authorization Framework
• RFC 6750: OAuth 2.0 Bearer Token Usage
• RFC 7636: Proof Key for Code Exchange (PKCE)
• RFC 8252: OAuth 2.0 for Native Apps
• RFC 9700: Best Current Practice for OAuth 2.0 Security
• OpenID Connect Core 1.0
• OAuth 2.1 (IETF draft)
• Google Identity: OpenID Connect
• Kakao Developers: Kakao Login (REST API · OpenID Connect)
• Naver Developers: 네이버 아이디로 로그인
• OWASP: OAuth 2.0 Cheat Sheet