ビジネスケースがAPIやバックエンドサーバーなどの非インタラクティブなオーディエンスにサービスを提供する場合は、マシンツーマシン（M2M）構成でオンボードします。
次の場合は、M2Mオンボーディングパスを使用します。
- サービスツーサービス通信をサポートする
- 保護されたリソースまたはAPIにアクセスする必要があるサーバー上でスケジュールされたジョブまたはcronタスクが実行されている
- IoTデバイスがバックエンドサービスまたはAPIと通信できるようにする
- ユーザーの関与なし、またはユーザートークンの有効期限が切れた後に他のAPIレイヤーと通信する必要があるAPIレイヤーがある
- ユーザーが認証される前に呼び出す必要がある特権APIがある（つまり、Auth0テナントのアクションまたはカスタムデータベーススクリプトから）
- APIゲートウェイを使用してバックエンドサービスを管理する
- 非対話型アプリケーションや、daemonやバックエンドサービスなど人間との対話を含まないその他のツールを使用またはサポートする
これらのサービスは引き続き認証にM2Mアクセストークンが必要です。
- 「アーキテクチャ」では、ソフトウェア開発ライフサイクルと既存のインフラストラクチャをサポートするようにAuth0を構成することをお勧めします。
- 「アカウントの作成」では、Auth0でAPIインスタンスを作成する手順と、マシンツーマシン認証に必要な認証フロー（または権限許可）をサポートするアプリケーションを作成する手順を示します。
- 「認証」では、認証に使用する必要がある権限許可と、設定できるアクセストークンおよびアクセス許可（またはスコープ）について説明します。
- 「ブランディング」では、証明書の管理方法に応じて、カスタムドメインの構成方法に関する情報をどこで入手できるかをアドバイスします。
- 「デプロイメントの自動化」では、デプロイメントを支援するツールについて読むことができます。
- 「品質保証」では、ユニットテストと、で提供される準備チェックについて詳しく説明します。
Auth0アカウントとテナント、またはAuth0サービスのグループと構造を構成する前に、既存のエコシステムでAuth0の機能を最大限に活用できるように既存のインフラストラクチャのマップを作成します。
一般的なシナリオで説明したように、Auth0を構成する前に、アプリケーションドメイン、ネットワークドメイン、またはM2Mデバイスドメインに他の非対話型テクノロジーを考慮する必要があるかもしれません。M2Mシナリオの例を確認するには、「サーバー + API」を参照してください。Nodeを使ったハンズオン・ラボやAPIのデプロイをテストするには、GitHubリポジトリにアクセスしてください。
現在の技術スタックを視覚化したり、Auth0が現在のソフトウェア開発ライフサイクル（SDLC）にどのように適合するかを計画したりできます。これは、必要なテナントの数を判断するのに役立ちます。
新しいアカウントを作成したり、最初のテナントを構成したりする前に、次の点を考慮する必要があります。
-
特定のエンドポイントを呼び出すためにAPIを分割またはグループ化する方法。
- これにより、アクセストークンのオーディエンスやその他のクレームが決定されます。
-
リソースのサードパーティコンシューマーは、呼び出しごとにアクセストークンを要求する場合があります。呼び出しが多すぎると、レート制限に影響する可能性があります。
アーキテクチャの計画ができたので、Auth0アカウントとテナントを構成します。Auth0サービスにサインアップすると、最初のテナントが作成されます。ここで、Auth0アセット、サービス、およびリソースを構成します。サインアップして開始します。
開始する前に
Auth0 Dashboard内またはAuth0 Management APIを使用して、以下を作成します。
- APIを表すAPI
- クライアントの資格情報フローを使用するM2Mアプリケーション
アカウントを作成する前に、構成情報を計画することをお勧めします。
- テナント名には、Auth0ドメインにおけるロールが含まれます。名前を決める前に、「テナントの特性」をお読みください。
- ユースケースに必要となるAuth0機能を検討します。機能によっては、プロフェッショナルおよびエンタープライズプラン以外では、ご利用いただけません。
- 開発、ステージング、本番など、複数の環境に対応する必要があるか決定します。詳細については、「複数の環境をセットアップする」をお読みください。
- テナント内に登録するサードパーティアプリケーションが関連するユースケースがある場合、OIDCクライアント登録の仕様に基づいて、動的アプリケーション登録を使用することができます。
- 「バックエンドサービスおよびAPIライブラリー」をお読みのうえ、クイックスタートをお試しください。
Auth0 DashboardでAPIを作成すると、APIのテストアプリケーションが自動的に生成されます。Management APIでAPIをプログラムで作成する場合、別の呼び出しでテストアプリケーションを作成する必要があるかもしれません。 Auth0ダッシュボード内、あるいは管理APIリソースサーバーの更新エンドポイントを呼び出すことで、いつでもAPIを更新できます。 Auth0ダッシュボード
Mangement API
まず、Auth0 DashboardでAPI用のインスタンスを作成します。
- 指示に従ってAPIを登録します。
［Authentication（認証）］セクションで、M2M認証用のAPI設定を構成します。 APIをプログラムで登録するには、Management APIを使用します。Management APIを使用するには、アクセストークンが必要です。方法については、「Management APIトークン」をお読みください。Management API Explorerで提供されているサンプルを使用して、Management APIリソースサーバーの作成エンドポイントを呼び出し、本文に次のパラメーターを含めます：| フィールド | 説明 | 例 |
|---|
| Name（名前） | APIのわかりやすい名前です。機能性には影響しません。 | yourDomain |
| Identifier（識別子） | APIの一意の識別子です。URLの使用を推奨します。Auth0では、末尾にスラッシュを含むURLが区別されます。たとえば、https://example.comとhttps://example.com/は異なる識別子として扱われます。このURLは公開されているURLでなくても構いません。Auth0がAPIを呼び出すことはありません。この値は後で変更できません。 | https://{yourDomain} |
| JSON Web Token (JWT) Profile（JSON Web Token（JWT）プロファイル） | このプロファイルが、APIに発行されるアクセストークンの形式を決定します。使用できる値はAuth0とRFC 9068です。詳細については、「アクセストークンのプロファイル」を参照してください。 | access_token |
| JSON Web Token (JWT) Signing Algorithm（JSON Web Token（JWT）署名アルゴリズム） | アクセストークンの署名に使用されるアルゴリズムです。使用できる値はHS256、PS256、RS256です。RS256を選択すると、トークンはテナントの秘密鍵で署名されます。 | HS256 |
Auth0のAPIには、構成前に確認の必要がある設定が複数あります。詳細については、「APIの設定」をお読みください。 Auth0 Dashboard
Mangement API
DashboardでAPIを作成する場合、Auth0は自動的にテストアプリケーションを生成し、APIに関連付けます。
-
［Auth0 Dashboard］ > ［Applications（アプリケーション）］に移動します。
-
API作成時に作成したテストM2Mテストアプリケーションを選択します。
-
［API］ ビューに切り替え、このアプリケーションに対して有効にしたいAPIを見つけます。
-
［Authorize（認可）］ トグルを有効にし、右側にある矢印ボタンを選択してカードを展開します。
-
［Update（更新）］ を選択します。
このビューでは、ドロップダウンを選択して、追加したいスコープを選択できます。スコープについては、［Authentication（認証）］セクションのアクセストークンについて説明するときに詳しく説明します。
APIに関連付けるアプリケーションを作成します。Management API Explorerで提供されているサンプルを使用して、以下を行います：
- Create a Client（クライアントの作成）エンドポイントを呼び出します。
app_typeをnon-interactiveに設定する必要があります。
- Create Client Grant（クライアントの許可の作成）エンドポイントを呼び出し、アプリケーションをAPIに関連付けます。
アプリケーションとテナント設定の詳細については、「テナント設定」をお読みください。 client_idとclient_secretを使用）、1回の呼び出しで認可される1ステッププロセスです。
非対話型アプリケーションまたはサービスの認証では、クライアント権限許可または認証フローを選択する必要があります。Auth 2.0クライアントの資格情報フローは、人間の介入を必要とせず、M2Mアプリケーションに最適です。
開始する前に
Auth0 DashboardやManagement APIで、以下のことを行います。
- クライアントの資格情報フローを使用するようにアプリケーションを設定します。
- M2Mアクセストークンのスコープを更新します。
認証方式を構成する前に以下のことを行います。
- マシンツーマシン認証については、「クライアントの資格情報フロー」を参照してください。これは非対話型の認証と認可のワークフローです。
- APIのアクセスレベルを決定します。これは、APIを作成する際に構成するスコープや権限を決めるのに役立ちます。
client_idとclient_secretを提供し、アクセストークンを取得します。このアクセストークンにより、保護されたAPIへのアクセスが許可されます。
デフォルトのプロファイルまたは形式は、2つのトークンプロファイルに関連付けられたAuth0トークンプロファイルです。トークンプロファイルをRFC 9068に変更することもできます。詳細については、「アクセストークンのプロファイル」をお読みください。トークンが有効であることを確認するために、APIは署名アルゴリズムをチェックします。デフォルトの署名アルゴリズムは、キーベースのアルゴリズムであるRSA256です。
Auth0は、資格情報としてクライアントIDとクライアントシークレットを提供するほか、他のクライアント認証方法もサポートしています。これらのメソッドは、M2Mの構成の秘密鍵JWTの推奨を含め、エンタープライズプランで利用できます。詳細については、「アプリケーションの資格情報」をお読みください。 /oauth/tokenエンドポイントへの要求は、次のサンプルのようになります。
応答は、次のサンプルのようになります。
HTTP/1.1 200 OK
Content-Type: application/json
{
"access_token":"eyJz93a...k4laUWw",
"token_type":"Bearer",
"expires_in":86400
}
アクセストークンにカスタムクレームを追加するには、アクションマシンツーマシンフローを使用できます。詳細については、「マシンツーマシンフロー」をお読みください。
/authorizeエンドポイントを呼び出してアクセストークンを要求するときに、カスタムドメインの使用をサポートします。
M2Mオンボーディング - カスタムドメイン
Auth0ダッシュボードでは、次の操作を行う必要があります。
- Auth0サービスで使用する前に、ドメインを登録して検証します。
- 独自の証明書を管理するか、Auth0管理の証明書を使用するかを決定します。証明書の詳細については、「証明書管理のオプション」をお読みください。
- 自己管理証明書に使用するTLS（SSL）のバージョンと暗号がAuth0でサポートされていることを確認します。詳細ついては、「TLS（SSL）のバージョンと暗号」をお読みください。
-
Auth0管理の証明書を使用してカスタムドメインを構成するには、「Auth0管理証明書を使ってカスタムドメインを構成する」の手順に従ってください。
-
独自の証明書を管理する場合は、「自己管理証明書を使ってカスタムドメインを構成する」の手順に従ってください。
カスタムドメインで証明書を管理するには、エンタープライズサブスクリプションが必要です。詳細については、「Auth0の価格設定」と「ログイン」をお読みください。
-
「カスタムドメインを使用したAPI構成」を確認してください。カスタムドメインを組み込むには、API設定を調整する必要がある場合があります。
カスタムドメインで問題が発生した場合は、「カスタムドメインのトラブルシューティング」を確認してください。
Auth0は、使用可能なデプロイメント自動化アプローチに関していくつかの異なるオプションをサポートしており、それぞれを組み合わせて使用することができます。
ベストプラクティス
デプロイメントの自動化をどのように構成する場合でも、デプロイメント前にカスタムコードとアクションの単体テストを実行し、デプロイメント後にテナントに対して統合テストを実行することをお勧めします。
Real-time Webtask Logs拡張機能
console.log出力やその他の例外など、カスタムコードのすべてのログをリアルタイムで表示します。Auth0 Actionsまたはその他のカスタムロジックを使用している場合は、この拡張機能を使用してデバッグとトラブルシューティングを行うことができます。インストールと構成の詳細については、「Real-time Webtask Logs拡張機能」をご覧ください。
品質保証は、本番稼働前に問題を特定する上で重要です。プロジェクトの性質に応じて、Auth0との統合の一環として検討する必要があるさまざまな種類の品質保証テストがあります。
- 予期しない本番負荷にさらされた場合、APIはどのように機能しますか?
- サードパーティアプリケーションによってレート制限はどのように影響を受けますか?
Auth0のウィジェットやユニバーサルログインのような機能を使用していない場合、多くのブラウザーやデバイスで、ユーザビリティやアクセシビリティのベストプラクティスをすぐに利用することはできません。機能要件が満たされ、予期しないイベントが正しく処理されるように、アプリケーションとAuth0の統合をテストするためのガイダンスと、Auth0 Actionsなどの個々の拡張モジュールのユニットテストが提供されています。また、Auth0の「ペネトレーションテストポリシー」を確認し、「負荷テストポリシー」と組み合わせて活用できるモックテストを完了して、予期しない負荷の下でもアプリケーションを確実に動作させることをお勧めします。
ユニットテストは、Auth0 Actionsなどの拡張性のユニットを検証します。カスタムコードを使用している場合は、デプロイメント前にテストフレームワーク（Mochaなど）を使用して追加コードをテストすることをお勧めします。
Auth0の負荷テストポリシーと負荷テストの必要性のバランスを取るために、Auth0のエンドポイントのモックテストを作成するのが一般的です。これは、テストを制約することなく、構成が想定されたインターフェイスでの動作を確認するための有効な方法です。MockServer、JSON Server、さらにPostmanなどのツールも使用できます。
「デプロイメントとモニタリング」のセクションでは、デプロイメントのベストプラクティスに関するガイダンスを提供しています。「導入前の確認事項」、特に組み込みの「Auth0 Dashboard準備状況チェック」を確認することをお勧めします。
準備チェックを確認するには、［Auth0 Dashboard］>［Run Readiness Checks（準備状況チェックの実行）］を選択し、テナント名と環境タグの下のドロップダウンメニューを選択します。
フィルターを使用して、選択したアプリケーションに準備状況チェックを適用できます。これらのチェックは、構成済みのAPIには適用されません 。
特定の構成に適用されないチェックについては、［Dismiss（閉じる）］ を選択して最終結果から削除できます。
本番稼働前に最終チェックの「デプロイメントのベストプラクティス」を確認し、ログを利用してサービスを監視することをお勧めします。
このビューでは、ドロップダウンを選択して、追加したいスコープを選択できます。スコープについては、［Authentication（認証）］セクションのアクセストークンについて説明するときに詳しく説明します。