이 글에 등장하는 전체 코드는 깃허브 저장소에서 확인할 수 있다.
OIDC는 OAuth2에 인증 기능을 추가한 확장 프로토콜이므로, 구현 과정은 이전 글과 거의 동일하지만… 제공자가 OIDC를 지원해야만 이 방식으로 구현이 가능하다.
사용자 로그인 진입점#
OIDC에서는 로그인 페이지로 진입할 때,
OAuth2에서 전달하는 기본 파라미터(client_id, response_type, redirect_uri)에 scope파라미터가 필수로 포함된다. 이 scope에는 반드시 openid가 포함되어야 하며, 필요한 사용자 정보 항목을 추가로 명시할 수 있다.
예:
scope=openid profile email
사실 구글은 openid가 포함되지 않아도 oidc를 지원한다
해당 화면에서 사용자는 구글 계정으로 인증을 진행하게 된다.
리다이렉트#
리다이렉트 단계는 이전 글과 동일하다.
마찬가지로 code가 전달되고, 이 code를 사용해 토큰과 교환한다.
하지만 차이점은,
OIDC 프로토콜에서는 사용자의 정보를 담은 JWT 형식의
id_token이 함께 응답에 포함된다!!! 이 ID 토큰을 검증하면, 사용자를 신뢰할 수 있는 방식으로 인증할 수 있다.
구글 응답 예제:
{
"access_token": "access_token",
"expires_in": 3598,
"scope": "https://www.googleapis.com/auth/userinfo.email openid",
"token_type": "Bearer",
"id_token": "{{대충 jwt토큰}}"
}물론 Google의 다른 API를 사용하려면 access_token을 활용해야 하지만, 더 이상 사용자를 인증하기 위해 다시 제공자에게 요청할 필요가 없다.
추가#
OIDC가 특히 빛을 발하는 순간은 모바일 앱과 같이
“추가적인 사용자 정보 API 호출이 어렵거나, 클라이언트 시크릿을 안전히 보관하기 어려운” 환경이다.
이때 프론트엔드는 Authorization Code Flow with PKCE로 받은 id_token을 백엔드로 전달하고, 백엔드에서 JWT 서명 및 클레임(iss, aud, exp 등)을 검증하면 안전하고 간편하게 인증을 처리할 수 있다.
이 방법을 사용할 때 백엔드 검증이 필수인 이유는,
악의적인 사용자가id_token을 위·변조하여 전송할 수 있기 때문이다.
id_token은 비대칭 암호화(RS256) 방식으로 보호되며, 이 서명을 검증하기 위한 공개 키는 제공자(구글)이 공개한 well‑known jwks_uri 즉, 에서 가져올 수 있다.
추가 설정은 OpenID Connect 디스커버리 문서 google openid-configuration에서 확인할 수 있다.