Skip to main content
Timesheets API へのアクセスを、認可されたユーザーとアプリケーションのみに限定するため、ExampleCo は OAuth 2.0 authorization framework を採用することにしました。このフレームワークでは、さまざまな認可フローを利用して Timesheets API と通信する必要がある各種アプリケーションを容易に認可できるため、同社が求める柔軟性を実現できます。

​
API の認証と認可

API は、アプリケーションの機能をほかのアプリケーションに公開する仕組みです。アプリケーションは、API のエンドポイントにメッセージを送信してリクエストを行い、そのレスポンスとして情報を受け取ることができます。 API エンドポイントは、保護されている場合もあれば、そうでない場合もあります。このケースでは、タイムシートはレビューや支払いに影響する機密情報であるため、認可されたユーザーとアプリケーションだけが API のエンドポイントを呼び出せるようにすることが重要です。クライアントアプリケーションが API の保護されたエンドポイントにアクセスしようとする場合、そのエンドポイントを呼び出すために必要な権限を持っていることの証明として、 を提示する必要があります。 アクセストークンは、ユーザーを で認証することで取得されます。その後、ユーザーはアプリケーションが自分に代わって API にアクセスすることを認可できます。

アクセストークンとは何ですか？

アクセストークン (access_token とも呼ばれます) は、アプリケーションに発行された認可を表す不透明な文字列です。これは、認可情報を取得するために使われる識別子である場合もあれば、認可情報そのもの (たとえば、ユーザーの ID や権限など) を検証可能な形で内包している場合もあります。アクセストークンは、JSON Web Tokens として実装されることがよくあります。Auth0 の アクセストークン について詳しくは、アクセストークン を参照してください。
API では、公開されているさまざまなエンドポイントに対して、誰がアクセスできるかをきめ細かく制御できます。これらの権限はスコープとして表現されます。 ユーザーがクライアントアプリケーションを認可する際、アプリケーションは必要な権限を指定することもできます。ユーザーはそれらの権限を確認し、付与できます。そして、それらの権限は アクセストークン の scope クレームに含まれます。 その後、クライアントが API へのリクエスト時に アクセストークン を渡すと、API は scope クレームを確認し、その特定の API エンドポイントを呼び出すために必要な権限が付与されていることを確かめられます。

スコープ とは何ですか？

各 アクセストークン には、クライアントに付与された権限の一覧を含めることができます。クライアントが Auth0 で認証する際には、要求するスコープ (または権限) の一覧を指定します。それらのスコープが認可されると、アクセストークン には認可されたスコープの一覧が含まれます。たとえば、タイムシート API では 4 つの異なる認可レベルを受け付けることがあります。タイムシートの読み取り (scope read:timesheets) 、タイムシートの作成 (scope create:timesheets) 、タイムシートの削除 (scope delete:timesheets) 、タイムシートの承認 (scope approve:timesheets) です。クライアントが API に新しいタイムシート項目の作成を要求する場合、アクセストークン には create:timesheets scope が含まれている必要があります。同様に、既存のタイムシートを削除するには、アクセストークン に delete:timesheets scope が含まれている必要があります。スコープについて詳しくは、スコープ を参照してください。
認可フレームワークを使用すると、自社のアプリケーションやサードパーティアプリケーションに対して、アプリケーション自身として API への限定的なアクセス権を付与できます。Auth0 を使えば、OAuth 2.0/ Connect (OIDC) の仕様や、API 認可に関するそのほか多くの技術的な詳細を気にすることなく、自社の API でさまざまなフローを簡単にサポートできます。

OAuthの役割

OAuth 2.0のフローには、次の役割があります。
  • Resource Owner: 保護されたリソースへのアクセスを許可できる主体です。通常はエンドユーザーを指します。
  • Resource Server: 保護されたリソースをホストするサーバーです。つまり、アクセス先のAPIです。
  • Client: Resource Ownerに代わって、保護されたリソースへのアクセスを要求するアプリケーションです。
  • Authorization Server: Resource Ownerを認証し、適切な認可を得た後にアクセストークンを発行するサーバーです。この場合は、Auth0のAuthentication APIです。
グラントタイプ (またはフロー) は、これらの参加者がどのように連携して、構築中のAPIに対する限定的なアクセスをアプリケーションに許可するかを定めます。その結果、アプリはユーザーに代わってAPIを呼び出すために使用できるアクセストークンを取得します。

​
Proof Key for Code Exchange (PKCE)

OAuth 2 では、さまざまなユースケースに対応するために複数のグラントタイプが用意されています。このユースケースでは、モバイルアプリケーションから API にアクセスするため、Proof Key for Code Exchange (PKCE) を使用する Authorization Code Flow を利用します。 Authorization Code Flow は、ネイティブアプリケーションに実装する場合、いくつかのセキュリティ上の問題があります。たとえば、悪意のある攻撃者が Auth0 から返された authorization_code を傍受し、それを アクセストークン  (場合によっては リフレッシュトークン) に交換してしまう可能性があります。 Proof Key for Code Exchange (PKCE) (RFC 7636 で定義) は、この認可コード傍受攻撃を軽減するための技術です。 PKCE では、Application は認可リクエストごとに、code_verifier と呼ばれる暗号学的にランダムな鍵と、その変換値である code_challenge を生成し、authorization_code を取得するために Auth0 に送信します。Application が authorization_code を受け取ると、要求したトークンと交換するため、そのコードと code_verifier を Auth0 の に送信します。
Diagram - Microsite - Auth Code with PKCE
  1. ネイティブアプリがフローを開始し、ユーザーを Auth0 にリダイレクトします (具体的には /authorize endpoint) 。このとき、code_challenge と code_challenge_method パラメータを送信します。
  2. Auth0 は、クエリ文字列に authorization_code を付与して、ユーザーをネイティブアプリにリダイレクトします。
  3. ネイティブアプリは、authorization_code と code_verifier を、redirect_uri および client_id とともに Auth0 に送信します。これは /oauth/token endpoint を使用して行われます。
  4. Auth0 はこの情報を検証し、アクセストークン (必要に応じてリフレッシュトークンも) を返します。
  5. ネイティブアプリは、アクセストークンを使用して、ユーザーに代わって API を呼び出すことができます。
Refresh Token Rotation が有効になっている場合は、リクエストごとに新しいリフレッシュトークンが生成され、アクセストークンとともに発行されます。リフレッシュトークンが交換されると、以前のリフレッシュトークンは無効になりますが、その関連情報は認可サーバーに保持されます。

​
Authorization Extension

Auth0 Authorization Extensionを使用すると、ユーザーにロール、グループ、権限を割り当てることで、アプリケーションに認可機能を追加できます。 Authorization Extension は、認証フロー中に、ユーザーに割り当てられたロール、グループ、権限をユーザープロファイルに追加する Rule を作成します。これにより、ユーザーに発行されるアクセストークンに、Authorization Extension で定義された権限に基づいて許可されたスコープだけが含まれるようにできます。 前のチュートリアル Introduction 次のチュートリアル 2. Auth0 Configuration