OIDC準拠のパイプラインの採用
テナントの世代に応じて、OIDC準拠パイプラインを採用するためのさまざまなオプションがある場合があります。新しいテナント
Auth0ダッシュボードを使用して新しいテナントを作成する場合、デフォルトでOIDC準拠のパイプラインが使用されます。これは、2019年初頭からダッシュボードのデフォルト設定となっています。OIDC Conformant（OIDC準拠）設定を手動で無効にすることはできますが、以前のテナントに関する指示に従ってください。
古いテナント
本ガイドで説明されているすべての変更を特定のアプリケーションに対して同時に強制し、実行時ではなく構成中にすべての重大な変更を検出できるようにするには、次の操作を行う必要があります。- ［Dashboard］>［Applications（アプリケーション）］>［Applications（アプリケーション）］に進み、希望するアプリケーションを選択します。
- ［Advanced Settings（詳細設定）］ にスクロールし、 OAuth タブに進みます。
- ［OIDC Conformant（OIDC準拠）］ トグルスイッチを有効にし、 ［Save Changes（変更を保存）］ をクリックします。
audienceパラメーターを使用して/socialエンドポイントへの要求を開始します。
認証要求ごとにOIDC準拠のパイプラインを使用する必要があり、アプリケーションがAPIを呼び出す必要がない場合は、次のaudienceパラメーターを使用します。
違い
OIDC準拠パイプラインを有効にすると、従来のパイプラインに次の変更が加えられます。API
アプリケーションとAPI（リソース）は、個別のAuth0エンティティとして定義してください。詳細は「OIDC準拠の採用：API」をお読みください。アクセストークン
- APIは、IDトークンではなくアクセストークンを使用して保護してください。これらの違いに関する詳細は、「トークン」をお読みください。
- ユーザーに関する標準的なクレームの定義済みセットは、IDトークンまたは
/userinfoからの応答で返されます。 - カスタムクレームは、名前付き形式に準拠する必要があります。詳細については、「名前空間カスタムクレームを作成する」をお読みください。
/userinfoからの応答はIDトークンの内容と同様にOIDC仕様に準拠します。- スコープは、標準クレームまたはカスタムAPIアクセス許可のいずれかを要求するために使用できます。
認可フロー
- 認可コードフロー：認証要求、認証応答、コード交換要求、コード交換応答、IDトークン構造、アクセストークン構造には構造上の違いがあります。
- クライアントの資格情報フロー：新しいフローが有効になり、アプリケーションがユーザーの代わりにではなく自分自身として認証し、プログラムによってセキュアにAPIへのアクセスを取得できるようになりました。
-
暗黙フロー：認証要求、認証応答、IDトークン構造、アクセストークン構造には構造上の違いがあります。具体的には次のような違いがあります。
response_type=tokenはアクセストークンのみを返します。IDトークンを取得するには、response_type=id_tokenまたはresponse_type=token id_tokenを使用します。- IDトークンはRS256を使用して非対称的に署名されます。
- nonceパラメーターなしで行われた認証要求は拒否されます。詳細は「暗黙フローの使用時にリプレイ攻撃を軽減する」をお読みください。
- 認証に暗黙フローを使用すると、リフレッシュトークンは返されなくなります。
-
リソース所有者のパスワードフロー：認証要求、認証応答、IDトークン構造、アクセストークン構造には構造上の違いがあります。具体的には次のような違いがあります。
- 従来のリソース所有者エンドポイントが無効になり、そのエンドポイントからの埋め込みログインのパスワードレス認証も無効になります。埋め込みログインでパスワードレスを実装するには、アプリケーションの種類に応じて、埋め込みパスワードレスAPIまたはSDKを使用してください。
offline_accessスコープを使用してリフレッシュトークンを要求する場合、deviceパラメーターは無効と見なされるようになりました。
委任
- 廃止 ：
/delegationエンドポイント、サードパーティのAPIトークンを取得するために使用される場合を除く。 - OIDC準拠のアプリケーションは、委任要求のソースまたはターゲットになることはできません。
エンドポイント
- 廃止 ：
/tokeninfoエンドポイント - 無効 ：
/oauth/access_tokenエンドポイント（ネイティブモバイルアプリケーションからのソーシャル認証に使用）。 - 廃止 ：
/ssodataエンドポイント - 廃止 ：
/delegationエンドポイント、サードパーティーAPIトークンを取得するために使用される場合を除く。
リフレッシュトークン
- 認証に暗黙フローを使用すると、リフレッシュトークンは返されなくなります。
- リフレッシュトークンは機密アプリケーションに使用できますが、リフレッシュトークンのローテーションによりほとんどのフローのセキュリティを強化できるため、PKCEを使用した認証コードフローを使用する場合は、常にパブリックアプリケーションに使用してください。機密アプリケーションの詳細については、「機密アプリケーションと公開アプリケーション」をお読みください。リフレッシュトークンのローテーションの詳細については、「リフレッシュトークンのローテーション」をお読みください。
- 新しいトークンを取得するときは、
/oauth/tokenエンドポイントを使用してください。 - 認証要求で
offline_accessスコープを使用してリフレッシュトークンを要求する場合、deviceパラメーターは不要になりました。
シングルサインオン（SSO）
- はAuth0ログインページからのみ実行できるため、ユニバーサルログインを使用してください。
- ユーザーがSSO経由でログインしているかどうかを確認するには、サイレント認証を使用してください。詳細は、「サイレント認証を構成する」をお読みください。
- 廃止 ：
/ssodataエンドポイントおよびLock/auth0.jsのgetSSOData()メソッド。
追加機能
- API用のサードパーティーアプリケーションを作成し、認可のための同意ダイアログを表示します。詳細は「ユーザーの同意およびサードパーティーアプリケーション」をお読みください。
- 認証時にアプリケーションに提供されるユーザープロファイル情報を制限します。詳細は「ユーザープロファイル」をお読みください。
- 動的にアプリケーションを登録します。詳細については、「動的クライアント登録」をお読みください。
- 組織とその関連機能が利用可能になります。