- Auth0 Dashboard で Authentication > Social に移動します。
- Create Connection を選択し、リストの一番下までスクロールして Create Custom を選択します。
- Connection Name: 作成する接続の論理識別子です。この名前は変更できず、先頭と末尾は英数字である必要があり、使用できるのは英数字とダッシュのみです。
-
Authorization URL: ユーザーがログインのためにリダイレクトされる URL です。
認可 URL で OAuth2 の
response_modeパラメーターを設定しないでください。この接続でサポートされるのは、デフォルトのresponse_mode(query) のみです。 - Token URL: 受け取った認可コードを 、および必要に応じて と交換するための URL です。
-
Scope: 認可リクエストとともに送信する
scopeパラメーターです。複数の scope はスペースで区切ってください。 -
Separate scopes using a space: IdP’s API の呼び出し時に
connection_scopeパラメーターが含まれている場合に、scope の区切り文字を決定する切り替えです。デフォルトでは、scope はカンマで区切られます。この切り替えを有効にすると、scope はスペースで区切られます。詳しくは、Add Scopes/Permissions to Call Identity Provider APIs を参照してください。 - : 認可をリクエストし、認可コードを交換する際に、アプリケーションとしての Auth0 に使用される Client ID です。Client ID を取得するには、 に登録する必要があります。
- : 認可コードを交換する際に、アプリケーションとしての Auth0 に使用される Client Secret です。Client Secret を取得するには、IDプロバイダーに登録する必要があります。
- Fetch User Profile Script: 提供されたアクセストークンを使用して userinfo URL を呼び出す Node.js スクリプトです。このスクリプトの詳細については、Fetch User Profile Script を参照してください。
- Purpose: ソーシャル接続を Authentication、Connected Accounts for Token Vault、またはその両方で有効にします。詳しくは、User authentication vs Connected Accounts を参照してください。
カスタムのアイデンティティプロバイダーを設定する際は、コールバックURL
https://{yourDomain}/login/callback を使用します。認証フローを更新
接続を作成すると、その接続に割り当てられるデフォルトの OAuth 2.0 グラントタイプは認可コードフローです。Client Secret を保存できないパブリックなアプリケーション (シングルページアプリケーションやネイティブアプリケーションなど) の場合は、 を使用して、接続が 認可コードフロー + PKCE を使用するよう更新できます。 の詳細については、どの OAuth 2.0 フローを使うべきですか? を参照してください。-
/get-connections-by-idエンドポイントにGETリクエストを送信します。レスポンスは次のようになります。 -
optionsオブジェクト全体をコピーします。 -
optionsオブジェクトを含めてPATCHリクエストを送信し、"pkce_enabled":trueを追加します。
ユーザープロファイル取得スクリプト
ユーザーがOAuth2プロバイダーを使ってログインすると、その後にユーザープロファイル取得スクリプトが呼び出されます。Auth0 はこのスクリプトを実行して OAuth2 プロバイダーの API を呼び出し、ユーザープロファイルを取得します。user_id プロパティが必須です。email プロパティは任意ですが、指定することを強く推奨します。返せる属性の詳細については、ユーザープロファイルのルート属性 を参照してください。
プロバイダーから返されるプロファイルの項目は、必要に応じて選別したり、追加したり、削除したりできます。ただし、このスクリプトはできるだけシンプルに保つことをお勧めします。ユーザー情報をより高度に操作するには、ルール を使用できます。ルールを使用する利点の 1 つは、どの接続にも適用されることです。
カスタム接続を使用してログインする
カスタム接続でユーザーをログインさせるには、Auth0 の標準的な方法をどれでも利用できます。直接リンクは次のようになります。アイコンと表示名を変更する
IDプロバイダーのログインボタンにアイコンを追加したり、ログインボタンに表示するテキストを変更したりするには、Management API を使用して、それぞれoptions オブジェクトの icon_url プロパティと display_name プロパティを設定できます。
Auth0 CLI を使用していますか?まだ設定していない場合は、このコマンドを実行する前に CLI セッションを設定して認証してください。
プロバイダー固有のパラメータを渡す
OAuth 2.0プロバイダーの認可エンドポイントには、プロバイダー固有のパラメータを渡せます。これらは静的にも動的にも指定できます。静的パラメータを渡す
静的パラメータ (すべての認可リクエストで送信されるパラメータ) を渡すには、Management API を使用して OAuth 2.0 接続を設定する際に、options の authParams 要素を使用できます。以下の呼び出しでは、すべての認可リクエストに custom_param という静的パラメータを custom.param.value として設定します。
動的なパラメータを渡す
状況によっては、OAuth 2.0 のIDプロバイダーに動的な値を渡したいことがあります。その場合は、options の authParamsMap 要素を使って、Auth0 /authorize エンドポイント で受け付けられる既存の追加パラメータのいずれかと、IDプロバイダーが受け付けるパラメータとのマッピングを指定できます。
前述と同じ例で、custom_param パラメータを認可エンドポイントに渡したいものの、実際の値は Auth0 の /authorize エンドポイントを呼び出すときに指定したいとします。
この場合は、access_type など、/authorize エンドポイントで受け付けられる既存の追加パラメータのいずれかを使い、それを custom_param パラメータにマッピングできます。
/authorize エンドポイントの呼び出し時に、access_type パラメーターでアクセスタイプを指定でき、その値は custom_param パラメーターとして認可エンドポイントに渡されます。
追加のヘッダーを渡す
場合によっては、OAuth 2.0 プロバイダーのに追加のヘッダーを渡す必要があります。追加のヘッダーを設定するには、接続の設定を開き、カスタムヘッダーフィールドに、カスタムヘッダーをキーと値のペアとして含む JSON オブジェクトを指定します。Authorization ヘッダーの送信が必要になる場合を考えてみましょう。この場合は、Custom Headers フィールドに次の JSON オブジェクトを指定できます。
[your credentials] は、IDプロバイダーに実際に送信する資格情報です。