Authentication
How to Retrieve Access Tokens to Gain Access to the API
Last updated
How to Retrieve Access Tokens to Gain Access to the API
Last updated
This documentation is based on the FoodCrunch use case. Please open the link below alongside this page to understand the examples.
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, a certified access control solution.
First, let's talk about the general authentication flow.
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.
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.
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.
POST
https://cloud.squidex.io/identity-server/connect/token
Get an access token from Squidex Identity.
Or simply create a request with curl:
Add the returned token to all consecutive requests:
A frequently asked question is how to deal with the access token, because there are a few challenges:
The token is only valid for 30 days.
The token might expire sooner, for example, when a certificate is replaced on the server.
You need an additional request to get the token.
Our recommendation is to use the following pattern (pseudo code):
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.
Name | Type | Description |
---|---|---|
scope
string
squidex-api
client_secret
string
<YOUR_CLIENT_SECRET>
client_id
string
<YOUR_CLIENT_ID>
grant_type
string
client_credentials