OIDC (Open ID Connect)

hi2li·2026년 6월 6일
networksecurity

security

목록 보기
3/12

Authentication과 Authorization의 차이

  • 인증 : 사용자의 신원을 확인하는 과정.
  • 인가 : 인증된 사용자에게 특정 자원에 대한 접근권한을 부여하는 과정





OAuth 2.0과 OIDC의 차이점

  • Oauth 2.0 : “인가” 프로토콜
  • OIDC : OAuth 2.0을 확장하여, 사용자의 인증 정보를 안전하게 전달하는 인증 프로토콜
    • OAuth 2.0위에서 동작함






등장배경

  • OAuth 2.0이라는 인가 프로토콜이 존재했다.
  • 이는 사용자가 어떤 앱에게 내 리소스에 접근할 권한을 위임하기 위해 존재했다.
  • 예를 들어, 나의 로컬 캘린더 앱이 구글 캘린더를 읽을 수 있게 허용하는 것이다.
  • 결국 “인가”에 집중된 프토콜이다.

OAuth 2.0은 원래 인가를 위한 프로토콜이지만, 서비스들은 OAuth 2.0을 이용하여 “Google로 로그인”, “GitHub로 로그인” 과 같은 기능을 구현하기 시작했다.

하지만 OAuth 2.0 자체는 사용자 인증을 위한 표준 규격이 아니었기 때문에, 사용자의 신원을 일관되게 표현하는 데 한계가 있었다.

→ 그래서 나온 것이 OIDC이다.





OIDC란?

  • OAuth 2.0 기반의 사용자 인증 프로토콜

→ OIDC는 OAuth 2.0 위에 다음내용들을 추가한다.

  • ID Token
  • UserInfo Endpoint
  • 표준 사용자 정보 Claim
  • 로그인 세션 개념





OIDC의 구성요소

[1. resource Owner]

  • 서비스에 로그인 하는 사람(회원)


[2. client]

  • 인증을 OIDC Provider (Identity Provider) 에 위임하는 서비스
  • 사용자 인증을 직접 처리 하지 않고, OIDC Provider로 부터 인증 결과 (ID Token)을 받아 사용하는 애플리케이션


[3. Identity Provider]

  • 사용자를 인증하는 서버 (구글, 마이크로소프트, 키클락등)
  • 사용자의 로그인 정보를 client 애플리케이션 대신 검증한다.
  • 인증이 완료되면 Authorization Code를 생성하고, 이를 통해 ID Token, Access Token, Refresh 을 발급한다.





Endpoints

  • End point는 기능을 나누기 위한 API진입점이다.
  • OIDC가 하나의 서버라고 하더라도 모든 요청을 하나의 URL에서 처리하지 않기 떄문에 Endpoint가 필요하다.
  • 일반 웹서비스 의 엔드포인트들.
https://api.example.com/login
https://api.example.com/users
https://api.example.com/products
https://api.example.com/orders

URL마다 역할이 다른 것처럼 OIDC도 대표적으로 3개의 기능을 엔드포인트로 구분했다.

[ Authorization endpoint ]

  • 사용자 인증 요청을 처리하는 엔드포인트
  • 사용자를 로그인 페이지로 이동시키고 인증 요청을 처리한다.
  • 실제 인증은 OIDC Provider 내부 로직을 통해 수행된다.

[ Token Endpoint ]

  • 토큰 발급 요청을 처리하는 엔드포인트
  • Authorization code를 검증하고, ID token, access token , Refresh token을 발급

[ UserInfo Endpoint ]

  • 사용자 정보 조회 요청을 처리하는 엔드포인트
  • Access Token 을 이용하여 사용자 정보를 제공





Tokens

OIDC에서는 인증 및 권한 처리를 위해 여러 종류의 토큰을 사용한다.

[ID Token]

  • 사용자의 신원을 증명하는 토큰
  • OIDC의 핵심 토큰으로 사용자가 누구인지 확인하기 위한 정보를 포함한다.
  • Client는 이 토큰을 통해 사용자의 로그인 여부를 확인할 수 있다.

[Access Token]

  • API 접근 권한을 증명하는 토큰
  • 보호된 리소스에 접근할 때 사용된다.
  • 사용자가 어떤 권한을 가지고 있는지 확인하기 위해 사용된다. (인가 느낌의 토큰)

[Refresh Token]

  • 토큰 재발급을 위한 토큰
  • Access Token이 만료되었을 때 사용자 재로그인 없이 새로운 토큰을 발급받을 수 있게 해준다.
  • 일반적으로 Access Token보다 긴 만료 시간을 가진다.





OIDC의 동작과정

  • OIDC는 사용자의 인증을 client 애플리케이션이 직접 수행하지 않고, OIDC Provider에게 위임하는 구조로 동작한다.

  • 대표적인 흐름은 Authorization code Flow이다.

1. 사용자가 client 애플리케이션에 접속

2. client가 Authorization Endpoint로 사용자를 이동시킴

3. OIDC Provider가 사용자를 인증

4. 인증 성공 후 Authorization code를 전달 

5. client가 Token endpoint에 Authorization code를 전달

6. OIDC Provider가 그 Authorization code를 검증하고 여러개의 토큰을 발급 (ID Token, Access Token, Refresh Token)

7. Client는 ID Token을 검증하고 사용자의 로그인 세션을 생성

8. 이후 서비스는 Access Token에 포함된 권한 정보(Role, Scope 등)를 기반으로 사용자가 수행할 수 있는 작업을 결정





인증 결과 검증 및 로그인 세션 생성

  • OIDC Provider가 사용자를 인증했다고 해서 Client가 해당 결과를 무조건 신뢰하는 것은 아니다.
  • Client는 전달받은 ID Token이 신뢰할 수 있는 OIDC Provider가 발급한 정상 토큰인지 검증해야 한다. (검증이 없다면 공격자가 위조하여 악용할 수 있다. )


[JWT (JSON Web Token)]

ID Token은 JWT 형식으로 제공된다.

JWT는 사용자에 대한 정보와 인증정보를 안전하게 전달하기 위한 토큰 형식이다. JWT는 다음과 같이 3개의 영역으로 구성된다.

JWT = Header.Payload.Signature



[ 검증 항목 ]

  • client는 OIDC Provider가 제공하는 “공개키”와 미리 설정된 issuer, client_id정보를 이용하여 ID Token의 유효성을 검증한다.
  • 검증 대상은 다음과 같다
1. 토큰 서명 -> 해당 토큰이 실제 OIDC provider가 발급한 토큰인지 확인

2. 발급자 -> 토큰 발급자가 신뢰하는 OIDC Provider인지 확인

3. 대상 -> 해당 토큰이 실제로 client대상으로 발급된 토큰인지 확인

4. 만료시간 -> 토큰이 만료되지 않았는지 확인



[ 공개키와 설정값을 이용한 검증 과정 ]

  • OIDC Provider는 ID Token을 발급할 때 자신의 개인키(Private Key)로 토큰에 서명한다.

  • 또한 JWT Header에는 “서명 알고리즘”과 “공개키 식별정보”가 저장되어 있다.

{
"alg": "RS256", -> 해당 알고리즘으로 서명됨
"kid": "key-2026" -> 제공되는 공개키 목록 중 "key-2026"에 해당하는 공개키를 사용하라 
}

OIDC Provider는 공개키를 외부에 공개하며, Client는 OIDC Provider가 제공하는 공개키 조회 엔드포인트에서 공개키 목록을 조회할 수 있다.

Client는 이 키들 중 kid에 해당하는 공개키를 이용하여 토큰을 검증한다.

{
  "keys": [
    {"kid": "key-2024"},
    {"kid": "key-2025"},
    {"kid": "key-2026"}
  ]
}

→ 검증이 성공하면 해당 토큰이 실제 OIDC Provider가 발급한 토큰이며, 중간에 위변조되지 않았음을 확인할 수 있다.


  • 그 다음 Client는 Payload 영역에 포함된 정보를 자신의 설정값과 비교한다.

  • Client는 OIDC 연동 시 자신이 신뢰하는 OIDC Provider의 issuer 정보와 자신의 client_id를 설정 파일에 미리 등록해둔다.

예를 들어 , Client 설정이 다음과 같다고 가정하자.

issuer = https://keycloak.aolda.kr/realms/aolda

client_id = acc

그리고 ID Token 안에 다음 정보가 포함되어 있다고 하자.

iss = https://keycloak.aolda.kr/realms/aolda

aud = acc

exp = 1710000000

Client는 다음과 같은 검증을 수행한다.

  • 설정파일의 issuer과 token의 iss 비교 → 토큰의 발급자가 자신이 신뢰하는 OIDC Provider인지 확인
  • 설정파일의 client_id와 token의 aud를 비교 → 해당 토큰이 현재 Client를 대상으로 발급된 토큰인지 확인
  • 현재시간과 token의 exp값을 비교 → 토큰이 만료되지 않았는지 확인

모든 검증이 성공하면 Client는 해당 ID Token을 신뢰할 수 있는 인증 결과로 판단한다.


즉, 검증 과정에서는

  • Signature → 공개키를 이용하여 토큰 위조 여부 검증
  • iss → issuer값 과 비교하여 신뢰하는 OIDC Provider가 발급한 토큰인지 검증
  • aud → client_id값과 비교하여 현재 Client를 대상으로 발급된 토큰인지 검증
  • exp → 현재 시간과 비교하여 만료되지 않은 토큰인지 검증


[ 로그인 세션 생성 ]

  • 모든 검증이 완료되면 client는 사용자를 정상적으로 인증된 사용자로 판단한다.
  • 이후 client는 자체 로그인 세션을 생성한다.
  • 사용자는 이후 요청마다 ID Token을 다시 검증하지 않으며, Client가 생성한 로그인 세션을 이용하여 서비스를 사용한다.
profile
hi2li
Easy come , Easy go
이전 포스트

kerberos

다음 포스트

TLS handshake

0개의 댓글