OIDCとは何か: なぜ必要なのか、どう機能するのか
OIDCとは何か、なぜ必要なのか、そしてどのように機能するのかを学びましょう。OIDCがOAuth 2.0をどのように拡張して認証を行うのか、IDトークンやスコープ、ユーザー情報エンドポイントなどの主要なコンポーネントを理解しましょう。
OIDCとは何か、なぜ必要なのか、そしてどのように機能するのかを学びましょう。OIDCがOAuth 2.0をどのように拡張して認証を行うのか、IDトークンやスコープ、ユーザー情報エンドポイントなどの主要なコンポーネントを理解しましょう。
OpenID Connect (OIDC) は、OAuth 2.0 上に構築されたアイデンティティ認証プロトコルです。OAuth 2.0 が認可のみを提供するのに対し、OIDC は認証機能を追加し、ユーザーの認可と認証のシナリオに対するより標準化されたソリューションを提供します。
簡単に言うと: OIDC = 認可プロトコル + アイデンティティ認証。
OIDCがなぜ必要かを理解するために、まずOAuth 2.0の核心概念とワークフロー、および実用上の限界を探ることから始めましょう。具体的なシナリオを分析することで、OAuth 2.0以上にOIDCがなぜ必要なのかを確認します。
OAuth 2.0 (Open Authorization) は、ユーザーがユーザー名やパスワードなどの資格情報を共有することなく、サードパーティのアプリケーションにリソースへのアクセスを許可する認可プロトコルです。これには4つの主要な役割が含まれます:
典型的なOAuth 2.0の認可フローは次のように機能します:
示されているように、OAuth 2.0は主にサードパーティクライアントがユーザーリソースにアクセスするためのアクセストークンを発行することに焦点を当てています。
OAuth 2.0 プロトコルはアクセストークンの発行にしか焦点を当てていません。リソースサーバーはこれらのトークンを検証し、認可されたリソースを返しますが、ユーザーのアイデンティティを知ることはありません。
これは初期のインターネットエコシステムでは大きな問題ではありませんでした。
しかし、Google、Facebook、Twitter、Github などのプラットフォームが進化し、サードパーティアプリケーションにとって貴重な豊富なユーザーリソースを提供するようになると、OAuth 2.0 はサードパーティのユーザーリソースアクセスを認可するのに優れているものの、限界が生じました。典型的なシナリオとしては、ユーザー情報もリソースであるため、サードパーティアプリケーションが基本的なユーザー情報にアクセスする必要があるとき、異なるプラットフォーム(Google、Facebook、Twitter など)が異なる形式でユーザー情報を返し、開発者にとっての課題となります。
OIDCはこれらの課題に対処するために作成されました。
OAuth 2.0 上でユーザー認証を可能にし、その限界に対処するために、OIDC は3つの役割を導入しました:
OP は核心的な役割を担い、OAuth 2.0 の認可機能を提供し、ユーザー情報を別のリソースとして扱います。
OIDCの認証プロセスはOAuth 2.0 に似ていますが、OP が認可サーバーとリソースサーバーの役割を併せ持っているため、アクセストークンとIDトークンの両方を返します。IDトークンにはユーザーのアイデンティティ情報が含まれており、RP は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 のスコープは、RPがアクセスできるユーザー情報を定義します。OIDCは標準スコープを定義しており、openid スコープはOIDCの認証フローで必須です。
一般的な標準スコープには以下が含まれます:
openid: OIDC 認証リクエストを示すprofile: 氏名やアバターなどの基本的なユーザー情報email: ユーザーのメール情報phone: ユーザーの電話番号address: ユーザーの住所情報異なるスコープは異なるユーザー情報を返します。例えば、openid profile email を要求すると、基本的なユーザー情報とメールがIDトークンとユーザー情報に含まれて返され、openid profile email phone address を要求すると、電話番号と住所情報も含まれます。
OIDCは単なる認証プロトコルではなく、柔軟でスケーラブルなアイデンティティ管理システムを構築するための強力なツールです。OAuth 2.0 に認証レイヤーを追加し、ユーザー情報リソースを標準化し、アイデンティティ管理機能の拡張の基盤を提供することで、OIDCはさまざまなアイデンティティ管理シナリオを可能にします:
OIDC の柔軟性は進化するアイデンティティ管理のニーズに適応します。多くのアイデンティティ管理システムはOIDCに基づいて構築されています。たとえば、Logto は、SSO、組織管理、および権限管理機能を提供します。