Authorize with OAuth 2.0 Flows

The authorization process consists of the following basic steps regardless of your client application type:

You register your client application in Space, specifying the required authentication flow and providing permissions to access certain Space resources. During the registration, you are given credentials, such as a client ID and client secret, that you provide to your application.
Your application requests an access token from Space, presenting client ID, client secret, and other credentials depending on the client application type and authorization flows it uses. If authentication is successful, the application is issued a token.
If you create the application using the Space SDK, you can use the built-in HTTP client that supports the authentication flows out of the box. Otherwise, you must implement the authorization flow of your choice by yourself as described in the corresponding topics of this guide.
Your application requests access to Space resources presenting the obtained token in an HTTP authorization header.

Authorization scenarios

Flows	Best for	On behalf of	Required parameters	Details
Client Credentials flow	Applications that need to access resources on behalf of themselves, for example, chatbots.	Application	`grant_type`, `client_id`, `client_secret`	The application receives an access token from Space by sending it `client_id` and `client_secret`. Resources that require user authorization cannot be accessed using the Client Credentials flow. Use other flows that allow your script to act on behalf of the user.
Implicit flow	Rich client web applications with authorization logic in a browser	User	`grant_type`, `client_id`, `redirect_uri`	The application sends a user to Space via a link that also includes the scope of user account permissions. After the user logs in to Space, Space redirects the user back to the application using the specified redirect URI. The redirect contains an access token for the application.
Authorization Code flow	Web applications with authorization logic on the server	User	`grant_type`, `client_id`, `client_secret`, `redirect_uri`	The application sends a user to Space via a link that also includes the scope of required resources. After the user logs in to Space, Space redirects the user back to the application using the specified redirect URI. The redirect also contains an authorization code. The application uses the authorization code to obtain an access token from Space.
Resource Owner Password Credentials flow	Not recommended Potentially, you can use it for scripts that need to access resources on behalf of some user	User	`grant_type`, `client_id`, `client_secret`, `username`, `password`, `scope`	A user provides the application their Space user credentials and the application uses them to get full access to Space on behalf of the user. We do not recommend that you use this flow as it is not secure. You don't have to explicitly enable this flow as it is enabled by default for all registered applications.
Refresh Token flow	Desktop or mobile applications that request authorization tokens non-interactively	User	`grant_type`, `client_id`, `client_secretrefresh_token`, `scope`	This is not a separate flow but an extension for Resource Owner Password Credentials and Authorization Code flows. If you select one of these flows during application registration, the Refresh Token flow will be automatically enabled for the application. In this flow, the application gets not only an access token but also a `refresh_token`. This token lets the application automatically get a new access token once the lifetime of the current one expires.

Endpoints

Space's OAuth 2.0 endpoints for authentication and token are:

Endpoint	URL
Authentication	`<Space service URL>/oauth/auth`
Token	`<Space service URL>/oauth/token`

Last modified: 18 August 2021