OIDCとは何か: なぜ必要なのか、どう機能するのか

OpenID Connect (OIDC) の定義#

OpenID Connect (OIDC) は、OAuth 2.0 上に構築されたアイデンティティ認証プロトコルです。OAuth 2.0 が認可のみを提供するのに対し、OIDC は認証機能を追加し、ユーザーの認可と認証のシナリオに対するより標準化されたソリューションを提供します。

簡単に言うと: OIDC = 認可プロトコル + アイデンティティ認証。

なぜOIDCが必要なのか？#

OIDCがなぜ必要かを理解するために、まずOAuth 2.0の核心概念とワークフロー、および実用上の限界を探ることから始めましょう。具体的なシナリオを分析することで、OAuth 2.0以上にOIDCがなぜ必要なのかを確認します。

OAuth 2.0 の主要な概念と認可フロー#

OAuth 2.0 (Open Authorization) は、ユーザーがユーザー名やパスワードなどの資格情報を共有することなく、サードパーティのアプリケーションにリソースへのアクセスを許可する認可プロトコルです。これには4つの主要な役割が含まれます:

• リソース所有者: リソースを所有するユーザー
• リソースサーバー: ユーザーリソースを保存するサーバー
• クライアント: ユーザーリソースにアクセスすることを要求するサードパーティアプリケーション
• 認可サーバー: ユーザーのアイデンティティを確認し、アクセストークンを発行するサーバー

典型的なOAuth 2.0の認可フローは次のように機能します:

示されているように、OAuth 2.0は主にサードパーティクライアントがユーザーリソースにアクセスするためのアクセストークンを発行することに焦点を当てています。

OAuth 2.0 の制限#

OAuth 2.0 プロトコルはアクセストークンの発行にしか焦点を当てていません。リソースサーバーはこれらのトークンを検証し、認可されたリソースを返しますが、ユーザーのアイデンティティを知ることはありません。

これは初期のインターネットエコシステムでは大きな問題ではありませんでした。

しかし、Google、Facebook、Twitter、Github などのプラットフォームが進化し、サードパーティアプリケーションにとって貴重な豊富なユーザーリソースを提供するようになると、OAuth 2.0 はサードパーティのユーザーリソースアクセスを認可するのに優れているものの、限界が生じました。典型的なシナリオとしては、ユーザー情報もリソースであるため、サードパーティアプリケーションが基本的なユーザー情報にアクセスする必要があるとき、異なるプラットフォーム（Google、Facebook、Twitter など）が異なる形式でユーザー情報を返し、開発者にとっての課題となります。

OIDCはこれらの課題に対処するために作成されました。

OIDC の役割#

OAuth 2.0 上でユーザー認証を可能にし、その限界に対処するために、OIDC は3つの役割を導入しました:

• エンドユーザー (EU): 最終ユーザーであり、OAuth 2.0 のリソースオーナーに対応
• リライングパーティ (RP): 依存パーティであり、OAuth 2.0 のクライアントに対応
• OpenID プロバイダー (OP): アイデンティティ認証サービスプロバイダーであり、OAuth 2.0 の認可サーバーとリソースサーバーに対応

OP は核心的な役割を担い、OAuth 2.0 の認可機能を提供し、ユーザー情報を別のリソースとして扱います。

OIDCはどのように機能するか？#

OIDCの認証プロセスはOAuth 2.0 に似ていますが、OP が認可サーバーとリソースサーバーの役割を併せ持っているため、アクセストークンとIDトークンの両方を返します。IDトークンにはユーザーのアイデンティティ情報が含まれており、RP はIDトークンを検証することでユーザーのアイデンティティを確認できます。

典型的なワークフローは次のようになります:

これにより異なるプラットフォーム間でユーザー情報を取得する方法が標準化され、サードパーティアプリケーションがプラットフォーム固有の違いを処理する必要はなくなります。

OIDC のIDトークン (アイデンティティトークン)#

ユーザーがサードパーティアプリケーションを認可すると、OP はOAuth 2.0 アクセストークンとJWT形式のIDトークンの両方を返します。このIDトークンにはユーザーのアイデンティティ情報（ユーザーID、ユーザー名、メール、アバターなど）が含まれています。RP はIDトークンを検証することでユーザーのアイデンティティを確認できます。

JWTとして、IDトークンには標準化されたクレームが含まれており、次の必須の基本クレームが含まれます:

• iss (発行者): IDトークンを発行するOpenIDプロバイダーのユニーク識別子
• sub (主体): ユーザーのユニーク識別子
• aud (受け手): IDトークンを受け取るクライアントアプリケーションの識別子
• exp (有効期限): IDトークンの有効期限
• iat (発行時間): IDトークンが発行された時間

IDトークンの詳細については、こちらをご参照ください: IDトークン。

ユーザー情報エンドポイント#

ユーザー情報エンドポイントは、OPが提供する認証ユーザーの詳細を取得するための標準化されたHTTP APIです。このエンドポイントにはアクセストークンでGETまたはPOSTリクエストを送信することで、JSON形式でユーザー情報を受け取ることができます。

返されるデータには、ユニークユーザーID (sub)、ユーザー名 (name)、メール、写真のような標準化されたフィールドが含まれます。

ユーザー情報を取得するプロセスは、OAuth 2.0での保護されたリソースへのアクセスと同じパターンに従います。通常、ユーザー情報エンドポイントから取得するユーザー情報はIDトークンに含まれるものよりも包括的です。IDトークンは主にアイデンティティ認証と基本的なユーザー情報を提供します。

ユーザー情報エンドポイントの詳細については、こちらをご参照ください: ユーザー情報エンドポイント。

ユーザー情報エンドポイントから受けるユーザー情報は、要求されたスコープと認可時に付与された権限に依存することに注意してください。

OIDC のスコープ#

OIDC のスコープは、RPがアクセスできるユーザー情報を定義します。OIDCは標準スコープを定義しており、openid スコープはOIDCの認証フローで必須です。

一般的な標準スコープには以下が含まれます:

• openid: OIDC 認証リクエストを示す
• profile: 氏名やアバターなどの基本的なユーザー情報
• email: ユーザーのメール情報
• phone: ユーザーの電話番号
• address: ユーザーの住所情報

異なるスコープは異なるユーザー情報を返します。例えば、openid profile email を要求すると、基本的なユーザー情報とメールがIDトークンとユーザー情報に含まれて返され、openid profile email phone address を要求すると、電話番号と住所情報も含まれます。

OIDCに基づくアイデンティティ管理#

OIDCは単なる認証プロトコルではなく、柔軟でスケーラブルなアイデンティティ管理システムを構築するための強力なツールです。OAuth 2.0 に認証レイヤーを追加し、ユーザー情報リソースを標準化し、アイデンティティ管理機能の拡張の基盤を提供することで、OIDCはさまざまなアイデンティティ管理シナリオを可能にします:

• シングルサインオン (SSO): OIDCは拡張されたユーザーセッション情報を通じて自然にSSOをサポートし、統一されたログイン状態の管理とアプリケーション間のアイデンティティ共有を可能にします
• 組織構造管理: 拡張されたユーザー組織情報は、部門階層やユーザーグループ関係を含む複雑な組織構造を管理できます
• 権限管理: 拡張されたユーザー権限属性は、役割情報や権限ポリシーの設定を含む詳細なリソースアクセス制御を可能にします

OIDC の柔軟性は進化するアイデンティティ管理のニーズに適応します。多くのアイデンティティ管理システムはOIDCに基づいて構築されています。たとえば、Logto は、SSO、組織管理、および権限管理機能を提供します。