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(スコープ区切り文字)

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

選択肢はSpaceCommaです。

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

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

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

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

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

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

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

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

Config Values(構成値)(任意)

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

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

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

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

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

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

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

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

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

次の手順

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