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は、クライアントの種類に応じていくつかのフローを定義しています。モバイルアプリケーションの場合、標準はProof Key for Code Exchange (PKCE) を使用したAuthorization Code Flowです — デバイス上にclient secretがなくてもセキュリティを提供します。

Identity Providerとその役割

Identity Provider (IdP) は、ユーザーを認証しトークンを発行するサーバーです。OIDCエコシステムでは、IdPは2つの主要なエンドポイントを提供します: ユーザーログイン用の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とともにアプリケーションにリダイレクトします。

2番目のステップでは、アプリケーションがauthorization code、code verifier、client_idをサーバーのToken Endpointに送信します。サーバーはcode verifierを保存されたcode challengeと照合し、ID Token、Access Token、およびオプションでRefresh Tokenを返します。3番目のステップでは、アプリケーションが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は、根本的に異なる2つのトークン — 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ペイロードの例:

{
  "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) を備えたエンタープライズシステムの場合、選択は明確です: 標準化されたログアウトとセッション管理を提供する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()