> ## 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.

> Server + API アーキテクチャのシナリオにおけるソリューション概要

# ソリューション概要（Server Apps + API）

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

<div id="oauth-20">
  ## OAuth 2.0
</div>

<Tooltip tip="OAuth 2.0: 認可のプロトコルとワークフローを定義する認可フレームワーク。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=OAuth+2.0">OAuth 2.0</Tooltip> 認可フレームワークを使用すると、ExampleCo の Regular Web アプリケーションと外部委託業者向けのサードパーティー アプリケーションは、Timesheets API に限定的にアクセスできるようになります。Auth0 を使えば、ExampleCo は OAuth 2.0/<Tooltip tip="OpenID: アプリケーションがログイン情報を収集・保存することなく、ユーザーの本人確認を行える認証用のオープン標準。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=OpenID">OpenID</Tooltip> Connect (OIDC) の仕様や、API 認可に関する数多くの技術的な側面を意識することなく、さまざまな [グラントタイプ](/docs/ja-jp/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use) や認証フローに簡単に対応できます。

<Card title="OAuth の役割">
  OAuth 2.0 のフローでは、次の役割を識別できます。

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

  [グラントタイプ (or flows)](/docs/ja-jp/get-started/authentication-and-authorization-flow/which-oauth-2-0-flow-should-i-use) は、これらの関係者がどのようにやり取りして、構築中の API への限定的なアクセスをアプリケーションに付与するかを定めるものです。その結果、アプリはユーザーに代わって API を呼び出すために使える アクセストークン を取得します。
</Card>

<div id="client-credentials-grant">
  ### クライアントクレデンシャルズグラント
</div>

OAuth 2 には、さまざまなユースケースに対応する複数のグラントタイプがあります。今回のように cron ジョブが API 経由でタイムシートをアップロードするケースでは、cron ジョブに API へアクセスするための権限を付与する対話的なユーザー (または <Tooltip tip="リソースオーナー: 保護されたリソースへのアクセスを許可できる主体（ユーザーやアプリケーションなど）。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=resource+owner">リソースオーナー</Tooltip>) は存在しません。

また、cron ジョブは特定のユーザーに代わって API 呼び出しを行うわけでもありません。代わりに、アプリケーション (cron ジョブ) はマシン間認可を使用して、<Tooltip tip="リソースサーバー: 保護されたリソースをホストするサーバー。リソースサーバーは保護されたリソースへのリクエストを受け付け、応答します。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Resource+Server">Resource Server</Tooltip> (API) に対して自らの behalf で呼び出しを行います。

このようにユーザーの操作が関与しない状況では、[Client Credentials Grant](/docs/ja-jp/get-started/authentication-and-authorization-flow/client-credentials-flow) が最適です。Client Credentials Grant ([RFC 6749, section 4.4](https://tools.ietf.org/html/rfc6749#section-4.4) で定義) では、アプリケーションは自身のクライアント認証情報 (<Tooltip tip="認可サーバー: ユーザーのアクセス範囲の境界を定義するのに関わる集中管理サーバー。たとえば認可サーバーは、ユーザーが利用できるデータ、タスク、機能を制御できます。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Client+ID">クライアント ID</Tooltip> と <Tooltip tip="クライアントシークレット: クライアント（アプリケーション）が Authorization Server に対して認証するために使う秘密情報。クライアントと Authorization Server だけが知っているべきであり、推測されないよう十分にランダムでなければなりません。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Client+Secret">クライアントシークレット</Tooltip>) を使って、<Tooltip tip="アクセストークン: API へのアクセスに使用される、不透明な文字列または JWT 形式の認可資格情報。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=Authorization+Server">Authorization Server</Tooltip> から直接 <Tooltip tip="アクセストークン: API へのアクセスに使用される、不透明な文字列または JWT 形式の認可資格情報。" cta="用語集を見る" href="/docs/ja-jp/glossary?term=access+token">アクセストークン</Tooltip> をリクエストできます。このトークンは Resource Owner を識別する代わりに、アプリケーション自体を表します。

<Frame>
  <img src="https://mintcdn.com/translations/MV7tE-x71x8RWRES/docs/images/cdy7uua7fh8z/5CfNEkbyG1ZC5BqHwi9gEs/309babf8329b165f1241f4cbc8e002ba/client-credentials-grant.png?fit=max&auto=format&n=MV7tE-x71x8RWRES&q=85&s=94755d8d68bfaf27437b43220939ef8c" alt="undefined" width="750" height="286" data-path="docs/images/cdy7uua7fh8z/5CfNEkbyG1ZC5BqHwi9gEs/309babf8329b165f1241f4cbc8e002ba/client-credentials-grant.png" />
</Frame>

1. アプリケーションは、Client ID と Client Secret を使用して Authorization Server に認証します。
2. Authorization Server はこの情報を検証し、アクセストークンを返します。
3. アプリケーションは、そのアクセストークンを使用して、自身の behalf で Resource Server を呼び出すことができます。

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

APIは、アプリケーションの機能をほかのアプリケーションに公開するための仕組みです。ほかのアプリケーションはAPIエンドポイントにリクエストを送信し、レスポンスを受け取ることができます。同様に、ExampleCoの委託先担当者が利用する外部アプリケーションも、Timesheet APIや、ExampleCoが社内従業員向けに構築したRegular Web Applicationと通信できます。

Timesheets APIは機密情報 (PIIや財務情報など) を扱うため、ExampleCoは、認可されたユーザーとアプリケーションのみがそのエンドポイントを呼び出せるようにする必要があります。

<div id="access-tokens-and-scopes">
  ### アクセストークンとスコープ
</div>

API には、保護されているものと保護されていないものがあります。アプリケーションが API の保護されたエンドポイントにアクセスする場合、必要な権限を持っていることを示す証明として、アクセストークン (`access_token` とも呼ばれます) を提示する必要があります。

アクセストークンは、アプリケーションに発行された認可を表す不透明な文字列で、Authorization Server でユーザーを認証することで取得されます。その後、ユーザーは自分に代わって API にアクセスすることをアプリケーションに許可できます。詳しくは、[Access Tokens](/docs/ja-jp/secure/tokens/access-tokens) を参照してください。

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

ExampleCo の Regular Web Application またはサードパーティのアプリケーションが、アクセストークンを取得するために Auth0 で認証するとき、認証リクエストには、そのアプリケーションが必要とする要求対象のスコープ一覧が含まれます。それらのスコープが許可されると、アクセストークンにはアプリケーションに付与された承認済みスコープの一覧が含まれます。

Regular Web App またはサードパーティのアプリケーションは、Timesheets API へのリクエスト時に Authorization Server から受け取ったアクセストークンを含めます。Timesheets API はスコープクレームを確認し、その特定のエンドポイントを呼び出すために必要な権限が付与されていることを検証します。

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

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

Regular Web App が新しい timesheet エントリを作成するために Timesheets API にリクエストを送信する場合、アクセストークンには `create:timesheets` スコープが含まれている必要があります。含まれていない場合、リクエストは拒否されます。同様に、既存の timesheet を削除するには、アクセストークンに `delete:timesheets` スコープが含まれている必要があります。

詳しくは、[Scopes](/docs/ja-jp/get-started/apis/scopes) を参照してください。