Skip to main content
同じ API の一部として論理的にまとまる複数の異なる API 実装がある場合は、それらを で 1 つの論理 API として表すことで、認可プロセスを簡素化できます。こうすることで、実装する は 1 つだけで済みますが、適切なスコープを割り当てることで、個々の API へのアクセスは引き続き制御できます。 以下のセクションでは、複数の API を Auth0 で 1 つの として使用し、表現する方法を説明します。例では、次のサンプルアプリケーションを使用します。このサンプルアプリケーションはマイクロサービスアーキテクチャを採用しており、以下を含みます。
  • 2 つの Node.js API: contactscalendar (マイクロサービスと考えることができます)
  • 2 つの API を表す 1 つのリソースサーバー
  • 2 つの名前空間付きスコープ: read:contactsread:calendar
  • 両方の API で機能する access_token を取得するためのインプリシットグラントフロー
この 2 つの API は、Organizer Service という 1 つの Auth0 API だけを使って表します。次に 2 つのスコープを作成し、インプリシットフロー を使って SPA から calendar API と contacts API にアクセスする方法を示します。 次の手順を完了する必要があります。
  1. アプリケーションの接続を有効にする
  2. テストユーザーを作成する
  3. Auth0 に論理 API を登録する
  4. 論理 API のスコープを設定する
  5. 論理 API へのアクセスを付与する
  6. (任意) シングルログアウト (SLO) またはシングルサインオン (SSO) を実装する

前提条件

アプリケーションで接続を有効にする

新しく登録したアプリケーションでユーザーを利用できるようにするには、ユーザーの情報源として接続を設定する必要があります。このサンプルでは、ユーザーのメールアドレスとパスワードだけを求めるシンプルなデータベース接続を作成します。詳しくは、データベース接続を設定するをご覧ください。

テストユーザーを作成する

新しく作成した接続を使用しているため、まだ関連付けられたユーザーはいません。サンプルアプリケーションのログインプロセスをテストする前に、ユーザーを作成してその接続に関連付ける必要があります。ユーザーを作成する際は、必ず新しく作成した接続を選択してください。詳しくは、ユーザーを作成するをご覧ください。

Auth0 で論理 API を登録する

サンプルアプリケーションに含まれる複数の API を表すために使用する、1 つの論理 API を登録します。このサンプルでは、API の名前を Organizer Service、一意の識別子を organize に設定します。既定では、この API 用に取得するトークンの RS256 なので、そのままにしておきます。詳しくは、API を登録する を参照してください。

論理 API の権限を設定する

サンプルアプリケーションに含まれる API を論理 API が表現できるようにするには、適切な権限 (スコープ) を作成する必要があります。 スコープを使うと、呼び出し元のアプリケーションが利用できる API の操作を定義できます。各スコープは、1 つの API と 1 つの操作の組み合わせに対応します。このサンプルでは、呼び出し元のアプリケーションが calendar という API と、contacts という別の API から read できるようにしたいため、次の権限を作成する必要があります。
  • read:calendar
  • read:contacts
それぞれを 1 つのマイクロサービスと考えることができます。詳しくは、API の権限を追加するAPI スコープ を参照してください。

論理 API へのアクセスを付与する

これで、論理 API が を取得できるようにすることで、API へのアクセスを提供する準備が整いました。必要なスコープを含めることで、論理 API が表す API に対するアプリケーションのアクセスを制御できます。以下の手順では、サンプルに合わせて Implicit Flow を使用します。ただし、ニーズに最も適したフローを使用できます。たとえば、次のようなものです。 認可フローについて詳しくは、Authentication and Authorization Flows をお読みください。
  1. ユーザーが SPA 内で Login をクリックすると、アプリはユーザーを Auth0 認可サーバー (/authorize エンドポイント) にリダイレクトします。このリクエストのパラメーターについて詳しくは、チュートリアル「Call Your API Using the Authorization Code Flow with PKCE」をご覧ください。
    アプリケーションのサインインページの例
  2. Auth0 認可サーバーはユーザーをログインページにリダイレクトし、そこでユーザーは設定済みのログインオプションのいずれかを使って認証します。
    Lock のログインページ
  3. ユーザーがこのフローを利用するのが初めての場合、SPA に対して Auth0 が付与する権限の一覧を示す同意プロンプトが表示されます。この場合、ユーザーにはアプリが自分の連絡先とカレンダーを読み取ることへの同意が求められます。
    アプリケーションの Lock 同意画面の例
  4. ユーザーが同意すると、Auth0 は URI のハッシュフラグメントにトークンを含めてユーザーを SPA にリダイレクトします。これで SPA は JavaScript を使用してハッシュフラグメントからトークンを抽出し、アクセストークンを使用してユーザーに代わって API を呼び出せるようになります。
    このサンプルでは、ログインに成功すると、論理 API から取得したアクセストークンを使って、いずれかの API を呼び出せるボタンが表示されます。
    ユーザーが認可されたアプリケーション画面の例

シングルログアウト (SLO) またはシングルサインオン (SSO) を実装する

複数のアプリケーションにまたがる一部のシナリオで、シングルログアウトが必要な場合 (あるアプリケーションからログアウトしたユーザーを、他のアプリケーションからもログアウトさせる必要がある場合) は、checkSession() を使って定期的に Auth0 をポーリングし、セッションが存在するかどうかを確認するようアプリケーションを設定できます。セッションが存在しない場合は、そのユーザーをアプリケーションからログアウトさせることができます。同じポーリング方法は、 (SSO) のシナリオでサイレント認証を実装するためにも使用できます。 今後この呼び出しでレート制限の問題が発生するのを避けるため、checkSession() の確認間隔は、呼び出しと呼び出しの間を少なくとも 15 分空けるようにしてください。

詳細はこちら