JetBrains Space Help

Authorize with OAuth 2.0 Flows

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

  1. 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.

  2. 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.

  3. Your application requests access to Space resources presenting the obtained token in an HTTP authorization header.

Authorization scenarios

FlowsBest forOn behalf ofRequired parametersDetails
Client Credentials flowApplications that need to access resources on behalf of themselves, for example, chatbots.Applicationgrant_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 flowRich client web applications with authorization logic in a browserUsergrant_type, client_id, redirect_uriThe 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 flowWeb applications with authorization logic on the serverUsergrant_type, client_id, client_secret, redirect_uriThe 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

Usergrant_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 flowDesktop or mobile applications that request authorization tokens non-interactivelyUsergrant_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 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:

EndpointURL
Authentication<Space service URL>/oauth/auth
Token<Space service URL>/oauth/token
Last modified: 18 August 2021