この記事では、curl/Postmanを使用して、ブラウザーなしでOIDCアプリケーションのトークンを取得する方法について説明します。

• OpenID Connect（OIDC）およびOAuth 2.0
• SPA、Web、またはネイティブアプリ（ImplicitまたはAuthorization Codeフローを使用）
• MFAがなく（OrgレベルでMFAを要求されるユーザーにはより多くのAPI呼び出しが必要）、Oktaにパスワードがあるユーザー。外部/フェデレーション/ソーシャルユーザーは、以下の手法を使用できません。
• ユニット/統合/エンドツーエンドテスト

この手法により、ブラウザーを使用せずに、ImplicitまたはAuthorization Codeフローを使用するSPA/Web/ネイティブアプリケーションのユーザースコープのOAuthトークンを取得できます。このためには、使用するOAuthフローに応じて、OktaへのAPI呼び出しを2回または3回行います。最初のステップは、ユーザー名とパスワードを使用してユーザーをログインさせ、sessionTokenを取得することです。その後、認可リクエストを行うことで、sessionTokenをコード/トークンと交換できます。この方法については、「OpenID Connect認可エンドポイントからセッションCookieを取得する」ドキュメントでも説明しています。

これらのリクエストのフォーマットに役立つPostman Collectionsを入手することを強くお勧めします。このガイドでは、認証コレクションとOpenID Connectコレクションの両方が必要になります。

1. プライマリ認証の完了
   1. https://oktaDomain/api/v1/authnにPOSTします。/authnエンドポイントに関する情報は、プライマリ認証のドキュメントに記載されています。
   2. プライマリ認証が成功し、「status」が「SUCCESS」の場合、「sessionToken」が返されます。
      • 注：MFAを要求されたユーザーは、異なるステータスを返します。MFAを求められるユーザーを使用している場合は、以下のAPIドキュメントを参照して、このトランザクションを「SUCCESS」ステータスで完了してください。
   3. Postmanの例：

2. /authorizeのドキュメントに記載されているように、認可リクエストを行います。
   • https://oktaDomain/oauth2/v1/authorizeまたはhttps://oktaDomain/oauth2/{{authorizationServerId}}/authorizeにGETします。これら2つのオプションの違いの詳細については、「 どちらの認可サーバーを使用すべきか」を参照してください。それでもどちらを使用すればよいかわからない場合は、https://oktaDomain/oauth2/v1/authorizeを開始してみてください。
     1. 認可URLは、アプリケーションの構成と要件に応じて作成します。SPAに組み込みOrg Authorization Serverを使用した次の例を参照してください。
     2. 使用するアプリケーションに基づいてリクエストのクエリパラメーターを指定します。response_modeを含め、form_postに設定し、sessionTokenを上記の/authnリクエストから返された値に設定します。
        • PKCE用に構成されたSPAまたはネイティブアプリケーションを使用する場合は、code_verifierとcode_challengeのペアを使用/生成し、認可リクエストでcode_challengeとcode_challenge_methodを、トークンリクエストでcode_verifierを指定することを忘れないでください。ペアが手元にない場合は、これらを使用してテストします。
          • {"code_verifier":"M25iVXpKU3puUjFaYWg3T1NDTDQtcW1ROUY5YXlwalNoc0hhakxifmZHag", "code_challenge":"qjrzSW9gMiUgpUvqgEPE4_-8swvyCtfOVvg55o5S_es"}
     3. 成功すると、提供された「state」値と、トークン（Implicitフローを使用している場合）またはコード（Authorization Codeフローを使用している場合）を含むHTMLページが返されます。
        1. response_type = id_tokenまたはトークンまたはid_token+トークンを使用する場合は、すべて完了です。トークンは、このリクエストの本文で受信する必要があります。そうでない場合は、Okta Admin Consoleで構成された付与タイプとredirect_uriが使用されていることを確認するなど、解決が必要なエラーを受信したかどうかを確認します。
        2. response_type = コードまたはid_token+コードを使用する場合は、さらにいくつかの手順が必要です。このリクエストから返されたコードをコピーし、次のリクエストで使用する準備をします。注：このコードは1回のみ有効で、存続期間が短いことに注意してください。
     4. Postmanの例：

3. （Authorization Codeフローを使用する場合）トークンリクエストを行います。
   • https://oktaDomain/oauth2/v1/tokenまたはhttps://oktaDomain/oauth2/{{authorizationServerId}}/tokenにPOSTします（認可リクエストに使用したものと同じ認可サーバーを使用してください）。
     1. /authorizeリクエストへの応答で受け取ることができる「コード」と、その他すべての必要なパラメーターを指定します。ここで指定するclient_idとredirect_uriは、認可リクエストからのものと一致する必要があります。
        1. クライアントシークレットでアプリケーションを使用する場合、クライアント認証は、PKCE認証を使用したSPAを示す次の例とは異なることに注意してください。「付与タイプごとの承認の実装」ガイドは、このフローを説明するのに役立ちます。
        2. 暗黙的フローが必要な場合は、コードではなく「トークンid_token」として応答タイプを使用します。
        3. response_modeは常にform_postである必要があります。このメソッドは、フラグメントやクエリなどのほかの値と互換性がありません。
        4. redirect_uriは、client_idが指すアプリケーションによってサインインリダイレクトURIとして登録されている限り、任意のサポートURL値にすることができます。
     2. 成功すると、IDトークンとアクセストークンが発行され、Oktaでアプリケーションが要求され有効化されている場合はリフレッシュトークンが発行されます。
     3. Postmanの例：

以上です。これで、作成されたトークンを使用して、リソースサーバーまたはその他の統合をテストできます。

注：上記はテスト/デバッグのみを目的としています。実際のユースケースでは、/authorizeエンドポイントへのリクエストは、ブラウザー（ユーザーエージェント）をエンドポイントにリダイレクトするはずです。AJAXはこのエンドポイントでは使用できません。/authorizeの動作の詳細については、「Org Authorization Server - /authorize」を参照してください。