> ## Documentation Index
> Fetch the complete documentation index at: https://translations.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

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

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

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

<div id="api-authentication-and-authorization">
  ## API の認証と認可
</div>

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

API エンドポイントは、保護されている場合もあれば、そうでない場合もあります。この例では、タイムシートはレビューや支払いに影響する機微な情報であるため、認可されたユーザーとアプリケーションだけが API のエンドポイントを呼び出せるようにすることが重要です。クライアントアプリケーションが API の保護されたエンドポイントにアクセスする場合は、エンドポイントの呼び出しに必要な権限を持っていることの証明として、<Tooltip tip="アクセストークン: API へのアクセスに使用される、不透明な文字列または JWT の形式の認可クレデンシャル。" cta="用語集を見る" href="/ja/docs/glossary?term=Access+Token">アクセストークン</Tooltip>を提示する必要があります。

アクセストークンは、<Tooltip tip="認可サーバー: ユーザーアクセスの境界の定義に関与する集中管理型サーバーです。たとえば、認可サーバーは、ユーザーが利用できるデータ、タスク、機能を制御できます。" cta="用語集を見る" href="/ja/docs/glossary?term=Authorization+Server">認可サーバー</Tooltip>でユーザーを認証して取得します。その後、ユーザーはアプリケーションに対して、自分に代わって API にアクセスすることを認可できます。

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

  アクセストークンは、[JSON Web Tokens](/ja/docs/secure/tokens/json-web-tokens) として実装されることがよくあります。

  Auth0 のアクセストークンの詳細については、[Access Token](/ja/docs/secure/tokens/access-tokens) を参照してください。
</Card>

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

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

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

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

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

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

  スコープの詳細については、[Scopes](/ja/docs/get-started/apis/scopes) を参照してください。
</Card>

<Tooltip tip="OAuth 2.0: 認可プロトコルとワークフローを定義する認可フレームワークです。" cta="用語集を見る" href="/ja/docs/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip> 認可フレームワークを使用すると、自身のアプリケーションまたはサードパーティアプリケーションに対して、アプリケーション自体に代わって API への限定的なアクセス権を付与できます。Auth0 を使用すれば、OAuth 2.0/<Tooltip tip="OpenID: アプリケーションがログイン情報を収集および保存することなく、ユーザーの ID を検証できるようにする認証のオープン標準です。" cta="用語集を見る" href="/ja/docs/glossary?term=OpenID">OpenID</Tooltip> Connect (OIDC) 仕様や、API 認可に関するそのほか多くの技術的な側面を意識することなく、自身の API でさまざまなフローを簡単にサポートできます。

<Card title="OAuthの役割">
  OAuth 2.0 のフローには、次の役割があります。

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

  [Grantタイプ (またはフロー) ](/ja/docs/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use) は、これらの参加者がどのように連携して、構築中の API に対する限定的なアクセス権をアプリケーションに付与するかを定義します。その結果、アプリはユーザーに代わって API を呼び出すために使用できるアクセストークンを取得します。
</Card>

<div id="proof-key-for-code-exchange-pkce">
  ## Proof Key for Code Exchange (PKCE)
</div>

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

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

Proof Key for Code Exchange (PKCE) は、 ([RFC 7636](https://tools.ietf.org/html/rfc7636) で定義されている) この認可コード傍受攻撃を軽減するための手法です。

PKCE では、アプリケーションは認可リクエストごとに、`code_verifier` と呼ばれる暗号学的にランダムなキーと、その変換後の値である `code_challenge` を生成し、`authorization_code` を取得するために Auth0 に送信します。アプリケーションが `authorization_code` を受け取ると、要求したトークンと引き換えに、その code と `code_verifier` を Auth0 の <Tooltip tip="トークンエンドポイント: プログラムからトークンをリクエストするために使用される認可サーバー上のエンドポイント。" cta="用語集を表示" href="/ja/docs/glossary?term=token+endpoint">トークンエンドポイント</Tooltip> に送信します。

<Frame>
  <img src="https://mintcdn.com/translations/c0RQ9V0YAcT0-8l5/docs/images/cdy7uua7fh8z/7pd2I8RXINIihsTyuGxvMb/cdbad014a576df5a15d53f84a5d97a55/authorization-code-grant-pkce.png?fit=max&auto=format&n=c0RQ9V0YAcT0-8l5&q=85&s=f194bc10192901784b3222b5b948b5d8" alt="Diagram - Microsite - Auth Code with PKCE" width="1500" height="1049" data-path="docs/images/cdy7uua7fh8z/7pd2I8RXINIihsTyuGxvMb/cdbad014a576df5a15d53f84a5d97a55/authorization-code-grant-pkce.png" />
</Frame>

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

<Callout icon="file-lines" color="#0EA5E9" iconType="regular">
  [Refresh Token Rotation](/ja/docs/secure/tokens/refresh-tokens/refresh-token-rotation) を有効にしている場合は、リクエストごとに新しいリフレッシュトークンが生成され、アクセストークンとともに発行されます。リフレッシュトークンが交換されると、以前のリフレッシュトークンは無効化されますが、その関連情報は認可サーバーによって保持されます。
</Callout>

<div id="authorization-extension">
  ## Authorization Extension
</div>

[Auth0 Authorization Extension](/ja/docs/customize/extensions/authorization-extension) を使用すると、ユーザーにロール、グループ、権限を割り当てることで、アプリケーションで認可をサポートできます。

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

前のチュートリアル [はじめに](/ja/docs/get-started/architecture-scenarios/mobile-api)

次のチュートリアル [2. Auth0 の設定](/ja/docs/get-started/architecture-scenarios/mobile-api/part-2)