> ## 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 authorization framework](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="/docs/ja-jp/glossary?term=Access+Token">アクセストークン</Tooltip> を提示する必要があります。

アクセストークンは、ユーザーを <Tooltip tip="Authorization Server: ユーザーのアクセス範囲を定義するうえで中心的な役割を果たすサーバーです。たとえば、認可サーバーは、ユーザーが利用できるデータ、タスク、機能を制御できます。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Authorization+Server">Authorization Server</Tooltip> で認証することで取得されます。その後、ユーザーはアプリケーションが自分に代わって API にアクセスすることを認可できます。

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

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

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

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

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

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

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

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

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

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

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

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

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

  [グラントタイプ (またはフロー) ](/docs/ja-jp/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 にアクセスするため、[Proof Key for Code Exchange (PKCE) を使用する Authorization Code Flow](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce) を利用します。

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

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

PKCE では、Application は認可リクエストごとに、`code_verifier` と呼ばれる暗号学的にランダムな鍵と、その変換値である `code_challenge` を生成し、`authorization_code` を取得するために Auth0 に送信します。Application が `authorization_code` を受け取ると、要求したトークンと交換するため、そのコードと `code_verifier` を Auth0 の <Tooltip tip="トークンエンドポイント: Authorization Server 上で、プログラムからトークンを要求するために使用されるエンドポイント。" cta="用語集を見る" href="/docs/ja-jp/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. ネイティブアプリがフローを開始し、ユーザーを Auth0 にリダイレクトします (具体的には [/authorize endpoint](https://auth0.com/docs/api/authentication#authorization-code-grant-pkce-)) 。このとき、`code_challenge` と `code_challenge_method` パラメータを送信します。
2. Auth0 は、クエリ文字列に `authorization_code` を付与して、ユーザーをネイティブアプリにリダイレクトします。
3. ネイティブアプリは、`authorization_code` と `code_verifier` を、`redirect_uri` および `client_id` とともに Auth0 に送信します。これは [/oauth/token endpoint](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](/docs/ja-jp/secure/tokens/refresh-tokens/refresh-token-rotation) が有効になっている場合は、リクエストごとに新しいリフレッシュトークンが生成され、アクセストークンとともに発行されます。リフレッシュトークンが交換されると、以前のリフレッシュトークンは無効になりますが、その関連情報は認可サーバーに保持されます。
</Callout>

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

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

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

前のチュートリアル [Introduction](/docs/ja-jp/get-started/architecture-scenarios/mobile-api)

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