OpenID Connect(OIDC) 쉽게 이해하기: OAuth 2.0 위에서 로그인 기능을 만든 이유

구글 로그인, 카카오 로그인, 네이버 로그인. 우리가 매일 사용하는 이 소셜 로그인은 OIDC(OpenID Connect)라는 프로토콜을 기반으로 동작합니다. 많은 사람들은 OAuth 2.0으로 로그인을 한다고 생각합니다. 하지만 사실 OAuth 2.0은 로그인용 기술이 아닙니다. OAuth의 본래 목적은 권한 위임, 즉 이 앱이 내 구글 드라이브에 접근하도록 허용할까 같은 문제를 해결하는 것입니다. 그러나 이런 구조만으로는 누가 로그인했는지를 인증하기에는 부족했습니다. 이 빈틈을 메워주는 것이 바로 OIDC입니다.

OIDC란 무엇인가?

OIDC(OpenID Connect)는 OAuth 2.0 위에 사용자 인증, 즉 로그인 기능을 정식으로 추가한 표준 프로토콜입니다. OAuth 2.0은 본래 "이 앱에 내 정보 접근 권한을 줄게"라는 권한 위임(Authorization) 을 위한 기술입니다. 예를 들어, 어떤 앱이 내 구글 드라이브나 프로필 정보에 접근하도록 허용할지 결정하는 것이라 할 수 있습니다. 하지만 OAuth 2.0만으로는 로그인, 즉 사용자가 누구인지 확인하는 과정(Authentication) 을 처리하기 어렵습니다. 앱이 토큰을 받아도 그 토큰이 실제 어떤 사용자와 연결된 것인지 알 수 없기 때문입니다.

이 문제를 해결하기 위해 등장한 것이 바로 OIDC입니다. OIDC는 OAuth 2.0의 흐름을 그대로 활용하면서, 여기에 사용자를 식별할 수 있는 ID 토큰(ID Token) 개념을 추가했습니다. 이 토큰에는 사용자의 고유 식별자, 이름, 이메일 같은 기본 정보가 포함되어 있어, 애플리케이션이 안전하게 로그인 상태를 관리할 수 있습니다.

정리하자면, OIDC는 인증(Authentication)을 담당하고 OAuth는 인가(Authorization)을 담당합니다. 이 둘이 함께 작동함으로써, 오늘날 우리가 사용하는 소셜 로그인 시스템이 완성됩니다.

OIDC에서 가장 중요한 것: ID Token

OIDC의 핵심은 ID Token입니다. ID Token은 쉽게 말해 JWT 형태의 로그인 증명서라고 볼 수 있습니다. 이 토큰 안에는 사용자의 인증 정보를 담은 여러 필드가 들어 있습니다.

필드	의미
sub	사용자를 식별하는 고유 값 (이메일 아님)
iss	누가 발급했는지 (Issuer)
aud	누구에게 발급된 토큰인지 (Audience: 보통 클라이언트 앱)
exp	언제까지 유효한지
iat	언제 발급되었는지
name, email	사용자 프로필 정보 (스코프에 따라 달라짐)

SP(서비스)는 이 ID Token의 서명을 검증하여, 이 토큰이 실제 인증 서버에서 발급된 것임을 확인합니다. 그 후 토큰 안의 정보를 읽어 사용자가 인증되었다는 사실만 받아 세션이나 자체 토큰을 설정합니다.

Access Token과 ID Token의 차이

OAuth 2.0과 OIDC를 구분할 때 가장 자주 혼동되는 부분이 바로 Access Token과 ID Token입니다. 둘 다 토큰이지만, 역할은 완전히 다릅니다.

구분	Access Token	ID Token
목적	API 접근 권한 확인	사용자 인증(로그인 증명)
발급 주체	인증 서버 (Authorization Server)	동일
사용 대상	API 서버(Resource Server)	클라이언트 앱(Client)
포맷	JWT일 수도 있고 아닐 수도 있음	반드시 JWT
포함 정보	권한 범위(scope), 만료 시간 등	사용자 정보(sub, iss, aud, exp 등)

정리하자면, Access Token은 "이 사용자가 이 API를 쓸 수 있는지" 를 판단하는 열쇠이고, ID Token은 "이 사용자가 누구인지" 를 알려주는 신분증입니다.

ID Token 검증 절차

클라이언트(또는 서비스)는 인증 서버에서 받은 ID Token을 그대로 믿지 않습니다. 보안상, 반드시 서명 검증(Signature Verification) 과 클레임 검증(Claim Validation) 단계를 거쳐야 합니다. ID Token 검증은 아래와 같은 순서로 진행됩니다.

1. JWKs(공개키) 조회

인증 서버(OIDC Provider)는 공개키 목록을 JSON Web Key Set(JWKS) 형태로 제공합니다. 클라이언트는 토큰 헤더의 kid(Key ID)에 맞는 공개키를 가져와 검증에 사용합니다.

2. 서명 검증(Signature Verification)

ID Token의 서명을 공개키로 검증하여, 토큰이 실제로 인증 서버에서 발급된 것인지 확인합니다. 누군가 중간에서 변조했다면 이 단계에서 검증에 실패합니다.

3. 클레임 검증(Claim Validation)

iss : 신뢰하는 발급자인지 확인
aud : 우리 앱(Client ID)에 맞는지 확인
exp : 토큰이 만료되지 않았는지 확인
nonce : 요청 시 보낸 값과 일치하는지 확인 (재사용 공격 방지)

이 과정을 모두 통과한 후에야, 서비스는 이 사용자는 인증됨이라는 사실을 신뢰할 수 있습니다.

OIDC 로그인 흐름 (가장 단순한 형태)

사용자가 “구글로 로그인” 버튼 클릭
서비스는 사용자를 구글 로그인 페이지로 보냄
사용자가 구글에 로그인 → 동의
구글은 서비스에게 Authorization Code 를 전달
서비스는 Authorization Code를 이용해 ID Token + Access Token 을 받아옴
서비스는 ID Token을 검증 → 사용자 로그인 상태 확정

핵심은:

Access Token은 API 접근 권한, ID Token은 로그인 증명

왜 OIDC가 현대 웹/모바일에서 기본이 되었는가?

장점	설명
모바일/SPA 친화적	JSON + JWT → JS에서 다루기 쉬움
사용자 프로필 연동 쉬움	name, email 등을 표준 claims로 제공
소셜 로그인 표준	거의 모든 공급자가 OIDC 지원
확장성	인증 정보 + 권한 + 세션 정책 연계가 수월

요약하면:

개발하기 쉽고, 서비스 전체에서 편하고, 보안적으로 정리가 잘 되어 있다.

OIDC vs SAML (한 번 더 감각적 비교)

항목	SAML	OIDC
데이터 형식	XML	JSON / JWT
주 사용처	기업 내부 시스템	웹/모바일 / 소셜 로그인
배우기 난이도	상대적으로 높음	상대적으로 쉬움
확장성	다소 정적	동적 설정/확장 용이

결론:

회사 포털/레거시 → SAML
웹/모바일/소셜 로그인 → OIDC

실무에서 딱 이것만 신경 쓰면 충분합니다

포인트	이유
ID Token 검증	단순 문자열이 아니라 서명 검증해야 함
사용자 식별자(sub) 사용	이메일은 변경 가능한 값
Refresh Token 관리 방식	세션 유지 전략에 따라 보안/UX가 바뀜
HTTPS 필수	토큰은 민감 정보이기 때문

나머지는 대부분 라이브러리나 IdP 플랫폼에서 처리됩니다.

정리

OIDC는 OAuth 2.0 위에 “로그인 기능” 을 정식으로 추가한 표준
로그인 증명은 ID Token(JWT) 으로 전달됨
OIDC는 웹/모바일 시대에 최적화되어 있어 소셜 로그인 및 SaaS 인증 표준
Access Token은 “권한”, ID Token은 “로그인”

참고자료

공식 사이트: https://openid.net/connect/
Google OAuth Playground: https://developers.google.com/oauthplayground
Auth0 OIDC 설명: https://auth0.com/docs/authenticate/protocols/oidc

이어서 배우면 좋은 글

다음 중 하나를 골라주세요:

ID Token 안에 실제로 들어있는 JWT 분석 예시
OIDC + JWT + Refresh Token으로 로그인 유지 전략 비교
Next.js / React / SPA에서 OIDC 로그인 흐름 구현 정리

번호만 말해주세요. 1 / 2 / 3