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

# APIを使用したシングルページアプリケーション（SPA）

> シングルページアプリケーション（SPA）が、Auth0でのユーザー認証のために、OpenID Connect（OIDC）とOAuth 2.0の暗黙付与フローを使ってAPIに通信するアーキテクチャをご説明します。

この例では、ExampleCoという架空の会社のためにタイムシートAPIを作成します。このAPIにより、従業員・請負業者のタイムシートエントリーが追加できるようになります。

また、このAPIを使って、タイムシートエントリーのログを取ってそれを一元化されたタイムシートデータベースに送るシングルページアプリケーション（SPA）もビルドします。

<Info>
  ### TL;DR

  * Auth0はAPIエンドポイントへのアクセスを保護する手段として、API認証および認可を提供しています（[「API認証と認可」](/docs/ja-jp/get-started/architecture-scenarios/spa-api/part-1#api-authentication-and-authorization)を参照）
  * SPAのユーザーの認可には、Auth0はPKCEを使った認可コードフローの使用をお勧めします（ [「PKCEを使った認可コードフロー」](/docs/ja-jp/get-started/authentication-and-authorization-flow/call-your-api-using-the-authorization-code-flow-with-pkce)を参照）
  * SPAとAPIはAuth0 Dashboardで設定する必要があります（[「Auth0の構成」](/docs/ja-jp/architecture-scenarios/spa-api/part-2#auth0-configuration)を参照）
  * ユーザーの権限は、認可拡張機能を使用して強制することができます（[「認可拡張機能を構成する」](/docs/ja-jp/architecture-scenarios/spa-api/part-2#configure-the-authorization-extension)を参照）
  * APIは、APIへの呼び出し時にHTTP認可ヘッダーに有効なアクセストークンが渡されることを確認することで保護されます（[「APIを実装する」](/docs/ja-jp/get-started/architecture-scenarios/spa-api/part-3#implement-the-api)を参照）
  * Auth0.jsライブラリーを使用して、SPAのユーザーを認可し、有効なアクセストークンを取得し、APIを呼び出すことができます（[「ユーザーを認可する」](/docs/ja-jp/get-started/architecture-scenarios/spa-api/part-3#authorize-the-user)を参照）
  * SPAは、APIを呼び出す際にアクセストークンをHTTP認可ヘッダーに渡すことができます（[「APIを呼び出す」](/docs/ja-jp/get-started/architecture-scenarios/spa-api/part-3#call-the-api)を参照）
  * SPAは、付与されたスコープに基づいて条件付きでUI要素を表示できます（[「スコープに基づいた条件付きUI要素の表示」](/docs/ja-jp/get-started/architecture-scenarios/spa-api/part-3#display-ui-elements-conditionally-based-on-scope)を参照）
</Info>

<Warning>
  Auth0では、IDトークンのみを必要とするブラウザーベースのアプリケーションに対して暗黙の付与を使用することが可能ですが、[PKCE](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce)を使った認可コード付与を推奨しています。詳細については、Auth0ブログの「[OAuth2の暗黙の付与とSPA](https://auth0.com/blog/oauth2-implicit-grant-and-spa/)」を参照してください。

  ユーザーを再認証することなく新しいアクセストークンやIDトークンを取得できるように[フレッシュトークン](/docs/ja-jp/secure/tokens/refresh-tokens)が必要な場合は、[認可コード付与](/docs/ja-jp/get-started/authentication-and-authorization-flow/authorization-code-flow/call-your-api-using-the-authorization-code-flow)を使用する必要があります。
</Warning>

## 前提条件

ExampleCoは、コンサルティングを行うスタートアップ企業です。現在、従業員は約100名で、いくつかの業務を社外の請負業者に外注しています。従業員と請負業者は、毎週タイムシートに記入する必要があります。

そこで同社は、[通常のWebアプリ向けシングルサインオン](/docs/ja-jp/get-started/architecture-scenarios/sso-for-regular-web-apps)で紹介しているシナリオの通り、タイムシートのアプリケーションを構築しました。従業員は、このWebアプリを使ってタイムシートに記入していますが、会社はSPAに変えたいと考えています。SPAは、APIを使って、タイムシートエントリーのログを取り、そのデータを一元化されたタイムシートデータベースに送ります。また、管理職によるタイムシートエントリーの承認も可能になります。

## 目標と要件

ExampleCoは、フレキシブルなソリューションを構築したいと考えています。現時点で必要なのは、タイムシートエントリーを取得するSPだけですが、将来的には、販売チームの要望に沿ったモバイルアプリなど、さまざまなアプリを作成したいと考えています。そのため、会社は、単一のタイムシートAPIを開発して、このサーバープロセスだけでなく、将来的に導入されるすべてのアプリで時間を記録できるようにしようと決断しました。会社は、このような用途に対応できるフレキシブルなセキュリティアーキテクチャを実装したいと考えています。アプリケーションのコードやビジネスロジックの大部分を、他のアプリケーションと共有できるようにしたいのです。

タイムシートAPIには、認可されたユーザーとアプリケーションだけがアクセスできるようにする必要があります。

このSPAを使用するユーザーは、従業員と管理職の2種類です。従業員は、自分のタイムシートエントリーを表示・作成・削除することができて、管理職は、タイムシートの承認もできることが必要です。

## もっと詳しく

* [ソリューションの概要（モバイルアプリ + API）](/docs/ja-jp/get-started/architecture-scenarios/spa-api/part-1)
* [Auth0構成（SPA + API）](/docs/ja-jp/get-started/architecture-scenarios/spa-api/part-2)
* [APIとSPAの構成（SPA + API）](/docs/ja-jp/get-started/architecture-scenarios/spa-api/part-3)
* [Node.js APIの実装 (SPA+API)](/docs/ja-jp/get-started/architecture-scenarios/spa-api/api-implementation-nodejs)
* [Angular 2でのSPA実装（SPA + API）](/docs/ja-jp/get-started/architecture-scenarios/spa-api/spa-implementation-angular2)
* [まとめ（SPA + API）](/docs/ja-jp/get-started/architecture-scenarios/spa-api/part-4)