APIトークンの管理

APIページを使用して、すべてのOkta APIトークンを管理および作成し、オリジンのURLを追加します。

Okta APIの追加情報については、Okta開発者向けサイトを参照してください。

トークン

APIトークンは、ブラウザーでHTTPクッキーがOktaアプリケーションへのリクエストを認証するのと同じように、Okta APIへのリクエストを認証するために使用されます。APIトークンは特定のユーザーに対して発行され、トークンを含むすべてのリクエストはユーザーの代わりに機能します。APIトークンはシークレットであり、パスワードと同様に扱う必要があります。

APIトークンは、トークンを作成したユーザーの権限で生成されます。ユーザーの権限が変更されると、トークンの権限も変更されます。Oktaでは、変更されない権限を持つサービス・アカウントからAPIトークンを生成することをお勧めします。

APIトークンは30日間有効で、APIリクエストで使用されるたびに自動的に更新されます。トークンが30日以上非アクティブである場合、そのトークンは取り消され、再度使用することはできません。トークンは、トークンを作成したユーザーもアクティブな場合にのみ有効です。非アクティブ化されたユーザーが発行したトークンは拒否されます。ユーザー・アカウントが再アクティブ化されると、APIトークンが受け入れられます。ほかのアクションは必要ありません。

Oktaエージェントには、インストール時に、Okta組織へのアクセスに使用するAPIトークンも発行されます。このトークンは標準のAPIトークンと似ていますが、Oktaによって管理されます。

[APIトークン]ページを使用して、すべてのOkta APIトークンを管理します。エージェント・トークンは通常、エージェントをアクティブ化、非アクティブ化、または再アクティブ化するときに管理されます。

エージェント・トークンはこのページに表示されます。ここでレビューしたり、発生する可能性があるセキュリティー上の問題を明確に示したりできます。ほとんどのエージェントはトークンを使用します。トークンの設定は通常、エージェントをアクティブ化または再アクティブ化する際に自動的に処理されます。このトークンのリストには、組織でのOktaトークンの使用情報が含まれています。

トークンの管理に使用できるアクションは5つあります。

[信頼できるオリジン]タブ

信頼できるオリジンは、ページのURIスキーム、ホスト名、ポート番号を組み合わせたセキュリティベースのコンセプトです。Oktaから組織のWebサイトへのクロスオリジンWebリクエストおよびリダイレクトはすべて明示的に許可する必要があります。 [信頼できるオリジン]タブを使用して、Okta APIを通じてOkta組織へのアクセスを制御および信頼しているWebサイトへのアクセス権を付与します。

Note

組織は、組織のOktaまたはカスタム・ドメインURLとは異なる信頼できるオリジンでホストされているサインイン・ページにWebAuthnを使用できます。「WebAuthn(MFA)」を参照してください。

信頼できるオリジンを追加するには:

  1. 管理コンソールで、[セキュリティー] > に移動します[API]
  2. [信頼できるオリジン]タブを選択します。
  3. [オリジンを追加]をクリックします。
  4. [オリジンを追加]ダイアログで、[名前][オリジンのURL]を入力します。
  5. [オリジン・タイプを選択]:
    • CORS – クロス・オリジン・リソース・シェアリング(CORS)は、WebサイトでホストされているJavaScriptがOktaセッションのCookieを使用してOkta APIに対してXMLHttpRequestを行えるようにします。
      Info

      CORSとは? クロス・オリジン・リソース・シェアリング(CORS)は、WebサイトでホストされているJavaScriptがOktaセッションのCookieを使用してOkta APIに対してXMLHttpRequest(XHR)を行えるようにする標準のブラウザー機能です。

    • リダイレクト – サインインまたはサインアウト後に組織の信頼できるWebサイトにブラウザーをリダイレクトできます。
  6. [保存]をクリックします。

レート制限

APIエンドポイントの調整制限は、(本番およびプレビュー・テナントの)Oktaサービスを、(意図しない、またはサービス拒否攻撃として)送信されたリクエストによる負荷の急増またはサービスの中断から保護するために作成されました。この戦略は、顧客に対して一貫したサービス・レベルを維持するために、多くのSaaSアプリケーションおよびプラットフォームで業界全体に採用されています。レート制限に達したリクエストは、429 Too Many Requests HTTPステータス・コードを返します。

公開アプリケーションは、不正使用を防ぐため積極的にレート制限されており、ユーザーに関するメタデータをリリースする前にプライマリー認証が正常に完了している必要があります。詳細については、「Okta認証API」を参照してください。各APIレスポンスの制限を報告するヘッダーの操作を含む、デフォルトのOkta APIレート制限の詳細については、「レート制限」を参照してください。

その他のデフォルトのレート制限をエンドポイント別に次の表に示します。Oktaは、サービスを維持するプロセスにおいて、予告なしに制限を増減する場合があります。

レート制限されるURI

1分あたりのリクエスト数

/app/{アプリ}/{キー}/sso/saml

750

/app/office365/{キー}/sso/wsfed/active

2,000

/app/office365/{キー}/sso/wsfed/passive

250

/app/template_saml_2_0/{キー}/sso/saml

2,500

/login/do-login

200

/login/login.htm

850

/login/sso_iwa_auth

500

/login/agentlessDSSO1000
/api/plugin/{プロトコルのバージョン}/form-cred/{アプリのユーザーID}/{フォーム・サイト・オプション}650
/api/plugin/{プロトコルのバージョン}/sites150
/bc/fileStoreRecord500
/bc/globalFileStoreRecord500

同時レート制限

すべての顧客のサービスを保護するために、Oktaでは同時レート制限を適用しています。この制限は、組織全体の1分あたりのAPIレート制限とは異なります。

同時レート制限の場合、トラフィックは3つの異なる領域で測定されます。すなわち、エージェント・トラフィック、Microsoft Office 365トラフィック、APIリクエストを含むほかのすべてのトラフィックの3つの領域です。1つの領域の測定値は、ほかの2つの領域の測定値には含まれません。

  • エージェントのトラフィックについては、Oktaは各組織のトラフィックを測定し、過去4週間で最も高い使用率より高く制限を設定しました。
  • Microsoft Office 365トラフィックの場合、組織あたりの同時トランザクション数の制限は75です。
  • APIリクエストを含むほかのすべてのトラフィックの場合、組織あたりの同時トランザクション数は75に制限されます。

同時制限を超える最初のリクエストではHTTP 429エラーが返され、60秒ごとの最初のエラーがログに書き込まれます。同時レート制限を1分に1回レポートすることで、ログのボリュームを管理しやすいレベルに抑えることができます。

デフォルトのレート制限

APIエンドポイントの調整制限は、(本番およびプレビュー・テナントの)Oktaサービスを、意図しない、またはサービス拒否攻撃として送信されたリクエストによる負荷の急増またはサービスの中断から保護するために作成されました。この戦略は、顧客に対して一貫したサービス・レベルを維持するために、多くのSaaSアプリケーションおよびプラットフォームで業界全体に採用されています。レート制限に達したリクエストは、429 Too Many Requests HTTPステータス・コードを返します。

公開アプリケーションは、不正使用を防ぐため積極的にレート制限されており、ユーザーに関するメタデータをリリースする前にプライマリー認証が正常に完了している必要があります。

エンド・ユーザーのレート制限

Oktaでは、Oktaユーザー・インターフェイスからのリクエスト数を、エンドポイントあたり10秒ごとに1ユーザー40リクエストに制限しています。このレート制限は、ユーザーを相互に保護し、またシステム内のほかのAPIリクエストからユーザーを保護します。

ユーザーがこの制限を超えることができる場合、レート制限が経過するまでロック・アウトされ、メッセージがユーザー・インターフェイスとシステム・ログに書き込まれます。

例外のリクエスト

エンドポイントの調整はOktaのすべての顧客に対して一律に実施されますが、場合によっては、一時的なレート制限の引き上げを求める顧客のリクエストに対応するというシナリオもあります。一例として、非常に多くのユーザーとグループがOktaにインポートされる初期の展開のシナリオが挙げられます。このようなシナリオでは、顧客は一時的な例外の手配を求めることができます。

リクエストは、引き上げが必要な時間枠の10営業日前に受け取る必要があります。例外をリクエストするには、Oktaサポートでケースを開き、以下の詳細を提供してください。

  1. 組織名
    • URL全体を指定してください
    • 例:https://cloudcompany.okta.com、https://unicorn.oktapreview.com
  2. エンドポイントとレート
    • 制限を引き上げる必要があるURI
    • どのくらいの引き上げが必要か?
  3. 開始日時
  4. 終了日時
  5. 業務上の正当な理由
    • リクエストを推進する組織の要件の詳細を入力してください。

Oktaは、悪用、スパム、サービス拒否攻撃、またはその他のセキュリティー問題を防ぐために、ほかの機能をレート制限する権利を留保します。可能な場合、Oktaは説明的なエラー・コードを提供します。