OAuth 2.0承認カードを使用する

OAuth 2.0は、リソースセット(リモートAPIやユーザーデータなど)へのアクセス権を付与する認証プロトコルです。

OAuth 2.0認証サーバーは追加のセキュリティレイヤーとして機能し、アクセストークンと交換される認証コードをクライアントに返すことができます。

OAuth 2.0の詳細については、「OAuth 2.0とは何か?」を参照してください。

始める前に

OAuth 2.0認証を使用するには、まず接続先のリモートサービスを使ってOAuthアプリを作成する必要があります。

このタスクを開始する

承認コード付与タイプを使ってOAuth 2.0認証を追加する手順は次のとおりです。

  1. [概要]タブをクリックします。

  2. [認証]ダイアログで[Auth Type(認証タイプ)]ドロップダウンリストから[OAuth 2.0]を選択します。

  3. [Grant Type(付与タイプ)]ドロップダウンメニューから[承認コード]を選択します。

  4. 次のフィールドに値を追加します。

フィールド 定義

Paths(パス)

Base URL(ベースURL)

OAuthサーバーのベースURL。コネクターは、[Base URL(ベースURL)]の値にアクセストークンのパスを追加します。

ただし、[Authorize Path(承認パス)][Token Path(トークンパス)][Refresh Token Path(リフレッシュトークンパス)]エントリに完全修飾URLが指定されていれば、このフィールドは空白のまま残すことができます。これらのアクセストークンの処理に異なるURLが使用される場合はこちらのシナリオの方が適しています。

Authorize Path(承認パス)

コネクターがサービスのアクセストークンを取得できる場所(例:/authorize)。

[Base URL(ベースURL)]が空の場合、このフィールドは完全修飾URLである必要があります(例:https://account.example.com/api/oauth2/authorize)。

Token Path(トークンパス)

フローがアクセスおよびリフレッシュトークンの承認コードを交換する場所(例:/oauth2/token)。

[Base URL(ベースURL)]が空の場合、このフィールドは完全修飾URLである必要があります(例:https://api.example.com/oauth2/token)。

Refresh Token Path(リフレッシュトークンパス)(任意)

コネクターがアクセストークンの期限切れ後に新しいアクセストークンを取得できる場所。

リフレッシュトークンパスは、多くの場合はアクセストークンパスと同じです。サービスがアクセストークンの更新に個別のエンドポイントを使用する場合は、ここに入力します(例:https://account.example.com/api/oauth2/reauthorize)。

Credentials(資格情報)

Redirect URI(リダイレクトURI)

新しいアプリの登録時は、通常はアプリ名やWebサイトなどの基本情報を登録します。さらに、認証をOkta Workflowsに戻すためのリダイレクトURLも登録する必要があります。

提供されたコネクターの[Redirect URI(リダイレクトURI)]を新しいOAuthアプリにコピーしてコネクターをサービスに登録します。

次のリダイレクトURLを使用して、それぞれOktaのプレビューサイト、本番サイトに接続します。

  • https://oauth.workflows.oktapreview.com/oauth/{{auth.connector_key}}/cb

  • https://oauth.workflows.okta.com/oauth/{{auth.connector_key}}/cb

コネクターの[Key(キー)]は、コネクターの[設定]ペインで確認できます。

プレビュー環境と本番環境の両方に登録する必要があります。

Client Ownership(クライアント所有権)

この設定は、OAuthアプリケーションを管理するユーザーのタイプを決定します。オプションは[開発者][カスタマー]です。

  • 開発者:コネクタービルダーがアプリケーションを作成し、その設定を管理します。ビルダーは、[Client ID(クライアントID)]フィールドと[Client Secret(クライアントシークレット)]フィールドの値も提供します。

  • カスタマー:アプリケーションのエンドユーザーがクライアントOAuthアプリケーションを管理します。このユーザーは、[Client ID(クライアントID)]フィールドと[Client Secret(クライアントシークレット)]フィールドの値も提供します。このオプションを選択すると、[新規接続]ダイアログに[Client ID(クライアントID)]フィールドと[Client Secret(クライアントシークレット)]フィールドが自動的に追加されます。

Client ID(クライアントID)

サービスから提供される、公開される文字列です。OAuthアプリケーションを識別して承認URLを構築するために使用されます。

Client Secret(クライアントシークレット)

サービスから提供されるプライベート値。アプリケーションのIDをサービスに対して認証するため使用される値。

Scopes(スコープ)(任意)

Name(名前)

各スコープは、サービスからの接続リクエストの詳細なアクセスレベルを定義します。接続にOAuthスコープを追加する方法は次のとおりです。

  1. [Add Scope(スコープを追加)]をクリックして、この接続用に要求する一意のスコープをサービスに追加します。

  2. スコープ名を入力します(例:openidoffline_access)。

    トグルを使ってスコープが[Required(必須)]であるかどうかを指定します。スコープを[Required(必須)]としてマークするには、事前に[Allow users to customize scopes(スコープのカスタマイズをユーザーに許可)]オプションを有効化しておく必要があります。

    必須としてマークされたスコープは常に要求されます。通常は、コネクターが正しく機能するために必要なスコープです。また、APIのすべてのエンドポイントを呼び出すCAPIAカードでは、通常は接続によってすべてのスコープが有効化されている必要があります。

    追加する各スコープは、[新規接続]プレビューの[権限]タブに表示されます。

  3. ユーザーがスコープリストを変更できるようにするには、[Allow users to customize scopes(スコープのカスタマイズをユーザーに許可)]オプションを選択します。

    この機能は、異なるスコープを使ってサービスを呼び出す複数の接続をユーザーが作成できるようにする場合に有用です。たとえば、これらのユーザーは最小権限の原則に合わせてスコープを削除できます。

    たとえば、メールサービスへの1つの接続には、管理を合理化するためにread-emailスコープが含まれる場合があります。同一サービスへのより高度な別の接続には、delete-emailスコープやsend-emailスコープも含まれるかもしれません。

    このオプションは、サービスから要求されるスコープを定義するための2つの選択肢を提供するセレクターを[権限]タブに追加します。

    • [Use default scopes(デフォルトスコープを使用)]:定義済みのすべてのスコープを要求します。

    • [Customize scopes(スコープをカスタマイズ)]:ユーザーは、元のリストから必須以外のスコープを削除できます。必須スコープは消去できません。

  4. ユーザーがコネクターを通じて追加のスコープリクエストを追加できるようにするには、[Allow users to request additional scopes(追加スコープの要求をユーザーに許可)]オプションを選択します。

    スコープは[Manually add scopes(スコープを手動で追加)]フィールドに入力できます。この入力フィールドの文字数制限は500です。スコープは個別に追加することも、スペースまたはカンマ区切りのスコープリストとして追加することもできます。区切り文字は、[Scopes Delimiter(スコープ区切り文字)]フィールドの選択と一致します。

    このオプションを選択しない場合、ユーザーはOkta Ideasサイトを通じてコネクターへの新規スコープの追加を求めることができます。このリンクは、[権限]タブの下部にあります。

    このオプションは、[Allow users to customize scopes(スコープのカスタマイズをユーザーに許可)]オプションを有効にした場合にのみ利用できます。

コネクター認証の任意のコンポーネント(新規スコープのカスタマイズなど)を変更した場合、その更新は開発環境で過去に確立されたアクションカードや接続には適用されません。ただし、Oktaが提供する完成済みのコネクターには、ファーストパーティコネクター、サードパーティコネクターを問わず、この制限はありません。

リフレッシュトークンを取得するために特別なスコープ(refresh_tokenoffline_accessなど)が必要かどうかについては、APIのドキュメントを参照してください。

Scopes Delimiter(スコープ区切り文字)

ユーザーが個々のスコープを区切って入力するための区切り文字を指定します。

オプションはスペースカンマです。

Parameters(パラメーター)(任意)

パラメーターを使用することで、インスタンスやサブドメインなど、認証に必要な追加情報をコネクターユーザーから収集できます。これらのフィールドは、ユーザーが接続を最初に作成する際に表示され、必須です。

Label(ラベル):コネクターのセットアップ時に[New Connection(新規接続)]ダイアログに表示されるパラメーターの名前。

Key(キー):サービスで使用されるキー/値ペアのテキスト値。たとえば、api_keyapplication_keyauthentication

Type(タイプ):3つのフィールドタイプから選択できます。

  • テキスト:ユーザーにプレーンテキストフィールドを表示します。これは、加工なしのオープンテキストフィールドです。

  • パスワード:加工されたテキストフィールドを表示します。このフィールドに入力したテキストはユーザーには表示されません。

  • ドロップダウンリスト:ユーザーが選択する値の、手動で作成されたドロップダウンリストを表示します。

Config Values(構成値)(任意)

コネクターに対してユーザーを認証する方法を定義するために、その他の設定値が必要になる場合があります。[Add Config Value(構成値を追加)]をクリックします。

Label(ラベル):コネクターのセットアップ時に[New Connection(新規接続)]ダイアログに表示される構成値の名前。

Definition(定義):このフィールドに静的な値が入力されるか、ヘルパーフローからの値が入力されるかを示します。

  • Static Value(静的な値)であれば、[Value(値)]フィールドに値を入力します。

  • Value from Helper Flow(ヘルパーフローからの値)であれば、[Choose Flow(フローの選択)]ダイアログでフローを選択します。

Type(タイプ):2つのフィールドタイプから選択できます。

  • テキスト:ユーザーにプレーンテキストフィールドを表示します。これは、加工なしのオープンテキストフィールドです。

  • パスワード:加工されたテキストフィールドを表示します。このフィールドに入力したテキストはユーザーには表示されません。

[Visible(可視性)]トグルは、コネクターの認証ダイアログに構成値を表示するかどうかを決定します。

次の手順

この認証方式を作成したら、認証方式を通じて呼び出しを管理するhttpHelperフローを作成する必要があります。「httpHelperフローの構築」を参照してください。