OpenID Connect（OIDC）とは？仕組みや意味をわかりやすく解説！（認証：認可：OAuth2.0との関係：フローの種類など）

OpenID Connect（OIDC）とは？仕組みや意味をわかりやすく解説！（認証：認可：OAuth2.0との関係：フローの種類など）

Webサービスやスマートフォンアプリで見かける「Googleでログイン」「Microsoftアカウントで続行」といった機能は、複数の仕組みが連携して成り立っています。

その中心的な技術の一つがOpenID Connect、略してOIDCです。

OIDCを理解すると、ログイン機能の設計、外部サービス連携、APIの安全な利用について、用語だけではつかみにくかった関係が整理しやすくなります。

本記事ではOIDCの意味、OAuth2.0との違い、トークン、代表的な認証フロー、導入時の注意点まで、実務で役立つ視点から解説します。

OpenID Connect（OIDC）の意味と役割

それではまずOpenID Connect（OIDC）の意味と役割について解説していきます。

OIDCが提供する本人確認

OIDCは、利用者が誰であるかを確認するための認証プロトコルです。

アプリケーションが自前でIDとパスワードを保管せず、信頼できる認証事業者にログイン処理を任せ、認証結果を受け取る形で利用されます。

たとえば利用者がGoogleアカウントでログインするとき、利用者はGoogle側で本人確認を受けます。

ログイン先のサービスは、Googleから返される情報をもとに、利用者を識別する流れです。

OIDCでは認証を担当する側をOpenID Provider、略してOPと呼びます。

認証結果を受け取ってサービスを提供するアプリケーションはRelying Party、略してRP、またはClientと呼ばれます。

この役割分担により、利用者は複数のサービスで同じ認証基盤を利用しやすくなります。

認証と認可の違い

OIDCを理解するうえで、認証と認可を区別することが重要です。

認証は、その利用者が本人であることを確かめる処理です。

一方で認可は、本人確認済みの利用者に対し、どの情報や機能へのアクセスを許可するかを決める処理を指します。

項目	確認する内容	具体例
認証	誰がアクセスしているか	メールアドレスとパスワードによるログイン
認可	何をしてよいか	予定表データの読み取り許可
識別	利用者を区別するための情報	一意のユーザーID

ログインに成功しても、すべての機能やデータに自由にアクセスできるわけではありません。

認証後に必要な権限だけを認可するため、個人情報や業務データを扱うサービスでも安全性を保ちやすくなります。

OIDCは認証を補い、OAuth2.0は認可の仕組みを提供すると覚えると、両者の関係を把握しやすいでしょう。

シングルサインオンとの関係

OIDCはシングルサインオン、略してSSOを実現する技術としても広く採用されています。

SSOとは、一度認証した利用者が、許可された複数のサービスへ再度パスワードを入力せずに移動できる仕組みです。

企業内では、グループウェア、勤怠管理、ファイル共有、業務アプリケーションなどを共通のID基盤につなぐ場面があります。

利用者はログイン操作を減らせるため、利便性が高まります。

管理者にとっても、退職者のアカウント停止や多要素認証の適用を認証基盤側へ集約しやすい点がメリットです。

ただし、認証基盤が停止すると多くのサービスに影響が及ぶ可能性があります。

可用性、障害時の運用、緊急アクセスの設計まで含めて検討することが大切です。

OAuth2.0とOIDCの関係

続いてはOAuth2.0とOIDCの関係を確認していきます。

OAuth2.0が扱う委任

OAuth2.0は、利用者のパスワードをアプリケーションに渡さずに、特定の操作権限を委任するための認可フレームワークです。

たとえば写真編集アプリが、利用者のクラウドストレージに保存された画像を読み取るケースを考えます。

このとき利用者は認証事業者の画面で、写真編集アプリに画像へのアクセスを許可します。

アプリケーションは許可された範囲で使えるアクセストークンを受け取り、APIを呼び出します。

OAuth2.0単体では、ログイン中の利用者が誰かをアプリケーションが確実に把握するための標準的な情報形式までは定めていません。

ここにOIDCが加わることで、認証情報を扱えるようになります。

IDトークンを追加するOIDC

OIDCはOAuth2.0を基盤として、IDトークンという認証用のトークンを追加した仕様です。

IDトークンには、認証された利用者を表す識別子、発行者、対象アプリケーション、有効期限などが格納されます。

多くの場合、IDトークンはJWTという署名付きのデータ形式で発行されます。

アプリケーションは署名、発行者、受信者、有効期限、リクエストとの対応関係を検証し、認証結果を信頼できるか判断します。

両方とも文字列として扱われることが多いため、用途を混同しない注意が必要です。

IDトークンをAPIの認可判定だけに流用しないことが、基本的な安全対策になります。

scopeによる要求情報の指定

OIDCでは、アプリケーションが求める情報や権限をscopeという値で指定します。

OIDCを利用するには、通常はopenidというscopeを必ず含めます。

加えてprofile、email、address、phoneなどを指定すると、利用者の同意を前提として対応する情報を取得できます。

scope	主な目的	取得対象の例
openid	OIDC認証の要求	利用者識別子とIDトークン
profile	基本プロフィールの取得	氏名、表示名、画像
email	メール情報の取得	メールアドレス、確認状態
offline_access	再認証なしの継続利用	リフレッシュトークン

取得する情報は、サービス提供に必要な範囲へ絞るべきです。

必要性の低い個人情報を広く要求すると、利用者の不安につながり、同意画面で離脱される要因にもなります。

最小権限の考え方を取り入れ、scopeごとの利用目的を明確にしましょう。

OIDCで利用する主要な要素

続いてはOIDCで利用する主要な要素を確認していきます。

認証サーバーとアプリケーションの役割

OIDCの処理では、利用者、アプリケーション、認証サーバー、必要に応じてAPIサーバーが関わります。

アプリケーションは認証を開始し、利用者を認証サーバーの画面へ転送します。

認証サーバーはログインや多要素認証を実施し、利用者の同意を取得します。

その後、認証結果やトークンをアプリケーションへ返す流れです。

認証サーバーのURL、公開鍵、対応するエンドポイントなどは、Discovery Documentを通じて取得できる場合があります。

この仕組みにより、アプリケーションは認証事業者ごとの設定を標準的な方法で参照できます。

発行者を表すissuerの完全一致確認は、偽装された認証サーバーを避けるうえで特に重要です。

IDトークンとアクセストークンの使い分け

IDトークンは、認証が行われたことをクライアント側で確認するために使われます。

代表的なクレームとして、利用者を一意に識別するsub、発行者のiss、宛先を示すaud、有効期限のexpがあります。

アクセストークンは、リソースサーバーがAPIアクセスを許可するか判定する目的で使用します。

アクセストークンの形式はJWTとは限らず、認証サーバーだけが意味を解釈できる不透明な文字列の場合もあります。

トークンをログへ出力したり、URLのクエリ文字列に残したりすると、漏えいリスクが高まります。

ブラウザー、モバイル端末、サーバーのどこに保存するかも、アーキテクチャに応じて慎重に設計してください。

クレームとユーザー情報

クレームとは、トークンやUserInfo Endpointで返される利用者に関する属性情報です。

subはOIDCにおける中心的なクレームであり、サービス側でユーザーを紐付ける際の基準になります。

メールアドレスは変更される可能性があり、同じアドレスが将来別の状態になる事情も考えられます。

そのため、ユーザーの恒久的な識別には、原則としてissuerとsubを組み合わせた識別子を用いる方法が適しています。

アプリケーションでは、氏名やメールアドレスを初回登録時だけ使うのか、ログインのたびに同期するのかも決めておく必要があります。

プロフィール情報の更新方針が曖昧だと、アカウント統合や通知先の管理で問題が起こりやすくなります。

OIDC認証フローの種類

続いてはOIDC認証フローの種類を確認していきます。

Authorization Code Flow

Authorization Code Flowは、現在のWebアプリケーションやモバイルアプリケーションで広く推奨される基本的なフローです。

利用者がアプリケーションからログインを開始すると、認証サーバーへ移動します。

認証と同意が完了すると、アプリケーションには一時的な認可コードが返されます。

アプリケーションはそのコードを認証サーバーへ送り、IDトークンやアクセストークンを受け取ります。

トークンを直接フロントチャネルで渡す方式に比べ、露出を抑えやすい点が特徴です。

サーバーサイドWebアプリでは、クライアントシークレットを安全に保持できるため、コード交換の保護を行いやすくなります。

ただし、リダイレクトURIの登録と照合を厳格に行わなければ、認可コードの横取りにつながるおそれがあります。

PKCEを使った安全性の強化

PKCEは、認可コード横取り攻撃への対策として使われる拡張仕様です。

読み方はピクシーであり、Public Key for Code Exchangeの略称です。

アプリケーションは認証開始時にcode verifierというランダムな値を作成し、その変換値であるcode challengeを認証リクエストへ含めます。

後のトークン交換では元のcode verifierを送信し、認証サーバーが整合性を確認します。

これにより、途中で認可コードだけを取得した第三者が、トークンへ交換しにくくなります。

公開クライアントではAuthorization Code Flow with PKCEを選択する考え方が一般的です。

スマートフォンアプリ、デスクトップアプリ、ブラウザー上で動くシングルページアプリでは、クライアントシークレットを安全に隠し続けることが難しいためです。

Implicit FlowとDevice Authorization Flow

Implicit Flowは、かつてブラウザー中心のアプリケーションで利用された方式です。

現在はトークンがブラウザー経由で露出しやすいなどの理由から、新規導入では慎重な判断が求められます。

多くのケースでは、Authorization Code FlowにPKCEを組み合わせる構成が選ばれます。

一方で、テレビ、ゲーム機、CLIツールのように入力手段が限られる機器では、Device Authorization Flowが役立ちます。

利用者は別のスマートフォンやPCで認証ページを開き、画面に表示されたコードを入力して承認します。

フロー	主な利用場面	考慮点
Authorization Code Flow	Webアプリ、バックエンド	安全性と汎用性のバランス
Code Flow with PKCE	モバイル、SPA、公開クライアント	コード横取り対策
Device Authorization Flow	テレビ、CLI、入力困難な端末	別端末での認証操作
Implicit Flow	既存システム	新規用途では慎重に検討

OIDC導入時のセキュリティ対策

続いてはOIDC導入時のセキュリティ対策を確認していきます。

リダイレクトURIとstateの検証

リダイレクトURIは、認証完了後に認証サーバーが利用者を戻す先のURLです。

あいまいなワイルドカード指定や、利用していないURLの登録は避け、完全一致で管理することが望まれます。

攻撃者が細工した戻り先を使える状態になると、認可コードや認証結果が第三者へ渡る危険があります。

stateは、認証リクエストとコールバックを結び付けるランダムな値です。

アプリケーション側で発行したstateと、戻ってきたstateを照合することで、CSRF攻撃への対策になります。

stateを生成し、サーバー側または安全なセッション領域で検証することを必須の実装項目として扱いましょう。

nonceとIDトークンの検証

nonceは、IDトークンが現在の認証リクエストに対応することを確認するためのランダムな値です。

認証リクエストにnonceを含め、IDトークン内のnonceクレームと比較します。

これにより、過去に取得したIDトークンを再利用するリプレイ攻撃のリスクを低減できます。

IDトークンの検証では、署名が正しいかだけでは不十分です。

issが期待する認証事業者であること、audが自分のクライアントIDであること、expが失効していないことも確認します。

ライブラリが検証機能を提供していても、設定ミスで検証を無効化していないか確認が必要です。

独自実装よりも、信頼できるSDKや標準仕様に対応したライブラリを活用するほうが、実装漏れを減らしやすいでしょう。

トークンの保管と失効管理

トークンは、パスワードに近い重要情報として扱う必要があります。

アクセストークンやリフレッシュトークンをブラウザーの保存領域へ長期間置く構成では、クロスサイトスクリプティングによる漏えいリスクを十分に検討してください。

サーバー側で安全に保持できる場合は、HttpOnly属性やSecure属性を持つCookie、短い有効期限、セッション管理を組み合わせる方法があります。

リフレッシュトークンは長期利用につながるため、必要な場合だけ発行し、ローテーションや失効処理を設計することが重要です。

ログ、監視ツール、問い合わせ画面にトークンを残さない運用も欠かせません。

事故を想定し、トークン失効、セッション強制終了、利用者への連絡を迅速に行える手順を用意しておくと安心です。

OIDCの活用場面と導入の進め方

続いてはOIDCの活用場面と導入の進め方を確認していきます。

外部IDを利用したログイン機能

一般消費者向けサービスでは、外部IDによるログインを用意すると、アカウント登録時の入力負担を軽減できます。

パスワードを新たに設定したくない利用者にも利用してもらいやすく、初回利用までの導線を短くできる可能性があります。

ただし、外部IDだけに依存すると、認証事業者側の障害や利用者のアカウント喪失が影響します。

メールアドレスによるログイン、パスキー、復旧手段などをどこまで提供するか、サービス特性に応じて決めましょう。

複数のログイン方法で同一人物が重複登録するケースも想定し、アカウント連携の方針をあらかじめ定めておくと運用が安定します。

企業システムにおけるID連携

企業システムでは、OIDCを利用して社内ID基盤とSaaS、独自開発アプリケーションを連携させる場面があります。

人事情報の更新に合わせてアカウントの有効化や停止を制御し、部門や役割に応じた認可を別途適用する構成も一般的です。

OIDCはログイン時の認証連携を担当し、細かな権限管理はアプリケーションや認可サーバーで実装することがあります。

認証基盤の属性情報をそのまま権限へ直結させる場合は、属性の更新頻度、削除時の扱い、誤設定時の影響範囲を確認してください。

監査ログには、いつ、どの認証事業者を通じて、どの利用者がログインしたかを記録すると、調査や内部統制に役立ちます。

導入前に整理したい要件

OIDC導入では、まず利用者、クライアント種別、保護する情報、認証事業者を整理します。

次に、必要なscope、利用するフロー、リダイレクトURI、トークンの保存先、ログアウト時の挙動を決めます。

認証成功だけを確認して終えるのではなく、認証失敗、同意拒否、トークン失効、認証事業者の障害時もテスト対象に含めることが大切です。

確認項目	検討内容
利用者識別	issuerとsubで内部ユーザーを管理するか
フロー選択	クライアント種別にPKCEが必要か
情報取得	必要なscopeと個人情報の利用目的
トークン管理	保存場所、有効期限、更新、失効
障害対応	認証不可時の案内、復旧、監視

仕様は認証事業者ごとに細部が異なるため、公式ドキュメント、Discovery Document、SDKの対応状況を確認しながら実装を進めるとよいでしょう。

OpenID Connect（OIDC）のまとめ

OIDCは、OAuth2.0を基盤に利用者の認証情報を標準的な形で扱うための仕組みです。

OAuth2.0が主に認可を扱うのに対し、OIDCはIDトークンを用いて、誰がログインしたかを確認できるようにします。

Authorization Code FlowとPKCEを適切に選び、state、nonce、リダイレクトURI、IDトークンの検証を確実に行うことが、安全な導入の基本です。

また、アクセストークンとIDトークンの役割を混同せず、必要最小限のscopeと安全なトークン管理を徹底する必要があります。

OIDCはログイン画面を便利にするだけでなく、認証を信頼できる基盤へ集約する技術でもあります。

利用者の利便性、個人情報の保護、運用時の復旧手順まで見据え、自社サービスに合った認証設計へつなげていきましょう。