OpenID Connect의 구조적 역할
OpenID Connect는 OAuth 2.0 인가 프레임워크 위에 인증 계층을 추가한 설계입니다. OAuth 2.0은 '이 애플리케이션이 어떤 리소스에 접근할 수 있는가'(인가)를 답하지만, OpenID Connect는 '현재 로그인한 사용자가 누구인가'(인증)를 증명합니다. 핵심 확장은 ID Token이라는 JWT 기반 보안 토큰으로, 인증 이벤트 자체에 대한 클레임(iss, sub, aud, exp, iat, auth_time, nonce 등)을 담아 클라이언트에 전달합니다.
3가지 인증 플로우와 아키텍처 선택
Authorization Code Flow는 기밀 클라이언트(백엔드 서버) 전용이며, 권한 부여 코드를 먼저 받은 후 Token Endpoint에서 ID Token과 Access Token을 안전하게 교환합니다. Implicit Flow는 자바스크립트 기반 클라이언트용으로 브라우저 프래그먼트에 토큰을 직접 반환하며 클라이언트 인증 없음이 특징입니다. Hybrid Flow는 Authorization Endpoint에서 일부 토큰을, Token Endpoint에서 나머지를 반환하여 지연시간을 줄이되 클라이언트 인증이 가능합니다. 실무에서는 클라이언트 타입(confidential/public)과 토큰 노출 위험도를 함께 고려하여 선택합니다.
실무 검증 포인트: ID Token과 클레임 관리
ID Token은 반드시 JWS로 서명되어야 하고, 선택적으로 JWE로 암호화됩니다. 클라이언트는 iss(발급자) 일치, aud(청중)에 자신의 client_id 포함 확인, exp(만료) 검증, nonce 값 재생 공격 방지를 필수로 수행해야 합니다. 클레임은 기본 set(name, email, phone_number 등)과 선택적 추가 클레임으로 나뉘며, scope 파라미터(openid, profile, email, address, phone) 또는 claims 파라미터로 요청합니다. 집계 클레임(Aggregated Claims)과 분산 클레임(Distributed Claims)은 제3자 claims provider 연계 시에만 필요하므로, 대부분의 구현에서는 기본 클레임으로 충분합니다.
클라이언트 인증과 보안 구성
Token Endpoint에 접근할 때 클라이언트는 client_secret_basic(HTTP Basic), client_secret_post(Form Body), client_secret_jwt(HMAC), private_key_jwt(비대칭) 중 하나로 인증합니다. Authorization Code Flow 사용 시 클라이언트 인증은 필수이며, 이는 Authorization Code 탈취 후 토큰 교환 공격을 방어합니다. Access Token은 UserInfo Endpoint 접근용 Bearer Token으로 전달되며, UserInfo Response 검증 시에는 반드시 sub 클레임이 ID Token의 sub와 일치하는지 확인하여 토큰 치환 공격(Token Substitution)을 차단합니다. 또한 nonce는 충분한 엔트로피를 가져야 하고, 서버는 이전 요청의 nonce와 정확히 일치하는지 검증해야 합니다.