メインコンテンツへスキップ
ビジネスケースの対象が、API やバックエンドサーバーなどの非インタラクティブな の場合は、machine-to-machine (M2M) 構成でオンボーディングします。

​
ユースケース

次のいずれかに該当する場合は、M2M のオンボーディングパスを使用してください。
  • サービス間通信をサポートしている
  • 保護されたリソースや API へのアクセスが必要な、サーバー上で実行されるスケジュール済みジョブや cron タスクがある
  • IoT デバイスがバックエンドサービスや API と通信できるようにしている
  • ユーザーの関与なしに、またはユーザーのトークンの有効期限が切れた後に、ほかの API レイヤーと通信する必要がある API レイヤーがある
  • ユーザーが認証される前に呼び出す必要がある可能性のある特権 API がある (つまり、Auth0 テナント内の Action やカスタムデータベーススクリプトから)
  • API Gateway を使用してバックエンドサービスを管理している
  • デーモンやバックエンドサービスなど、人による操作を伴わない非対話型アプリケーションやその他のツールを使用またはサポートしている
これらのサービスでも、認証には引き続き M2M アクセストークンが必要です。

​
このガイドの使い方

このガイドは、Auth0 で M2M 実装を構築するための指針です。確認しておくべき考慮事項、ベストプラクティス、概念を紹介します。
  • アーキテクチャでは、ソフトウェア開発ライフサイクルと既存のインフラストラクチャに対応できるように Auth0 を設定することを推奨します。
  • アカウントの作成では、Auth0 で API インスタンスを作成し、マシン間認証に必要な認証フロー (またはグラント) をサポートするアプリケーションを作成する手順を案内します。
  • 認証では、認証に使用するグラントに加えて、設定可能な と権限 (またはスコープ) について説明します。
  • ブランディングでは、証明書の管理方法に応じて、 の設定方法に関する情報の参照先を案内します。
  • デプロイ自動化では、デプロイを支援する当社のツールについて確認できます。
  • 品質保証では、単体テストに加え、 で提供されるReadiness Checksについて詳しく確認できます。

​
アーキテクチャ

Auth0 アカウントやテナント、または Auth0 サービスのグループや構造を設定する前に、既存のインフラストラクチャを整理して把握しておくと、現在のエコシステム内で Auth0 の機能を最大限に活用できます。 一般的なシナリオで説明したように、Auth0 を設定する前に、アプリケーション ドメイン、ネットワーク ドメイン、または M2M デバイス ドメインに存在する、その他の非対話型テクノロジーも考慮する必要がある場合があります。M2M シナリオの例を確認するには、Server + API を参照してください。Node を使って API のデプロイをテストするハンズオン ラボを試すには、GitHub リポジトリ を参照してください。 現在の技術スタックを可視化するとともに、Auth0 を現在のソフトウェア開発ライフサイクル (SDLC) にどのように組み込むかを計画しておくことをお勧めします。これにより、必要なテナント数を判断しやすくなります。

​
考慮事項

新しいアカウントを作成したり、最初のテナントを設定したりする前に、次の点を検討してください。
  • 特定のエンドポイントを呼び出すために、API をどのように分割またはグループ化するか。
    • これにより、アクセストークンのオーディエンスやその他のクレームが決まる可能性があります。
  • リソースを利用するサードパーティのコンシューマーは、呼び出しのたびにアクセストークンを要求する場合があります。呼び出しが過剰になると、レート制限に影響する可能性があります。

​
アカウントを作成する

アーキテクチャの計画ができたら、Auth0 アカウントとテナントを設定します。Auth0 サービスにサインアップすると、最初の テナント を作成します。ここで Auth0 のアセット、サービス、リソースを設定します。開始するには サインアップ してください。

開始前に

Auth0 Dashboard または Auth0 Management API で、次を作成します。
  • 対象の API を表す API
  • Client Credential Flow を使用するための M2M アプリケーション
アカウントを作成する前に、設定の詳細をいくつか計画しておくことをおすすめします。
  • テナント名は Auth0 ドメインの一部になります。名前を決める前に、テナントの特性 を確認してください。
  • ユースケースに必要な Auth0 の機能を確認してください。一部の機能は Professional プランと Enterprise プランでのみ利用できます。
  • 開発、ステージング、本番環境など、複数の環境をサポートする必要があるかを判断してください。詳しくは、複数の環境を設定する を参照してください。
  • テナントに登録したいサードパーティアプリケーションを含むユースケースがある場合は、OIDC Client Registration 仕様に基づく Dynamic Application Registration を使用できます。

​
テナントをプロビジョニングする

アーキテクチャの計画ができたので、次に Auth0 アカウントと を設定します。
Auth0 Dashboard で API を作成すると、その API 用のテストアプリケーションが自動的に生成されます。Management API を使用してプログラムで API を作成する場合は、別の呼び出しでテストアプリケーションを作成する必要があることがあります。

​
API を登録する

このセクションでは、Auth0 で API を作成します。
API は、Auth0 Dashboard または Management API の Update a resource server エンドポイントを呼び出して、いつでも更新できます。
まず、Auth0 Dashboard で API のインスタンスを作成します。
  1. 手順に従って API を登録 します。
Authentication セクションで、M2M 認証用の API 設定を構成します。

​
アプリケーションを関連付ける

アプリケーションが API からアクセストークンをリクエストできるようにするには、アプリケーションと API を関連付ける必要があります。クライアントグラントの詳細は、Authentication セクションで説明します。
設定を行う前に、Auth0 の API に関して確認しておくべき設定項目が複数あります。詳しくは、API Settingsを参照してください。
Auth0 Dashboard で API を作成すると、Auth0 によってテスト用アプリケーションが自動的に生成され、その API に関連付けられます。
  1. Auth0 Dashboard > Applications に移動します。
  2. API の作成時に作成された M2M テスト用アプリケーションを選択します。
    開発用または本番用の別のアプリケーションは、後で Register Machine-to-Machine Applications の手順に従って作成できます。
  3. API ビューに切り替えて、このアプリケーションで有効にする API を探します。
  4. Authorize トグルを有効にし、右側の矢印ボタンを選択してカードを展開します。
  5. Update を選択します。
    Dashboard > Applications > APIs
    このビューでは、ドロップダウンから追加するスコープを選択できます。スコープの詳細は、Authentication セクションのアクセストークンに関する説明で取り上げます。

​
認証

ある API から別の API を呼び出す場合や、認証済みユーザーのコンテキストがない状況では、ユーザーではなくアプリケーションを認可する方法が必要です。これは 1 ステップのプロセスで、アプリケーションを (client_id と client_secret を使用して) 認証し、その後、1 回の呼び出しで認可します。 認証を行う非対話型のアプリケーションまたはサービスでは、クライアントグラント、つまり認証フローを選択する必要があります。 の Client Credentials Flow では人による操作は不要で、M2M アプリケーションに最適です。

始める前に

Auth0 Dashboard または Management API では、次の作業を行います。
  • アプリケーションで Client Credentials Flow を使用するように設定する
  • M2M アクセストークンのスコープを更新する
認証方法を設定する前に、次の内容を確認してください。
  • マシン間認証の Client Credentials Flow を確認します。これは、非対話型の認証と認可に使用するフローです。
  • API のアクセスレベルを決定します。これにより、API の作成時に設定する scopes、つまり権限を判断できます。

​
クライアントクレデンシャルフローを設定する

Auth0 Dashboard または を使用して、クライアントクレデンシャルを提示してアクセストークンを取得するように認証フローを設定できます。 Auth0 Dashboard または Management API を使用するには、Grant Type の更新 の手順に従ってください。

​
M2M アクセストークン

トークンベースの認証では、非対話型クライアントは Authentication API token endpoint を呼び出す際に client_id と client_secret を指定して、アクセストークン を取得します。このアクセストークンにより、保護された API にアクセスできます。 デフォルトのプロファイル (形式) は、2 つあるトークンプロファイルのうち Auth0 トークンプロファイルです。トークンプロファイルは RFC 9068 に変更することもできます。詳しくは、Access Token Profiles を参照してください。トークンが有効かどうかを検証するために、API は Signing Algorithms を確認します。デフォルトの は、鍵ベースのアルゴリズムである RSA256 です。
Auth0 は、認証情報としてクライアントIDとクライアントシークレットを使用する方法以外のクライアント認証方式もサポートしています。これらの方式は、M2M 構成向けの推奨方式である Private Key JWT を含め、Enterprise プランで利用できます。詳しくは、Application Credentials を参照してください。

​
例

/oauth/token エンドポイントへのリクエストは、次のサンプルのようになります。 レスポンスは、次のサンプルのようになります。 
HTTP/1.1 200 OK
Content-Type: application/json
{
  "access_token":"eyJz93a...k4laUWw",
  "token_type":"Bearer",
  "expires_in":86400
}

​
トークンの有効期限

アクセストークンには、有効期間の上限があります。通信はバックチャネルで行われるため、セッションの延長に は使用できません。そのため、アクセストークンの有効期限は1時間に設定することを検討してください。環境によっては、セキュリティとパフォーマンスのバランスを独自に見極める必要があります。詳しくは、Update Access Token Lifetime を参照してください。

​
スコープ

非インタラクティブなクライアントまたはサービスが API を呼び出す前に、API が許可する権限、つまりスコープを定義する必要があります。Authentication API への認証リクエストに含めるスコープは、Auth0 Dashboard で設定できます。API スコープの使用例について詳しくは、API スコープを参照してください。 スコープを設定するには、Auth0 Dashboard を使用する場合は API Permissions の追加 の手順に従うか、Management API 向けに用意されているサンプルを使用してください。
アクセストークンにカスタムクレームを追加するには、Actions の Machine-to-Machine Flow を使用できます。詳しくは、Machine to Machine Flow を参照してください。

​
ブランディング

対話型でないクライアントやバックチャネルで動作するサービスを扱う場合でも、既存のブランドの見た目や雰囲気に合わせてエクスペリエンスをカスタマイズできます。

​
カスタムドメイン

Auth0 は、アクセストークンをリクエストするために /authorize エンドポイントを呼び出す際、カスタムドメインを使用できます。

M2M Onboarding - カスタムドメイン

Auth0 Dashboard では、次の対応が必要です。
  • Auth0 サービスで使用する前に、ドメインを登録して検証します。
  • 独自の証明書を管理するか、Auth0 管理の証明書を使用するかを決定します。証明書の詳細については、証明書管理オプションを参照してください。
  • 自己管理証明書で使用する TLS (SSL) のバージョンと暗号スイートが Auth0 でサポートされていることを確認します。詳細については、TLS (SSL) のバージョンと暗号スイートを参照してください。
  1. Auth0 管理証明書を使用してカスタムドメインを設定するには、Auth0 管理証明書を使用したカスタムドメインの設定の手順に従ってください。
    1. 独自の証明書を管理する場合は、自己管理証明書を使用したカスタムドメインの設定の手順に従ってください。
      カスタムドメインで証明書を管理するには、Enterprise サブスクリプションが必要です。詳細については、Auth0 Pricing と Login を参照してください。
  2. カスタムドメインを使用する API 設定を確認してください。カスタムドメインに対応するため、API 設定の調整が必要になる場合があります。
カスタムドメインで問題が発生した場合は、カスタムドメインのトラブルシューティングを確認してください。

​
デプロイ自動化

Auth0 では、デプロイ自動化の方法として複数のオプションをサポートしており、それぞれを組み合わせて使用することもできます。

ベストプラクティス

デプロイ自動化の構成方法にかかわらず、デプロイ前にカスタムコードと Actions の単体テストを実施し、デプロイ後にはテナントに対していくつかの統合テストも実行することをお勧めします。

​
Deploy CLI Tool

Architecture セクションで推奨されているとおり、開発、テスト、本番用に Auth0 テナントを用意する必要があります。品質チェックとテストを行うため、これらのテナントでは同一の設定を共有している必要があります。ただし、環境間で設定に不一致があると、エラーが発生する可能性があります。たとえば、各環境にはそれぞれ異なる と があります。 こうした設定不一致によるエラーを軽減するには、Deploy CLI Tool を使用して、既存の CI/CD パイプラインに Auth0 インスタンスを統合できます。動的キーワード置換を使用すると、類似した設定を共有するテナント間で環境変数を置き換えることができます。詳しくは、Deploy CLI Tool と Keyword Replacement を参照してください。

​
Actions リアルタイムログ

Actions リアルタイムログでは、console.log の出力やその他の例外を含む、カスタムコードのすべてのログをリアルタイムで表示します。Auth0 Actions やその他のカスタムロジックを使用している場合は、この拡張機能を使ってデバッグやトラブルシューティングを行えます。インストールと設定の詳細については、Actions リアルタイムログ を参照してください。

​
品質保証

品質保証は、本番稼働前に問題を特定するうえで重要です。プロジェクトの特性に応じて、Auth0 との統合の一環として検討すべき品質保証テストには、いくつかの種類があります。
  • 想定外の本番環境の負荷がかかった場合、API はどのように動作しますか？
  • サードパーティアプリケーションは、レート制限にどのような影響を与えますか？
のような Auth0 のウィジェットや機能を使用していない場合、多様なブラウザーやデバイスで利用できる、組み込みのユーザビリティおよびアクセシビリティのベストプラクティスは最初から備わっていません。機能要件が満たされ、想定外の事象が適切に処理されることを確実にするために、アプリケーションと Auth0 の統合をテストするためのガイダンスと、Auth0 Actions などの個別の拡張モジュールを単体テストするためのガイダンスが提供されています。また、Auth0 の侵入テストポリシーを確認し、負荷テストポリシーと併用できるモックテストを実施して、想定外の負荷がかかった場合でもアプリケーションが適切に動作することを確認することをお勧めします。

​
ユニットテスト

ユニットテストでは、Auth0 Actions のような拡張機能の単位を検証します。カスタムコードを使用している場合は、デプロイ前に追加したコードをテストできるよう、Mocha などのテストフレームワークを使用することを推奨します。

​
モックテスト

Auth0 の 負荷テストポリシーと負荷テストを行いたいという要件のバランスを取るために、Auth0 のエンドポイントのモックテストを作成するのが一般的です。これは、テストに制約をかけることなく、想定するインターフェースで設定が正しく機能することを確認するうえで有効な手法です。MockServer、JSON Server、さらには Postman などのツールを活用できます。

​
デプロイ

Deploy and Monitor セクションでは、デプロイのベストプラクティスに関するガイダンスを提供しています。Pre-Deployment Checks、特に組み込みの Auth0 Dashboard Readiness Checks を確認することをお勧めします。 Readiness Check を確認するには、Auth0 Dashboard > Run Readiness Checks で、テナント名と環境タグの下にあるドロップダウンメニューを選択します。
Auth0 Dashboard > Readiness Checklist
フィルターを使用すると、選択したアプリケーションに対して Readiness Checks を適用できます。これらのチェックは、設定済みの API には適用されません。 特定の設定に該当しないチェックについては、Dismiss を選択して最終結果から除外できます。 本番環境への移行前の最終確認として Deployment Best Practices を確認し、サービスの監視には Logs を活用することをお勧めします。

​
詳細情報