OpenID Connect（OIDC）の概要
お知らせ：当社は、お客様により充実したサポート情報を迅速に提供するため、本ページのコンテンツは機械翻訳を用いて日本語に翻訳しています。正確かつ最新のサポート情報をご覧いただくには、本内容の英語版を参照してください。
OpenID Connect（OIDC）は、OAuth 2.0認可プロトコルの上に構築されたIDレイヤーです。サードパーティー製アプリ（クライアント）がユーザーのIDを認証し、基本的なプロフィール情報にアクセスするために役立ちます。
OIDCの仕組みを理解する前に、いくつかの用語を確認しましょう。
OpenIDプロバイダー（OP）
クレーム
IDトークン
アクセストークン
リフレッシュトークン
認可エンドポイント
ユーザーを認証し、その情報を要求するクライアントにユーザー情報を提供するOAuth 2.0認可コンポーネントです。
OpenIDプロバイダーにユーザー認証とユーザー情報を要求するクライアントアプリケーションです。
クライアントの前提条件。
クライアント（リライングパーティー）は、リソースプロバイダー（OpenIDプロバイダー）に登録し、OpenIDプロバイダーからクライアントIDとクライアントシークレットを取得する必要があります。
OIDCの基本フロー。
リライングパーティーは、OpenIDプロバイダーの認可エンドポイントに、ユーザーの認証と、特定のユーザー情報にアクセスするための認可を要求します。ユーザーを認証して認可を取得すると、認可エンドポイントはIDトークンとアクセストークンをリライングパーティーに送信します。
このトークン交換で使用される方法は、リライングパーティー（RP）の種類と、選択した認証フローによって異なります。RPの種類と、それぞれにおすすめの認証フローについては、この記事の後半で説明します。
RPは、アクセストークンを使用して、OPのUserInfoエンドポイントにユーザー情報（クレーム）を要求します。OPは、同意済みのクレームをRPに送信します。
リライングパーティーの種類とおすすめの認証フロー。
通常のWebアプリ（MPA）と認可コードフロー。
これらのアプリケーションはサーバー上で実行され、操作のたびに新しいページのリクエストをサーバーに送信します。クライアントシークレットを安全に保存できるため、「機密クライアント」とも呼ばれます。MPAにおすすめの最適な認証フローは、認可コードフローです。
このフローでは、RP（クライアント）はOPの認可エンドポイントに、ユーザーの認証と、特定のユーザー情報にアクセスするための認可を要求します。ユーザーを認証して認可を取得すると、認可エンドポイントは認可コードをクライアントに送信します。クライアントは次に、この認可コードをOPのトークンエンドポイントでIDトークン、アクセストークン、および要求した場合はリフレッシュトークンと交換します。クライアントは、IDトークンから必要なユーザー情報（クレーム）を取得します。
シングルページアプリケーション（SPA）とインプリシットフロー
SPAは、ユーザーの操作に応じて必要なセクションを読み込む最新のWebアプリケーションです。通常、最初に必要なリソースをすべてサーバーから取得した後、クライアント側で実行されます。「公開クライアント」とも呼ばれます。ソース全体がブラウザー内にあるため、クライアントシークレットを安全に保存できません。SPAに推奨される認証フローは、インプリシットコードフローです。
このフローでは、クライアント（RP）はOPの認可エンドポイントに、ユーザーの認証と、特定のユーザー情報にアクセスするための認可を要求します。ユーザーを認証して認可を取得すると、認可エンドポイントはIDトークンをクライアントに直接送信します。要求した場合は、アクセストークンとリフレッシュトークンも送信します。クライアントは、IDトークンから必要なユーザー情報を取得します。このフローでは、トークンエンドポイントは使用されません。
ネイティブアプリケーションとPKCEフロー
ネイティブアプリケーションは、特定のデバイスに直接インストールされます。「公開クライアント」とも呼ばれます。デバイスに直接インストールされ、誰でもアプリケーションを逆コンパイルしてクライアントシークレットにアクセスできるため、シークレットを安全に保存できません。ネイティブアプリにおすすめのフローは、Proof Key for Code Exchange（PKCE）を使用する認可コードフローです。
このフローでは、クライアント（RP）はコードベリファイアー（ランダムな文字列）とコードチャレンジ（任意のハッシュ方式を使用してコードベリファイアーをハッシュ化したバージョン）を生成します。クライアントは、OPの認可エンドポイントに送信する認可要求とともに、コードベリファイアーも送信します。ユーザーを認証して認可を取得すると、認可エンドポイントは認可コードをクライアントに送信します。クライアントは、OPのトークンエンドポイントで、この認可コードとともにコードチャレンジと、コードベリファイアーのハッシュ化に使用した方式を提示します。トークンエンドポイントは処理として、指定されたハッシュ方式でコードチャレンジのハッシュを解除し、その結果とコードベリファイアーが一致するかどうかを確認します。これにより、認可要求を送信したクライアントと同じクライアントから認可コードを受信したことを検証します。その後、トークンエンドポイントはIDトークン、アクセストークン、および要求した場合はリフレッシュトークンを提供します。クライアントは、IDトークンから必要なユーザー情報を取得します。