> ## Documentation Index
> Fetch the complete documentation index at: https://docs-dev-fix-docs-5528-php-updates.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# ソリューションの概要（モバイルアプリ + API）
> モバイルアプリ + APIアーキテクチャシナリオでのソリューションの概要
ExampleCoでは、認可されたユーザーとアプリケーションだけがタイムシートAPIにアクセスできるように、[OAuth 2.00の認可フレームワーク](https://tools.ietf.org/html/rfc6749)を使用することに決めました。このフレームワークは、異なる付与タイプを使用して、タイムシートAPIと通信する必要があるさまざまな種類のアプリケーションを簡単に認可できるため、同社が求めている柔軟性を提供しています。
## API認証と認可
APIは、アプリケーションの機能性を他のアプリケーションに公開する手段になります。アプリケーションは、APIエンドポイントにメッセージを送信することで要求を行い、応答として情報を受信することができます。
APIエンドポイントはセキュリティ保護されている場合と、そうでない場合があります。この例では、タイムシートAPI審査や財務情報などの機密情報であるため、認可されたユーザーとアプリケーションだけがAPIのエンドポイントを呼び出せるようにしなければなりません。クライアントアプリケーションがAPIの保護されたエンドポイントにアクセスしたい場合は、エンドポイントへの呼び出しに必要なアクセス許可を備えている証拠としてアクセストークンを提示する必要があります。
アクセストークンは認証サーバーでユーザーを認証することにより取得され、ユーザーはアプリケーションが自身の代理でAPIにアクセスすることを許可できます。
アクセストークン（`access_token`とも呼ばれる）は、アプリケーションに対して発行された認可を表す、不透明な文字列です。この文字列は、認証情報の取得に使う識別子の場合もあれば、認証情報そのもの（たとえば、ユーザーのID、アクセス許可など）を検証可能な形で含んでいることもあります。
アクセストークンはたいていの場合、[JSON Web Token](https://auth0.com/docs/tokens/concepts/jwts)として実装されます。
Auth0アクセストークンの詳細については、「[アクセストークン](https://auth0.com/docs/tokens/concepts/access-tokens)」を参照してください。
APIは、APIが公開するさまざまなエンドポイントに誰がアクセスを許可されるかについて、きめ細かい制御を行うことができます。これらのアクセス許可はスコープと呼ばれます。
ユーザーがクライアントアプリケーションを認可すると、アプリケーションは必要とされるアクセス許可も指定することができます。ユーザーはこれらのアクセス許可を確認して付与します。そして、これらのアクセス許可が`scope`クレームの一部としてアクセストークンに含まれます。
その後、クライアントがAPIへの要求でアクセストークンを渡すと、APIは`scope`クレームを調査し、特定のAPIエンドポイントを呼び出すために必要なアクセス許可が付与されていることを確認します。
それぞれのアクセストークンには、クライアントに付与されたアクセス権限のリストが含まれます。クライアントがAuth0で認証を行う際、要求するスコープ（アクセス許可）のリストを指定します。スコープが認可されると、アクセストークンに認可されたスコープのリストが含められます。
たとえば、タイムシートAPIは、タイムシートの読み取り（スコープ：`read:timesheets`）、タイムシートの作成（スコープ：`create:timesheets`）、タイムシートの削除（スコープ：`delete:timesheets`）、タイムシートの承認（スコープ：`approve:timesheets`）という異なる4レベルの認可を受け入れることができます。
クライアントがAPIに新しいタイムシートエントリーの作成を依頼するときは、アクセストークンに`create:timesheets`スコープが含まれなくてはなりません。同様に、既存のタイムシートを削除するには、アクセストークンに`delete:timesheets`スコープが含まれなくてはなりません。
スコープの詳細については、「[スコープ](https://auth0.com/docs/scopes)」を参照してください。
OAuth 2.0 Authorization Framework使用することで、独自のアプリケーションや社外の請負業者向けのサードパーティアプリケーションは、アプリケーション自体に代わってAPIに制限付きでアクセスできるようになります。Auth0を使用することで、OAuth 2.0/OpenID Connect（OIDC）の仕様や、API認証に関する他の多くの技術的側面を心配することなく、独自のAPIで異なる認証フローを簡単にサポートすることができます。
OAuth 2.0フローでは、次のロールが識別されます：
* **リソース所有者（Resource Owner）** ：保護されたリソースへのアクセス権を付与できるエンティティ。通常は、エンドユーザーです。
* **リソースサーバー（Resource Server）** ：保護されたリソースをホストするサーバー。アクセスしたいAPIのことです。
* **クライアント（Client）** ：リソース所有者の代わりに保護されたリソースへのアクセス権を要求するアプリケーション。
* **認可サーバー（Authorization Server）** ：リソース所有者を認証し、適切な認可を得た後にアクセストークンを発行するサーバー。この場合、Auth0の認証APIになります。
[付与タイプ（またはフロー）](https://auth0.com/docs/api-auth/which-oauth-flow-to-use)は、これらの関係者がどのように作用し、ビルド中のAPIへの制限付きアクセスをアプリに付与するのかを決定します。そして、ユーザーの代わりにAPIを呼び出すためのアクセストークンをアプリが取得します。
## Proof Key for Code Exchange（PKCE）
OAuth 2には、異なるユースケースにいくつかの付与タイプが用意されます。この特定のユースケースでは、モバイルアプリケーションからAPIにアクセスしたいとします。そのためには、[Proof Key for Code Exchange（PKCE）を使った認可コードフロー](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce)を使用します。
[認証コードフロー](/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)）と交換する可能性があります。
[RFC 7636](https://tools.ietf.org/html/rfc7636)で定義されているProof Key for Code Exchange（PKCE）は、この認可コードの傍受攻撃を軽減するために用いられる手法です。
アプリケーションはPKCEを使って、それぞれの認可要求に`code_verifier`と呼ばれる暗号的にランダムなキーと、それから生成される`code_challenge`と呼ばれる値を作成します。そして、このキーは`authorization_code`を取得するためにAuth0に送られます。アプリケーションが`authorization_code`を受け取ると、コードと`code_verifier`をAuth0のトークンエンドポイントに送信し、要求されたトークンと交換します。
1. ネイティブアプリはフローを開始して、ユーザーをAuth0（具体的には[/authorize](/docs/ja-jp/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](/docs/ja-jp/api/authentication?http#authorization-code-pkce-)を使って行われます。
4. Auth0はこの情報を検証し、アクセストークン（と任意でリフレッシュトークン）を返します。
5. ネイティブアプリはアクセストークンを使って、ユーザーの代わりにAPIを呼び出します。
[［Refresh Token Rotation（リフレッシュトークンのローテーション）］](https://auth0.com/docs/tokens/concepts/refresh-token-rotation)を有効にした場合、要求ごとに新しいリフレッシュトークンが生成され、アクセストークンと共に発行されます。リフレッシュトークンが交換されると、前のリフレッシュトークンは失効しますが、関係についての情報は認可サーバーによって維持されます。
## 認可拡張機能
[Auth0のAuthorization Extension（認可拡張機能）](/docs/ja-jp/customize/extensions/authorization-extension)はユーザーにロール、グループとアクセス許可を割り当てることにより、アプリケーション内で認可に対応できるようにします。
認可拡張機能は[ルール](/docs/ja-jp/customize/rules)を作成し、認証フローの中で、ユーザーに割り当てられたロール、グループとアクセス許可を使ってユーザープロファイルを増補します。この情報を使用して、ユーザーに発行されたアクセストークンに、認可拡張機能で定義された権限が許すスコープのみが含まれるようにします。
前のチュートリアル [はじめに](/docs/ja-jp/get-started/architecture-scenarios/mobile-api)
次のチュートリアル [2.Auth0の構成](/docs/ja-jp/get-started/architecture-scenarios/mobile-api/part-2)