Client Credentials
| Web Applications (Server) | Single Page Applications | Mobile Applications |
|---|---|---|
| Supported | Not Supported | Not Supported |
The Client Credentials grant type is used by clients to obtain an access token outside of the context of a user. This is typically used by clients to access resources about themselves rather than to access a user's resources. It allows your application to act as a service itself when accessing the API, rather than on behalf of a user. For example, you could use this grant type to access a list of schools that activated your application.
In this flow the client application requests an access token using only its client credentials. The client application authenticates with the authorization server and requests an access token from the token endpoint. Since the client application is requesting access to its own resources, no user authorization is needed. The authorization server authenticates the client application and issues an access token. This access token could then be used to access the Eduplaces API on behalf of the client application.
To request an access token for your client application, you need to authenticate with the authorization server using your client credentials (client ID + client secret). As public clients (such as single page applications and mobile applications) can not keep a client secret confidential, this grant type is not supported for these types of applications. You will always need a server-side component to keep your client secret confidential.
Requesting an access token
To request an access token, make a POST request to the token endpoint with the following parameters:
| Body Parameter | Description |
|---|---|
grant_type | required Must be set to client_credentials. |
scope | optional A space-delimited list of scopes. If not provided, the access token will have no scopes assigned. |
In addition to the body parameters, you must also send the following HTTP headers:
| Header | Description |
|---|---|
Content-Type | required Set to application/x-www-form-urlencoded. This will most likely be set automatically by your HTTP client. |
Authorization | required Set to Basic <base64(client_id:client_secret)>. |
POST /oauth2/token HTTP/1.1
Host: auth.eduplaces.io
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded
grant_type=client_credentials
Successful Response
If the request was successful, we will respond with a 200 OK status code and a JSON body containing the following parameters:
| Key | Value |
|---|---|
access_token | The access token your application can use to make API requests on its own behalf. |
token_type | The type of the access token. Always set to bearer. Note: It should be Bearer but unfortunately, our OAuth 2.0 server returns it in lowercase. Make sure to be able to handle both as this might change. |
expires_in | The remaining lifetime of the access token in seconds. |
scope | The scopes this access token is valid for. |
HTTP/1.1 200
Content-Type: application/json
{
"access_token": "ory_at_klaZ2HJ-YapwFb8hK7YUEATC02FSxRMZ0WOTRl7fITA.R7Tl2anTzcnho53zPDTgUiiZy1xD3nFduHKMUuQy6hI",
"token_type": "bearer"
"expires_in": 3599,
"scope": ""
}
Error Response
If the request was not successful, we will respond with an error.
The authorization server will respond with a 400 Bad Request status code and a JSON body containing the following parameters:
| Key | Value |
|---|---|
error | The error code. |
error_description | A human-readable text providing additional information. |
HTTP/1.1 400 Bad Request
Content-Type: application/json
{
"error": "invalid_request",
"error_description": "The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed."
}
Refer to the OAuth 2.0 specification for a list of error codes.
The error_description is optional and might not be included in the response. We will try to include it if possible, but you should not rely on its presence.