OAuth 2.0承認カードを使用する
OAuth 2.0は、リソースセット(リモートAPIやユーザーデータなど)へのアクセス権を付与する認証プロトコルです。
OAuth 2.0認証サーバーは追加のセキュリティレイヤーとして機能し、アクセストークンと交換される認証コードをクライアントに返すことができます。
OAuth 2.0の詳細については、「OAuth 2.0とは何か?」を参照してください。
始める前に
OAuth 2.0認証を使用するには、まず接続先のリモートサービスを使ってOAuthアプリを作成する必要があります。
このタスクを開始する
承認コード付与タイプを使ってOAuth 2.0認証を追加する手順は次のとおりです。
-
[概要]タブをクリックします。
-
[認証]ダイアログで[Auth Type(認証タイプ)]ドロップダウンリストから[OAuth 2.0]を選択します。
-
[Grant Type(付与タイプ)]ドロップダウンメニューから[承認コード]を選択します。
-
次のフィールドに値を追加します。
フィールド | 定義 |
---|---|
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のプレビューサイト、本番サイトに接続します。
コネクターの[Key(キー)]は、コネクターの[設定]ペインで確認できます。 プレビュー環境と本番環境の両方に登録する必要があります。 |
Client Ownership(クライアント所有権) |
この設定は、OAuthアプリケーションを管理するユーザーのタイプを決定します。オプションは[開発者]と[カスタマー]です。
|
Client ID(クライアントID) |
サービスから提供される、公開される文字列です。OAuthアプリケーションを識別して承認URLを構築するために使用されます。 |
Client Secret(クライアントシークレット) |
サービスから提供されるプライベート値。アプリケーションのIDをサービスに対して認証するため使用される値。 |
Scopes(スコープ)(任意) |
|
Name(名前) |
各スコープは、サービスからの接続リクエストの詳細なアクセスレベルを定義します。接続にOAuthスコープを追加する方法は次のとおりです。
コネクター認証の任意のコンポーネント(新規スコープのカスタマイズなど)を変更した場合、その更新は開発環境で過去に確立されたアクションカードや接続には適用されません。ただし、Oktaが提供する完成済みのコネクターには、ファーストパーティコネクター、サードパーティコネクターを問わず、この制限はありません。 リフレッシュトークンを取得するために特別なスコープ(refresh_tokenやoffline_accessなど)が必要かどうかについては、APIのドキュメントを参照してください。 |
Scopes Delimiter(スコープ区切り文字) |
ユーザーが個々のスコープを区切って入力するための区切り文字を指定します。 オプションはスペースとカンマです。 |
Parameters(パラメーター)(任意) |
パラメーターを使用することで、インスタンスやサブドメインなど、認証に必要な追加情報をコネクターユーザーから収集できます。これらのフィールドは、ユーザーが接続を最初に作成する際に表示され、必須です。 Label(ラベル):コネクターのセットアップ時に[New Connection(新規接続)]ダイアログに表示されるパラメーターの名前。 Key(キー):サービスで使用されるキー/値ペアのテキスト値。たとえば、api_key、application_key、authentication。 Type(タイプ):3つのフィールドタイプから選択できます。
|
Config Values(構成値)(任意) |
コネクターに対してユーザーを認証する方法を定義するために、その他の設定値が必要になる場合があります。[Add Config Value(構成値を追加)]をクリックします。 Label(ラベル):コネクターのセットアップ時に[New Connection(新規接続)]ダイアログに表示される構成値の名前。 Definition(定義):このフィールドに静的な値が入力されるか、ヘルパーフローからの値が入力されるかを示します。
Type(タイプ):2つのフィールドタイプから選択できます。
[Visible(可視性)]トグルは、コネクターの認証ダイアログに構成値を表示するかどうかを決定します。 |
次の手順
この認証方式を作成したら、認証方式を通じて呼び出しを管理するhttpHelperフローを作成する必要があります。「httpHelperフローの構築」を参照してください。