OpenID Connect: 개념, 인증 및 권한 부여 프로토콜

OpenID Connect란?

OpenID Connect (OIDC)는 OAuth 2.0의 확장으로 구축된 개방형 인증 프로토콜입니다. OAuth 2.0에 없었던 것 — 사용자 ID 확인 — 을 표준화합니다. OAuth 2.0이 “어떤 애플리케이션이 액세스 권한이 있는가?”라는 질문에 답한다면, OIDC는 “이 사용자는 정확히 누구인가?”에 답합니다.

이 프로토콜은 ID Token — 고유 주체 식별자, 이메일, 이름, 아바타, 발행 및 만료 타임스탬프 등 클레임 집합을 포함하는 JSON Web Token (JWT) — 을 사용합니다. 클라이언트 애플리케이션은 ID Token을 암호학적으로 검증할 수 있습니다 — 서버는 RS256 또는 ES256을 사용하여 토큰에 서명하고, 클라이언트는 JWKS 엔드포인트를 통해 얻은 공개 키로 서명을 확인합니다.

Auth0, 2025에 따르면, 타사 인증을 사용하는 모바일 애플리케이션의 78% 이상이 Google Sign-In 또는 Sign in with Apple을 통해 OIDC를 사용합니다. 이로 인해 이 프로토콜은 소셜 로그인 및 엔터프라이즈 인증의 사실상 표준이 되었습니다.

OpenID Connect 작동 방식

OpenID Connect는 클라이언트 유형에 따라 여러 흐름(flows)을 정의합니다. 모바일 애플리케이션의 경우 표준은 PKCE(Proof Key for Code Exchange)를 사용한 Authorization Code Flow입니다 — 장치에 client secret이 없어도 보안을 제공합니다.

Identity Provider와 그 역할

Identity Provider (IdP)는 사용자를 인증하고 토큰을 발행하는 서버입니다. OIDC 생태계에서 IdP는 두 가지 주요 엔드포인트를 제공합니다: 사용자 로그인을 위한 Authorization Endpoint와 코드를 토큰으로 교환하기 위한 Token Endpoint입니다. 클라이언트는 Discovery URL — 표준 경로 /.well-known/openid-configuration — 을 통해 이러한 엔드포인트의 주소를 발견하며, 이는 전체 제공자 구성이 포함된 JSON 문서를 반환합니다.

각 IdP는 자체 JWKS (JSON Web Key Set)를 게시합니다 — ID Token 서명을 확인하기 위한 공개 키 집합입니다. 클라이언트는 이러한 키를 캐시하고 서버에 문의하지 않고 수신된 각 토큰을 확인하는 데 사용합니다.

PKCE를 사용한 Authorization Code Flow

Authorization Code Flow는 3단계 프로세스입니다. 먼저, 모바일 애플리케이션이 code verifier (43~128자의 무작위 문자열)와 그 해시 — code challenge — 를 생성합니다. 애플리케이션은 client_id, redirect_uri, scope (openid profile email) 및 code challenge가 포함된 URL로 브라우저 또는 WebView를 엽니다. 사용자는 IdP 페이지에서 자격 증명을 입력하고 동의를 확인합니다. IdP는 authorization code와 함께 브라우저를 애플리케이션으로 리디렉션합니다.

두 번째 단계에서, 애플리케이션은 authorization code, code verifier 및 client_id를 서버의 Token Endpoint로 보냅니다. 서버는 저장된 code challenge와 code verifier를 확인하고 ID Token, Access Token 및 선택적으로 Refresh Token을 반환합니다. 세 번째 단계에서, 애플리케이션은 ID Token을 검증합니다: JWKS에 대한 서명 유효성 검사, issuer (iss), audience (aud) 및 만료 시간 (exp)을 확인합니다. 검증에 성공하면 사용자는 인증된 것으로 간주됩니다.

PKCE (Proof Key for Code Exchange)는 공개 클라이언트의 표준 Authorization Code Flow에 내재된 취약점을 제거합니다. 모바일 애플리케이션은 client secret을 안전하게 저장할 수 없기 때문에, authorization code를 가로챈 공격자가 이를 토큰으로 교환할 수 있습니다. Code verifier는 이 문제를 해결합니다: 코드가 가로채져도 원래 code verifier 없이는 교환이 불가능합니다. OAuth Security Best Practices (RFC 9700)는 모바일 애플리케이션을 포함한 모든 공개 클라이언트에 PKCE를 요구합니다.

ID Token 및 Access Token

OpenID Connect는 근본적으로 다른 두 가지 토큰 — ID Token과 Access Token — 을 반환합니다. ID Token은 항상 JWT이며 클라이언트가 자체적으로 읽고 검증할 수 있습니다. 사용자 정보를 포함하며 API 액세스가 아닌 인증에 사용됩니다.

ID Token 구조

ID Token은 Base64로 인코딩되고 점으로 구분된 header, payload 및 signature로 구성됩니다. header에는 alg (서명 알고리즘)와 kid (키 식별자)가 포함됩니다. payload에는 필수 클레임이 포함됩니다: iss (issuer), sub (subject — 고유 사용자 ID), aud (audience — 클라이언트 식별자), exp (expiration), iat (issued at). 선택적 클레임에는 name, email, picture, locale이 있습니다.

Google에서 디코딩된 ID Token payload 예시:

{
  "iss": "https://accounts.google.com",
  "sub": "1234567890",
  "aud": "my-app-123.apps.googleusercontent.com",
  "exp": 1812345678,
  "iat": 1812342078,
  "name": "Ivan Petrov",
  "email": "ivan@example.com"
}

Access Token은 클라이언트가 API 요청에 전달하는 불투명 토큰(임의 문자열) 또는 JWT입니다. ID Token과 달리, access token은 클라이언트가 읽도록 설계되지 않았습니다 — 그 형식과 내용은 리소스 서버와 권한 부여 서버만 알고 있습니다. Access Token에는 범위(권한 제한)와 짧은 수명이 있으며, 일반적으로 15~60분입니다.

OpenID Connect와 OAuth 2.0의 차이점

OAuth 2.0은 애플리케이션이 사용자 리소스에 액세스하는 방법을 정의하는 권한 부여 프레임워크입니다. OpenID Connect는 이 프로세스에 인증을 추가하는 확장 기능입니다. 주요 차이점: OAuth 2.0은 토큰 형식을 정의하지 않으며 애플리케이션에 누가 요청했는지 알 수 있는 방법을 제공하지 않습니다.

OpenID Connect를 선택해야 하는 경우

OpenID Connect는 애플리케이션이 사용자 데이터에 액세스하는 것뿐만 아니라 사용자를 식별해야 할 때 필요합니다. “Google로 로그인” 또는 “Apple로 로그인”을 사용하는 경우 — 그것이 OIDC입니다. 애플리케이션이 사용자의 신원을 알 필요 없이 사용자를 대신하여 타사 API를 호출하는 경우 — 순수 OAuth 2.0으로 충분합니다. SSO(Single Sign-On)를 사용하는 엔터프라이즈 시스템의 경우 선택은 명확합니다: 표준화된 로그아웃 및 세션 관리를 제공하는 OpenID Connect만 가능합니다.

모바일 애플리케이션에서 OpenID Connect 구현

OpenID Connect를 모바일 애플리케이션에 통합하려면 적절한 라이브러리를 선택하고 흐름을 올바르게 구성해야 합니다. Android의 경우 credential manager (AndroidX Credentials) 또는 AppAuth 라이브러리를 사용합니다. iOS의 경우 ASWebAuthenticationSession과 함께 AuthenticationServices 프레임워크를 사용합니다.

Kotlin 코드 예제 (Android)

다음은 AppAuth-Android 라이브러리를 사용하여 Authorization Code Flow를 시작하는 예제입니다. 애플리케이션이 인증 요청을 생성하고, 사용자 로그인을 위해 브라우저를 열고, 토큰이 포함된 콜백을 처리합니다.

val authRequest = AuthorizationRequest.Builder(
    serviceConfig,
    clientId,
    "code",
    Uri.parse("com.example.app:/oauth")
)
.setScope("openid profile email")
.build()

val authService = AuthorizationService(this)
val intent = authService.getAuthorizationRequestIntent(authRequest)
startActivityForResult(intent, REQUEST_CODE)

override fun onActivityResult(
    requestCode: Int,
    resultCode: Int,
    data: Intent?
) {
    if (requestCode == REQUEST_CODE) {
        val response = AuthorizationResponse.fromIntent(data)
        if (response?.authorizationCode != null) {
            exchangeCodeForTokens(response.authorizationCode)
        }
    }
}

Swift 코드 예제 (iOS)

Apple의 ASWebAuthenticationSession은 iCloud Keychain을 통한 SSO 지원과 함께 OIDC 흐름을 위한 내장 브라우저를 제공합니다. 세션은 인증 URL로 시작되며, 콜백은 completion handler를 통해 처리됩니다.

OpenID Connect용 라이브러리를 선택할 때 내장 PKCE 지원을 고려하세요: AppAuth-Android와 AppAuth-iOS는 기본적으로 PKCE를 지원합니다. Firebase Authentication은 Google Sign-In, Sign in with Apple 및 Microsoft를 위해 내부적으로 OIDC를 사용합니다 — 개발자가 수동으로 흐름을 구현할 필요가 없습니다. 사용자 지정 IdP(예: Keycloak 또는 Okta)를 사용하는 엔터프라이즈 시스템의 경우, AppAuth는 구성 및 오류 처리에 대한 완전한 제어를 제공하는 표준 선택입니다.

let authURL = URL("https://accounts.google.com/o/oauth2/v2/auth")!
let callbackURL = URL("com.example.app://oauth")!

let session = ASWebAuthenticationSession(
    url: authURL,
    callbackURLScheme: callbackURL.scheme!
) { url, error in
    guard let url = url else { return }
    let components = URLComponents(url: url)
    let code = components?.queryItems?.first(where: { $0.name == "code" })?.value
    if let code = code { exchangeCode(code) }
}
session.start()