이것저것/정보

OIDC(OpenID Connect)란?

DoMyBestForDeveloper 2026. 3. 10. 14:12

OpenID Connect는 디지털 서비스에 액세스하기 위해 로그인할 때 사용자를 인증하고 권한을 부여하는 프로세스를 표준화하기 위한 OAuth 2.0이 확장된 ID 인증 프로토콜임. OIDC는 인증을 제공함 (사용자가 본인임을 확인)
OAuth2.0은 해당 사용자가 액세스할 수 있는 시스템에 권한을 부여함. OAuth 2.0은 일반적으로 관련없는 두 애플리케이션이 사용자 데이터를 손상시키지 않고, 정보를 공유할 수 있도록 하는 데 사용됨.

예를 들면 많은 사람들이 새 사용자 이름 및 암호를 만드는 대신 이메일 또는 소셜 미디어 계정을 사용해 타사 사이트에 로그인함.

OIDC는 Single Sign-On을 제공하는 데도 사용됨. 조직은 ID의 기본 인증자로 IAM(ID 및 액세스 관리) 시스템을 활용한 다음 OIDC를 사용해 해당 인증을 다른 앱에 전달할 수 있음. 이렇게 하면 사용자가 여러 앱에 액세스하기 위해 하나의 사용자 이름 및 암호로 한 번만 로그인하면 됨

OIDC의 주요 구성 요소

  • 인증: 사용자가 자신의 신원을 확인하는 프로세스
  • 클라이언트: 사용자를 인증하거나 리소스에 액세스하는 데 사용되는 토큰을 요청하는 웹 사이트 또는 애플리케이션과 같은 소프트웨어
  • 신뢰 당사자: OpenID 공급자를 사용해 사용자를 인증하는 애플리케이션
  • ID 토큰*: 인증 프로세스의 결과, 사용자 식별자 및 사용자 인증 방법 및 시기에 대한 정보 등과 같은 ID 데이터를 포함할 수 있음
  • OpenId 공급자: 사용자에게 이미 계정이 있는 애플리케이션. OIDC에서 OpenID 공급자의 역할은 사용자를 인증하고, 해당 정볼르 신뢰 당사자에게 전달하는 것
  • 사용자: 새 계정을 만들거나 사용자 이름과 암호를 제공하지 않고, 애플리케이션에 액세스하려는 사용자 또는 서비스

OIDC 인증의 작동 방식

OIDC 인증은 사용자가 한 애플리케이션에 로그인하고 다른 애플리케이션에 대한 액세스 권한을 받을 수 있도록 허용하는 방식으로 작동함. 예를 들어 사용자가 뉴스 사이트에서 계정을 만들려는 경우 새 계정을 만드는 대신 Facebook을 사용해 계정을 만드는 옵션이 있을 수 있음. Facebook을 선택하는 경우 OIDC 인증을 사용함. OpenID 공급자라고 하는 Facebook은 인증 프로세스를 처리하고 사용자 프로필과 같은 특정 정보를 신뢰 당사자인 뉴스 사이트에 제공하기 위해 사용자의 동의를 얻음

ID 토큰

OpenID 공급자는 ID 토큰을 사용해 인증 결과 및 관련 정보를 신뢰 당사자에게 전송함. 전송되는 데이터 형식의 예로는 ID, 이메일 주소, 이름이 포함됨

범위

범위는 사용자가 액세스 권한으로 수행할 수 있는 작업을 정의함. OIDC는 토큰이 생성된 신뢰 당사자, 토큰이 생성된 시기, 토큰이 만료되는 시기 및 사용자를 인증하는 데 사용되는 암호화 강도와 같은 항목을 정의하는 표준 범위를 제공함

OIDC 인증 프로세스

  1. 사용자가 액세스하려는 애플리케이션(신뢰 당사자)으로 이동
  2. 사용자가 사용자 이름 및 암호화를 입력
  3. 신뢰 당사자가 OpenID 공급자에게 요청을 보냄
  4. OpenID 공급자는 사용자의 자격 증명의 유효성을 검사하고 권한 부여를 얻음
  5. OpenID 공급자는 ID 토큰과 종종 액세스 토큰을 신뢰 당사자에게 보냄
  6. 신뢰 당사자는 사용자 디바이스에 액세스 토큰을 보냄
  7. 액세스 토큰 및 신뢰 당사자에 제공된 정보에 따라 사용자에게 액세스 권한이 부여됨

OIDC 흐름이란?

OIDC 흐름은 토큰을 요펑하고, 신뢰 당사자에게 전달하는 방법을 정의함.

  • OIDC 권한 부여 흐름: OpenID 공급자가 신뢰 당사자에게 고유한 코드를 보냄. 그런 다음 신뢰 당사자는 토큰을 대신하여 고유 코드를 OpenID 공급자에게 다시 보냄. 이 메서드는 OpenID 공급자가 토큰을 보내기 전에 신뢰 당사자를 확인할 수 있도록 사용됨. 브라우저는 이 메서드에서 토큰을 볼 수 없으므로 보안을 유지하는 데 도움이 됨

  • PKCE 확장을 사용하여 OIDC 권한 부여 흐름: 이 흐름은 PKCE(코드 교환) 확장에 공개 키를 사용해 통신을 해시로 전송한다는 점을 제외하고, OIDC 권한 부여 흐름과 동일. 이렇게 하면 토큰을 가로챌 가능성이 줄어듦

  • 클라이언트 자격 증명: 이 흐름은 애플리케이션 자체의 ID를 사용해 웹 API에 대한 액세스를 제공함. 일반적으로 서버 간 통신 및 사용자 상호 작용이 필요하지 않은 자동화된 스크립트에 사용됨

  • 디바이스 코드: 이 흐름을 통해 사용자는 브라우저가 없거나 스마트 TV와 같은 키보드 환경이 좋지 않은 인터넷에 연결된 디바이스에서 웹 기반 API에 로그인하고 액세스할 수 있음

브라우저 기반 애플리케이션용으로 설계된 OIDC 암시적 흐름과 같으 추가 흐름은 위험이 있어 권장하지 않음

OIDC 및 OAuth 2.0

OIDC는 인증을 추가하기 위해 OAuth 2.0을 기반으로 빌드됨. OAuth2.0 프로토콜이 먼저 개발된 후 기능을 개선하도록 OIDC가 추가된 것

둘 간의 차이점은 OAuth2.0은 권한 부여를 제공하는 반면 OIDC는 인증을 제공함.

  • OAuth2.0: 사용자가 OpenID 공급자와 함께 자신의 계정을 사용해 신뢰 당사자에 액세스할 수 있도록 함
  • OIDC: OpenID 공급자가 사용자 프로필을 신뢰 당사자에게 전달할 수 있게 해 줌. 또한, OIDC를 사용하면 조직에서 사용자에게 Single Sign-On을 제공할 수 있음

Single Sing-On (SSO)
한 번의 로그인으로 여러 시스템과 서비스에 자동으로 접근할 수 있게 하는 통합 인증 방식
사용자가 하나의 인증 정보(ID/비밀번호)로 로그인하면, 연동된 모든 애플리케이션과 시스템에 별도 로그인 없이 자동으로 접속할 수 있도록 하는 통합 인증 방식

용어

  • Authentication: 부여된 Identity와 엔티티 사이의 결속(바인딩)에서 충분한 신뢰를 얻기 위한 프로세스
  • Authentication Request: 확장된 파라미터와 OpenID Connect가 정의한 scopes를 사용하는 OAuth 2.0 인증 요청
  • Claim: 엔티티에 대해 설명하는 정보
  • Entity: 문맥 안에서 별개로 분리되고 구별되는 존재로 식별되는 것. 최종 사용자는 엔티티의 한 예
  • Essential Claim: 사용자가 요청한 특정 테스크에 원활한 권한 부여 절차를 보장하기 위해 필요하고 사용자가 지정한 특정 클레임
  • Hybrid Flow: Authorization Endpoint에서 Authorization Code가 리턴되는 OAuth2.0 과정에서 어떤 토큰은 Authorization Endpoint에서 리턴되고, 어떤 토큰을 Token Endpoint에서 리턴됨
  • ID Token: 인증 이벤트에 대한 클레임을 포함한 JWT(JSON Web Toke). 다른 클레임을 포함할 수 있음
  • OpenID Provider(OP): 최종 사용자 인증과, 신뢰당사자(RP)에게 인증 이벤트와 최종 사용자엗 ㅐ한 Claims를 제공할 수 있는 OAuth2.0 Authorization Server(권한 서버)
  • Relying Party (RP): 신뢰 당사자. 최종 사용자 인증과 OpenID 공급자의 Claims를 요청하는 OAuth2.0 클라이언트 애플리케이션

1. OpenID Connect protocol 개요

+--------+                                   +--------+
|        |                                   |        |
|        |---------(1) AuthN Request-------->|        |
|        |                                   |        |
|        |  +--------+                       |        |
|        |  |        |                       |        |
|        |  |  End-  |<--(2) AuthN & AuthZ-->|        |
|        |  |  User  |                       |        |
|   RP   |  |        |                       |   OP   |
|        |  +--------+                       |        |
|        |                                   |        |
|        |<--------(3) AuthN Response--------|        |
|        |                                   |        |
|        |---------(4) UserInfo Request----->|        |
|        |                                   |        |
|        |<--------(5) UserInfo Response-----|        |
|        |                                   |        |
+--------+                                   +--------+
  1. RP(Client)는 OpenID Provider (OP)에게 요청을 보냄
  2. OP는 최종 사용자를 인증하고, 권한을 획득
  3. OP는 ID Token과 보통 access token으로 응답
  4. RP(Client)는 access token과 함께 UserInfo Endpoint에 요청을 보낼 수 있음
  5. UserInfo Endpoint는 최종 사용자에 대한 Claim을 반환함

2. ID Token

OpenID Connect가 최종 사용자가 인증되도록 OAuth2.0에 만드는 주된 확장은 ID Token 데이터 구조임
ID 토큰을 Client를 사용할 때 권한 서버에 의한 최종 사용자 인증에 대한 클레임과 그외 요청 클레임을 포함하고 잇는 보안 토큰임. ID 토큰은 JWT(JSON Web Token)로 표시됨

ID 토큰 내의 클레임 목록

  • REQUIRED

    • iss
    • sub
    • aud
    • exp
    • iat

  • OPTIONAL/REQUIRED

    • auth_time: 인증 발생 시간

  • nance

    • 클라이언트 세션을 ID 토큰과 연결하고, replay 공격을 완화하는 데 사용되는 문자열 값
    • 값은 인증 요청에서 ID 토큰으로 수정되지 않은 상태로 전달됨.
    • ID 토큰에 있는 경우 클라이언트는 nance 청구 값이 인증 요청에서 전송된 nance 매개 변수의 값과 동일한지 확인해야 함.
    • 인증 요청에 있는 경우 권한 부여 서버는 인증 요청에서 전송된 임시 값이 청구값과 함께 ID 토큰에 임시 청구를 포함해야 함.
    • 인가 서버는 사용된 nance 값에 대해 다른 처리를 수행하지 않아야 함

  • OPTIONAL

    • acr
    • amr
    • azp
      ID Token의 클레인 집합 예시
      {
"iss": "https://server.example.com",
"sub": "24400320",
"aud": "s6BhdRkqt3",
"nonce": "n-0S6_WzA2Mj",
"exp": 1311281970,
"iat": 1311280970,
"auth_time": 1311280969,
"acr": "urn:mace:incommon:iap:silver"
}

3. Authentication

OpenID Connect는 인증을 수행하여 최종 사용자가 로그인을 하거나 사용자가 이미 로그인 했는지 확인함
OpenID Connect는 서버에서 수행한 인증 결과를 클라이언트가 신뢰할 수 있도록 안전한 방식으로 Client에게 반환함
그러한 이유로 이 경우 Client를 Relying Party(RP)라고 부름

인증 결과는 ID Token 안에 반환함. ID Token은 발행자, 식별 주제, 인증 만료 시간 같은 정보를 표현하는 클레임을 갖고 있음

Authorization Code Flow를 이용한 인증

  1. 클라이언트는 원하는 요청 매개변수를 포함하는 인증 요청(Authentication Request)을 준비
  2. 클라이언트는 권한 부여 서버에 요청을 보냄
  3. 권한 부여 서버는 최종 사용자를 인증함
  4. 권한 부여 서버는 최종 사용자 동의/권한을 얻음
  5. 권한 부여 서버는 Authorization Code와 함께 최종 사용자를 크랄이언트로 다시 보냄
  6. 클라이언트는 Authorization Code를 사용해 Token Endpoint에게 응답을 요청
  7. 클라이언트는 response body에 ID 토큰과 액세스 토큰이 포함된 응답을 받음
  8. 클라이언트는 ID 토큰의 유효성을 검사하고 최종 사용자의 주체 식별자를 검색

인증 요청 검증

  1. 권한 부여 서버는 OAuth2.0 사양에 따라 모든 OAuth2.0 매개변수를 검증해야 함
  2. scope 매개변수가 있고, openid 범위 값을 포함하는지 확인 (openid 범위 값이 없는 요청은 여전히 유효한 OAuth2.0 요청일 수 있지만 OIDC 요청은 아님)
  3. 권한 부여 서버는 모든 필수 매개변수가 존재하고 사용이 이 사양을 준수하는지 확인해야 함
  4. sub 클레임이 ID토큰에 대한 특정 값으로 요청되는 경우, 권한 부여 서버는 해당 sub 값으로 식별된 최종 사용자가 권한 부여 서버와의 활성 세션을 가지고 있거나 다음과 같이 인증된 경우에만 긍정적인 응답을 보내야 함

ID 토큰 유효성 검사

  1. ID토큰이 암호화된 경우, OP가 ID 토큰을 암호화하는데 사용할 Registration 과정 중에 클라이언트가 지정한 키와 알고리즘을 사용해 암호를 해독
  2. OpenID 공급자에 대한 발급자 식별자는 iss(발급자) 클레임의 값과 정확히 일치해야 함
  3. 클라이언트는 aud 클레임이, 대상으로 iss클레임에 의해 식별된 발급자에 등록된 client_id 값을 포함하는지 확인해야 함
  4. ID 토큰에 여러 대상(audiences)이 포함된 경우 클라이언트는 azp 클레임이 있는지 확인해야 함
  5. azp 클레임이 있는 경우 클라이언트는 해당 client_id가 클레임 값인지 확인해야 함
  6. ID 토큰이 클라이언트와 토큰 끝점 간의 직접 통신을 통해 수신된 경우 TLS 서버 유효성 검사를 사용해 토큰 서명을 확인하는 대신 발급자를 확인할 수 있음. 클라이언트는 JWT alg 헤더 매개변수에 지정된 알고리즘을 사용하여 JWS에 따라 다른 모든 ID 토큰의 서명을 확인해야 함. 클라이언트는 발행자가 제공한 키를 사용해야 함
  7. alg 값는 RS256의 기본값이거나, 등록과정 중에 클라이언트가 id_token_signed_response_alg 매개변수에 작성한 알고리즘이어야 함
  8. JWT alg 헤더 매개변수가 HS256, HS384 또는 HS512와 같은 MAC 기반 알고리즘을 사용하는 경우 aud 클레임에 포함된 client_id에 해당하는 client_secret의 UTF-8 표현의 옥텟이 유효성을 검사하는 키로 사용됨
  9. 현재 시간은 exp 클레임이 나타내는 시간 이전이어야 함
  10. iat 클레임을 사용하여 현재 시간에서 너무 멀리 발행된 토큰을 거부하여, 공격을 방지하기 위해 nance를 저장해야 하는 시간을 제한할 수 있음. 허용 범위는 클라이언트에 따라 다름
  11. 인증 요청에서 nance 값이 전송된 경우 nance Claim이 존재해야 하며, 해당 값이 인증 요청에서 전송된 값과 동일한지 확인해야 함. 클라이언트는 replay 공격에 대한 nance값을 확인해야 함. 12. acr 클레임이 요청된 경우 클라이언트는 클레임 값이 적절한지 확인해야 함. acr 클레임 값의 의미와 처리는 이 사양의 범위를 벗어남
  12. 이 클레임에 대한 특정 요청을 통하거나, max_age 매개변수를 사용해 auth_time 클레임이 요청된 경우 클라이언ㄴ트는 auth_time 클레임 값을 확인하고 마지막 최종 사용자 인증 이후 너무 많은 시간이 경과했다고 판단되면 재인증을 요청해야 함

'이것저것 > 정보' 카테고리의 다른 글

[아키텍처] 헥사고날 아키텍처  (0) 2026.03.17
Spring REST Docs란?  (0) 2026.03.03
사이버 보안  (0) 2025.12.08

'이것저것/정보'의 다른글

  • 현재글OIDC(OpenID Connect)란?

관련글

티스토리툴바