Authorization refers to the process of granting a user or application access permissions to Spotify data and features. Spotify implements the OAuth 2.0 authorization framework:

illustration depicting a client app between the Spotify server and end user on the authorization framework


  • End User corresponds to the Spotify user. The End User grants access to the protected resources (e.g. playlists, personal information, etc.)

  • My App is the client that requests access to the protected resources (e.g. a mobile or web app).

  • Server which hosts the protected resources and provides authentication and authorization via OAuth 2.0.

The access to the protected resources is determined by one or several scopes. Scopes enable your application to access specific functionality (e.g. read a playlist, modify your library or just streaming) on behalf of a user. The set of scopes you set during the authorization, determines the access permissions that the user is asked to grant. You can find detailed information about scopes in the scopes guide.

The authorization process requires valid client credentials: a client ID and a client secret. You can follow the App settings guide to learn how to generate them.

Once the authorization is granted, the authorization server issues an access token, which is used to make API calls on behalf the user or application.

The OAuth2 standard defines four grant types (or flows) to request and get an access token. Spotify implements the following ones:

Which OAuth flow should I use?

Choosing one flow over the rest depends on the application you are building:

  • If you are developing a long-running application (e.g. web app running on the server) in which the user grants permission only once, and the client secret can be safely stored, then the authorization code flow is the recommended choice.

  • In scenarios where storing the client secret is not safe (e.g. desktop, mobile apps or JavaScript web apps running in the browser), you can use the authorization code with PKCE, as it provides protection against attacks where the authorization code may be intercepted.

  • For some applications running on the backend, such as CLIs or daemons, the system authenticates and authorizes the app rather than a user. For these scenarios, Client credentials is the typical choice. This flow does not include user authorization, so only endpoints that do not request user information (e.g. user profile data) can be accessed.

  • The implicit grant has some important downsides: it returns the token in the URL instead of a trusted channel, and does not support refresh token. Thus, we don’t recommend using this flow.

The following table summarizes the flows’ behaviors:

FLOW Access User Resources Requires Secret Key (Server-Side) Access Token Refresh
Authorization code Yes Yes Yes
Authorization code with PKCE Yes No Yes
Client credentials No Yes No
Implicit grant Yes No No

What’s next?

  • Before continuing, make sure you have created an app following the app settings guide.

  • Determine which kind of application you are going to develop and read the corresponding flow as described above.

  • Finally, learn how to use the requested access token by reading the How to use the Access Token Guide.