OpenID Connect로 통합 인증 구조 이해하기
OpenID Connect의 인증 구조와 OAuth 2.0과의 차이, 토큰·리디렉션 URI·CSRF를 중심으로 통합 인증 설계 시 고려할 보안 요소를 정리한다.
2026-08-14 · 최초 발행 2025-06-15
하나의 디지털 신원으로 연결하는 인증
OpenID는 여러 웹 서비스에서 같은 디지털 신원으로 로그인할 수 있게 하는 개방형 사용자 인증 프로토콜이다. 서비스마다 계정을 새로 만들지 않고, 신뢰하는 Identity Provider(IdP)를 통해 접근한다는 점이 이 구조의 출발점이다.
이 체계는 2005년 Brad Fitzpatrick이 처음 제안한 뒤 발전을 거쳐 OpenID Connect(OIDC)로 이어졌다. 초기 OpenID 1.0은 기본적인 ID 공유 기능을 제공했고, OpenID 2.0은 보안과 기능을 확장했다. 현재의 OpenID Connect는 OAuth 2.0을 기반으로 하는 인증 프로토콜이다.
OIDC가 인증 정보를 전달하는 방식
OIDC는 OAuth 2.0 프레임워크 위에 인증 계층을 더해, 사용자 정보를 표준화된 형식으로 전달한다.
인증을 요청하는 애플리케이션이나 웹사이트는 Relying Party(RP)다. 실제 사용자 인증과 신원 정보 제공은 Identity Provider(IdP)가 담당하며, Google이나 Facebook 등이 여기에 해당한다. 서비스를 이용하려는 사람은 End-User로 부른다.
ID Token은 사용자 인증 정보를 담는 JWT(JSON Web Token) 형식의 토큰이다. UserInfo Endpoint는 클라이언트가 사용자에 관한 추가 정보를 요청할 때 사용하는 API 엔드포인트다.
리디렉션부터 세션 관리까지
클라이언트 애플리케이션은 사용자를 IdP의 인증 엔드포인트로 리디렉션하며 인증을 시작한다. 사용자가 IdP에 자격 증명을 제공해 인증에 성공하면, 클라이언트 애플리케이션에 정보를 제공할 권한을 부여한다.
그 뒤 IdP는 인증 코드를 클라이언트의 리디렉션 URI로 전달한다. 클라이언트는 이 코드를 토큰 엔드포인트에 제출해 ID 토큰과 액세스 토큰을 받고, 필요하다면 액세스 토큰으로 UserInfo Endpoint의 추가 사용자 정보를 요청한다. 최종적으로 클라이언트가 사용자 세션과 로그아웃 처리를 관리한다.
애플리케이션 성격에 따라 선택할 수 있는 흐름도 다르다.
- Authorization Code Flow는 서버 측 웹 애플리케이션에 적합하다.
- Implicit Flow는 브라우저 기반 JavaScript 애플리케이션에 적합하지만, 보안 강화를 위해 현재는 사용이 권장되지 않는다.
- Hybrid Flow는 Authorization Code와 Implicit Flow를 결합한다.
- Client Credentials Flow는 백엔드 서비스 간 통신에 적합하다.
- Resource Owner Password Credentials Flow는 기존 애플리케이션의 마이그레이션에 적합하지만, 보안 문제로 권장되지 않는다.
인증을 다루는 OIDC와 권한을 다루는 OAuth 2.0
OIDC와 OAuth 2.0은 함께 쓰일 수 있지만, 해결하려는 문제는 다르다.
| 특성 | OpenID Connect | OAuth 2.0 |
|---|---|---|
| 주요 목적 | 인증(Authentication) | 권한 부여(Authorization) |
| 응답 형식 | ID 토큰(JWT) + 액세스 토큰 | 액세스 토큰 |
| 사용자 정보 | 표준화된 클레임 세트 | 리소스 서버마다 다름 |
| 범위(Scope) | 표준화된 스코프(openid, profile, email 등) | 애플리케이션별 정의 |
구현에서 놓치기 쉬운 경계
클라이언트 ID와 시크릿은 안전하게 관리해야 하며, ID 토큰과 액세스 토큰의 서명 검증도 필수다. 인증 요청에는 state 파라미터를 사용해 CSRF 공격을 방지한다.
리디렉션 URI는 등록된 URI만 허용해 피싱 공격을 막고, 요청 범위는 필요한 최소 수준으로 제한한다. 모든 통신은 HTTPS로 암호화하며, 액세스 토큰과 리프레시 토큰에는 적절한 유효 기간을 설정해야 한다.
통합 인증이 쓰이는 장면
대기업 A사는 수십 개의 내부 시스템에서 직원이 별도로 로그인해야 하는 문제를 줄이기 위해 OpenID Connect를 도입했다.
이 도입으로 로그인 절차 간소화에 따른 업무 효율성은 50% 향상됐고, 계정 관리 비용은 70% 절감됐으며, 보안 인시던트는 40% 감소했다.
스타트업 B사는 가입 장벽을 낮추기 위해 Google, Facebook, Apple 등의 IdP를 통한 소셜 로그인을 OpenID Connect로 구현했다.
회원가입 완료율은 120% 증가했고, 사용자 인증 관련 고객지원 요청은 60% 감소했다. 사용자 데이터 관리 부담도 줄었다.
금융 서비스 C사는 다양한 마이크로서비스 API의 통합 인증을 위해 API 게이트웨이와 OpenID Connect를 함께 구현했다.
API 보안 관리가 일원화됐고, 개발자 경험 향상으로 신규 서비스 출시 시간은 40% 단축됐다. 규제 준수 보고 자동화로 감사 준비 시간도 80% 절감됐다.
디지털 신원 관리가 향하는 곳
OpenID는 블록체인 기술과 결합한 분산 ID(Decentralized Identity) 관리 체계로 발전하고 있다. FIDO2와의 통합을 통해 생체 인증과 하드웨어 토큰을 활용한 무암호(passwordless) 인증 지원도 강화되는 방향이다.
지속적인 인증과 컨텍스트 기반 접근 제어를 강조하는 Zero Trust 보안 모델, 선택적 정보 공개와 사용자 동의 메커니즘을 통한 개인정보 보호, 사물인터넷 기기까지의 인증 범위 확장도 함께 다뤄지고 있다.