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 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_secret refresh_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 |
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 |