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(スコープ区切り文字) |
ユーザーが個々のスコープを区切って入力するための区切り文字を指定します。 選択肢はSpaceとCommaです。 |
Parameters(パラメーター)(任意) |
パラメーターを使用することで、インスタンスやサブドメインなど、認証に必要な追加情報をコネクターユーザーから収集できます。これらのフィールドは、ユーザーが接続を最初に作成する際に表示され、必須です。 Label(ラベル):コネクターのセットアップ時に新規接続ダイアログに表示されるパラメーターの名前。 Key(キー):サービスで使用されるキー/値ペアのテキスト値。たとえば、api_key、application_key、authentication。 Type(タイプ):3つのフィールドタイプから選択できます。
|
Config Values(構成値)(任意) |
コネクターに対してユーザーを認証する方法を定義するために、その他の構成値が必要になる場合があります。[Add Config Value(構成値を追加)]をクリックします。 Label(ラベル):コネクターのセットアップ時に新規接続ダイアログに表示される構成値の名前。 Definition(定義):このフィールドに静的な値が入力されるか、ヘルパーフローからの値が入力されるかを示します。
Type(タイプ):2つのフィールドタイプから選択できます。
[Visible(可視性)]トグルは、コネクターの認証ダイアログに構成値を表示するかどうかを決定します。 |
次の手順
この認証方式を作成したら、認証方式を通じて呼び出しを管理するhttpHelperフローを作成する必要があります。「httpHelperフローを構築する」を参照してください。