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

> Explains the architecture scenario where a single-page application (SPA) talks to an API using OpenID Connect (OIDC), and the OAuth 2.0 Implicit Grant Flow, to authenticate users with Auth0.

# Single-Page Applications (SPA) with API

In this scenario, we will build a timesheet API for a fictitious company named ExampleCo. The API will allow adding timesheet entries for an employee or a contractor.

We will also be building a single-page application (SPA) which will be used to log timesheet entries and send them to the centralized timesheet database using the API.

<Info>
  ### TL;DR

  * Auth0 provides API Authentication and Authorization as a means to secure access to API endpoints (see [API Authentication and Authorization](/docs/get-started/architecture-scenarios/spa-api/part-1#api-authentication-and-authorization))
  * For authorizing a user of a SPA, Auth0 supports the Implicit Grant (see [Implicit Grant](/docs/get-started/architecture-scenarios/spa-api/part-1#implicit-grant))
  * Both the SPA and the API must be configured in the Auth0 Dashboard (see [Auth0 Configuration](/docs/get-started/architecture-scenarios/spa-api/part-2#auth0-configuration))
  * User Permissions can be enforced using the Authorization Extension (see [Configure the Authorization Extension](/docs/get-started/architecture-scenarios/spa-api/part-2#configure-the-authorization-extension))
  * The API will be secured by ensuring that a valid Access Token is passed in the HTTP Authorization header when calls are made to the API (see [Implement the API](/docs/get-started/architecture-scenarios/spa-api/part-3#implement-the-api))
  * The Auth0.js library can be used to authorize the user of the SPA and obtain a valid Access Token which can be used to call the API (see [Authorize the User](/docs/get-started/architecture-scenarios/spa-api/part-3#authorize-the-user))
  * The SPA can pass the Access Token in the HTTP Authorization header when making calls to the API (see [Call the API](/docs/get-started/architecture-scenarios/spa-api/part-3#call-the-api))
  * The SPA can display UI elements conditionally based on scopes granted to user (see [Display UI Elements Conditionally Based on Scope](/docs/get-started/architecture-scenarios/spa-api/part-3#display-ui-elements-conditionally-based-on-scope))
</Info>

## The Premise

ExampleCo is a consulting startup company. Currently, they have approximately 100 employees and they also outsource several activities to external contractors. All employees and external contractors are required to fill in their timesheets every week.

The company has built a timesheets application, a scenario we covered in [Single Sign-On for Regular Web Apps](/docs/get-started/architecture-scenarios/sso-for-regular-web-apps). The internal employees use this web app to fill in their timesheets but the company wants to replace it with a SPA. The app will be used to log timesheet entries and send the data to the centralized timesheet database using the API. The app will also allow managers to approve timesheet entries.

## Goals & Requirements

ExampleCo wants to build a flexible solution. At the moment only a SPA is required to capture timesheet entries but in the future, the company plans on launching more applications, like a mobile app to accommodate their sales teams. Hence the company has decided to develop a single Timesheets API which will be used to log time not only by this server process but by all future applications as well. They want to put in place a security architecture that is flexible enough to accommodate this. ExampleCo wants to ensure that a large part of the code and business logic for the application can be shared across the different applications.

It is required that only authorized users and applications are allowed access to the Timesheets API.

Two kinds of users will use this SPA: employees and managers. The employees should be able to read, create and delete their own timesheet entries, while the managers should be able to approve timesheets as well.

## Learn more

* [Solution Overview (SPAs + API)](/docs/get-started/architecture-scenarios/spa-api/part-1)
* [Auth0 Configuration (SPAs + API)](/docs/get-started/architecture-scenarios/spa-api/part-2)
* [API and SPA Configuration (SPAs + API)](/docs/get-started/architecture-scenarios/spa-api/part-3)
* [Node.js API Implementation (SPAs + API)](/docs/get-started/architecture-scenarios/spa-api/api-implementation-nodejs)
* [SPA Angular 2 Implementation (SPAs + API)](/docs/get-started/architecture-scenarios/spa-api/spa-implementation-angular2)
* [Conclusion (SPAs + API)](/docs/get-started/architecture-scenarios/spa-api/part-4)