# Authentication

This documentation is based on the *FoodCrunch* use case. Please open the link below alongside this page to understand the examples.

{% content-ref url="../../introduction-and-use-case" %}
[introduction-and-use-case](https://docs.squidex.io/id-02-documentation/introduction-and-use-case)
{% endcontent-ref %}

## Introduction

Squidex uses OpenID Connect and OAuth2.0 as authentication protocols. Both are state-of-the-art specifications and adopted by a lot of internet services. You have already used these protocols before, when logging in with your Google account to a third-party website.

The implementation uses [IdentityServer4](https://identityserver.io), a certified access control solution.

## Basic Authentication Flow

First, let's talk about the general authentication flow.

### 1. Generate Clients

Before you gain an access token you must create a client first. A client is just another name for an application and could be a mobile App, a public website, single page application or a backend server.

If you create a new App, it will already have a default client.

<div align="left"><figure><img src="https://2730255609-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LrL94QfeasZ0wF6YAvB%2Fuploads%2FSjHPC4RzzM1HBvHgo3V6%2F2023-04-10_11-50.png?alt=media&#x26;token=ef6b7228-0a68-4760-a923-e6fe90bdbba9" alt=""><figcaption><p>Default Client</p></figcaption></figure></div>

Each client also has a role assigned to define which updates or queries can be performed with the client. This is particularly useful when your client is a public application that can easily be a reversed engineer, like a mobile App or single page application. You can store your client credentials (*Client ID* and *Client Secret*) in the application but you have to ensure that you only give your client the necessary permissions and not more.

Read more about permissions in the following link.

{% content-ref url="../../concepts/permissions" %}
[permissions](https://docs.squidex.io/id-02-documentation/concepts/permissions)
{% endcontent-ref %}

### 2. Request a Token

The client ID and secret cannot be used directly in the API calls. You have to create an additional request to the identity-server first to gain an access token. This token is then valid for 30 days.

## Get access token

<mark style="color:green;">`POST`</mark> `https://cloud.squidex.io/identity-server/connect/token`

Get an access token from Squidex Identity.

#### Request Body

| Name           | Type   | Description                 |
| -------------- | ------ | --------------------------- |
| scope          | string | squidex-api                 |
| client\_secret | string | **\<YOUR\_CLIENT\_SECRET>** |
| client\_id     | string | **\<YOUR\_CLIENT\_ID>**     |
| grant\_type    | string | client\_credentials         |

{% tabs %}
{% tab title="200 The token response." %}

```
{
    "access_token":"<YOUR_ACCESS_TOKEN>,
    "expires_in":2592000,  // Expiration in seconds, 30 days
    "token_type":"Bearer",
    "scope":"squidex-api"
}
```

{% endtab %}
{% endtabs %}

Or simply create a request with curl:

```bash
curl
    -X POST 'https://cloud.squidex.io/identity-server/connect/token'
    -H 'Content-Type: application/x-www-form-urlencoded'
    -d 'grant_type=client_credentials&
        client_id=<YOUR_CLIENT_ID>&
        client_secret=<YOUR_CLIENT_SECRET>&
        scope=squidex-api
```

### 3. Use the Token

Add the returned token to all consecutive requests:

```bash
Authorization: Bearer <YOUR_ACCESS_TOKEN>
```

## How to Deal With the Access Token

A frequently asked question is how to deal with the access token, because there are a few challenges:

1. The token is only valid for 30 days.
2. The token might expire sooner, for example, when a certificate is replaced on the server.
3. You need an additional request to get the token.

Our recommendation is to use the following pattern (pseudo code):

```javascript
function makeRequest(url, body) {
    const token = getTokenFromCache();
    
    if (!token) {
        token = getToken(clientId, clientSecret);
        
        storeTokenInCache(token, days: 30);
    }
    
    const response = makeRequestToSquidex(url, body);
    
    // Token has probably expired. 
    if (response.status == 401) {
        // Request the token again.
        token = getToken(clientId, clientSecret);
        
        storeTokenInCache(token, days: 30);
        
        // Try the request again.
        response = makeRequestToSquidex(url, body);
    }
    
    // You can still have a 401 here, but this very likely not an epxired token then.
    return response;
}
```

As you can see, we use a simple memory cache to keep our token. We request a new token when it has expired in the cache or on the server and before the first request (after our application started).

You can also request multiple tokens in parallel, for example, when you have a cluster of servers. There is no need to sync the access tokens between your servers or to keep them in a centralized cache.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.squidex.io/id-02-documentation/developer-guides/api-overview/authentication.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.