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

​
前提条件

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

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

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

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

​
Auth0 に論理 API を登録する

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

​
論理 API の権限を設定する

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

​
論理 API へのアクセスを許可する

これで、論理 API が を取得できるようにすることで、API へのアクセスを提供する準備が整いました。必要なスコープを含めることで、論理 API が表す API に対してアプリケーションに許可するアクセスを制御できます。以下の手順では、サンプルに合わせて Implicit Flow を使用しています。ただし、要件に最も適したフローを使用できます。たとえば次のとおりです。
  • マシン間アプリケーションがある場合は、Client Credentials フロー を実行することで、そのアプリケーションが API のアクセストークンをリクエストできるように認可できます。
  • ネイティブアプリを構築している場合は、PKCE を使用する認可コードフロー を実装できます。
認可フローについて詳しくは、Authentication and Authorization Flows を参照してください。
  1. ユーザーが SPA 内で Login をクリックすると、アプリケーションはユーザーを Auth0 認可サーバー (/authorize エンドポイント) にリダイレクトします。この呼び出しのパラメーターについて詳しくは、チュートリアル「Call Your API Using the Authorization Code Flow with PKCE」を参照してください。
    アプリケーションのサインインページの例
  2. Auth0 認可サーバーはユーザーをログインページにリダイレクトし、ユーザーはそこで設定済みのログインオプションのいずれかを使用して認証します。
    Lock ログインページ
  3. ユーザーがこのフローを利用するのが初めての場合、Auth0 が SPA に付与する権限の一覧を表示する同意プロンプトが表示されます。この場合、ユーザーはアプリケーションが自分の連絡先とカレンダーを読み取ることに同意するよう求められます。
    アプリケーションの Lock Consent 画面の例
  4. ユーザーが同意すると、Auth0 は URI のハッシュフラグメントにトークンを含めてユーザーを SPA にリダイレクトします。これで SPA は JavaScript を使用してハッシュフラグメントからトークンを抽出し、アクセストークンを使用してユーザーに代わって API を呼び出せます。 
    function getParameterByName(name) {
  var match = RegExp('[#&]' + name + '=([^&]*)').exec(window.location.hash);
  return match && decodeURIComponent(match[1].replace(/\+/g, ' '));
}

function getAccessToken() {
  return getParameterByName('access_token');
}
    このサンプルでは、ログインに成功すると、論理 API から取得したアクセストークンを使用して、いずれかの API を呼び出せるボタンが表示されます。
    ユーザー認可済み画面の例

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

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

​
詳細はこちら