ソリューション概要（モバイルアプリ + API）

モバイル + API アーキテクチャシナリオ向けのソリューション概要

Timesheets API へのアクセスを、許可されたユーザーとアプリケーションのみに制限するため、ExampleCo は OAuth 2.0 認可フレームワーク を採用することにしました。このフレームワークは、異なるグラントを通じて Timesheets API と通信する必要があるさまざまな種類のアプリケーションを容易に認可できるため、同社が求める柔軟性を提供します。

​

API の認証と認可

API は、アプリケーションの機能をほかのアプリケーションに公開するための仕組みです。アプリケーションは、API のエンドポイントにメッセージを送ってリクエストを行い、そのレスポンスとして情報を受け取ることができます。

API エンドポイントは、保護されている場合もあれば、そうでない場合もあります。この例では、タイムシートはレビューや支払いに影響する機微な情報であるため、認可されたユーザーとアプリケーションだけが API のエンドポイントを呼び出せるようにすることが重要です。クライアントアプリケーションが API の保護されたエンドポイントにアクセスする場合は、エンドポイントの呼び出しに必要な権限を持っていることの証明として、アクセストークンを提示する必要があります。

アクセストークンは、認可サーバーでユーザーを認証して取得します。その後、ユーザーはアプリケーションに対して、自分に代わって API にアクセスすることを認可できます。

アクセストークンとは

アクセストークン (access_token とも呼ばれます) は、アプリケーションに発行された認可を表す不透明な文字列です。これは、認可情報を取得するために使用される識別子を表す場合もあれば、認可情報 (たとえば、ユーザーの ID や権限など) を検証可能な形式でそれ自体に含む場合もあります。

アクセストークンは、JSON Web Tokens として実装されることがよくあります。

Auth0 のアクセストークンの詳細については、Access Token を参照してください。

API では、API が公開するさまざまなエンドポイントに対して、誰がアクセスできるかを細かく制御できます。これらの権限はスコープとして表現されます。

ユーザーがクライアントアプリケーションを認可する際、アプリケーションは必要な権限を指定することもできます。ユーザーはそれらの権限を確認し、付与できます。これらの権限は、その後アクセストークンの scope クレームに含まれます。

その後、クライアントが API へのリクエスト時にアクセストークンを渡すと、API は scope クレームを確認して、その特定の API エンドポイントを呼び出すために必要な権限が付与されていることを検証できます。

Scopes とは

各アクセストークンには、クライアントに付与された権限の一覧を含めることができます。クライアントが Auth0 で認証されるときには、要求するスコープ (または権限) の一覧を指定します。それらのスコープが認可されると、アクセストークンには認可されたスコープの一覧が含まれます。

たとえば、タイムシート API では、4 つの異なる認可レベルを受け付ける場合があります。タイムシートの読み取り (スコープ read:timesheets) 、タイムシートの作成 (スコープ create:timesheets) 、タイムシートの削除 (スコープ delete:timesheets) 、タイムシートの承認 (スコープ approve:timesheets) です。

クライアントが API に新しいタイムシートエントリーの作成を要求する場合、アクセストークンには create:timesheets スコープが含まれている必要があります。同様に、既存のタイムシートを削除するには、アクセストークンに delete:timesheets スコープが含まれている必要があります。

スコープの詳細については、Scopes を参照してください。

OAuth 2.0 認可フレームワークを使用すると、自身のアプリケーションまたはサードパーティアプリケーションに対して、アプリケーション自体に代わって API への限定的なアクセス権を付与できます。Auth0 を使用すれば、OAuth 2.0/OpenID Connect (OIDC) 仕様や、API 認可に関するそのほか多くの技術的な側面を意識することなく、自身の API でさまざまなフローを簡単にサポートできます。

OAuthの役割

OAuth 2.0 のフローには、次の役割があります。

• Resource Owner: 保護されたリソースへのアクセスを許可できる主体です。通常はエンドユーザーです。
• Resource Server: 保護されたリソースをホストするサーバーです。つまり、アクセス先の API です。
• Client: Resource Owner に代わって、保護されたリソースへのアクセスを要求するアプリケーションです。
• 認可サーバー: Resource Owner を認証し、適切な認可を得た後でアクセストークンを発行するサーバーです。この場合は Auth0 の Authentication API です。

Grantタイプ (またはフロー) は、これらの参加者がどのように連携して、構築中の API に対する限定的なアクセス権をアプリケーションに付与するかを定義します。その結果、アプリはユーザーに代わって API を呼び出すために使用できるアクセストークンを取得します。

​

Proof Key for Code Exchange (PKCE)

OAuth 2 では、ユースケースに応じて複数のグラントタイプが提供されています。このユースケースでは、モバイルアプリケーションから API にアクセスするために、Authorization Code Flow with Proof Key for Code Exchange (PKCE) を使用します。

Authorization Code Flow は、ネイティブアプリケーションで実装するといくつかのセキュリティ上の問題があります。たとえば、悪意のある攻撃者が Auth0 から返された authorization_code を傍受し、それを アクセストークン (場合によっては リフレッシュトークン も) に交換してしまう可能性があります。

Proof Key for Code Exchange (PKCE) は、 (RFC 7636 で定義されている) この認可コード傍受攻撃を軽減するための手法です。

PKCE では、アプリケーションは認可リクエストごとに、code_verifier と呼ばれる暗号学的にランダムなキーと、その変換後の値である code_challenge を生成し、authorization_code を取得するために Auth0 に送信します。アプリケーションが authorization_code を受け取ると、要求したトークンと引き換えに、その code と code_verifier を Auth0 の トークンエンドポイント に送信します。

1. ネイティブアプリがフローを開始し、code_challenge パラメーターと code_challenge_method パラメーターを送信して、ユーザーを Auth0 (具体的には /authorize エンドポイント) にリダイレクトします。
2. Auth0 は、クエリ文字列に authorization_code を含めて、ユーザーをネイティブアプリにリダイレクトします。
3. ネイティブアプリは、authorization_code と code_verifier を、redirect_uri および client_id とともに Auth0 に送信します。これは /oauth/token エンドポイント を使用して行います。
4. Auth0 はこの情報を検証し、アクセストークン (必要に応じてリフレッシュトークンも) を返します。
5. ネイティブアプリは、ユーザーに代わって API を呼び出すためにアクセストークンを使用できます。

Refresh Token Rotation を有効にしている場合は、リクエストごとに新しいリフレッシュトークンが生成され、アクセストークンとともに発行されます。リフレッシュトークンが交換されると、以前のリフレッシュトークンは無効化されますが、その関連情報は認可サーバーによって保持されます。

​

Authorization Extension

Auth0 Authorization Extension を使用すると、ユーザーにロール、グループ、権限を割り当てることで、アプリケーションで認可をサポートできます。

Authorization Extension は Rule を作成し、認証フロー中にユーザーに割り当てられたロール、グループ、権限をユーザープロファイルに追加します。これにより、ユーザーに発行されるアクセストークンに、Authorization Extension で定義された権限に基づいて許可されたスコープのみが含まれるようにできます。

前のチュートリアル はじめに

次のチュートリアル 2. Auth0 の設定