The implicit grant flow is carried out on the client side and it does not involve secret keys. Thus, you do not need any server-side code to use it. Access tokens issued are short-lived with no refresh token to extend them when they expire.
The following diagram shows how the Implicit Grant Flow works:
Implicit grant flow
This guide assumes that you have created an app following the app settings guide.
You can find an example app implementing Implicit Grant flow on GitHub in the web-api-auth-examples repository.
Request User Authorization
Our application must build a
GET request to the
/authorize endpoint with
the following parameters:
The client ID provided to you by Spotify when you register your application.
Set it to
The URI to redirect to after the user grants or denies permission. This URI needs to have been entered in the Redirect URI allowlist that you specified when you registered your application (See the app settings guide). The value of
but strongly recommended. The state can be useful for correlating requests and responses. Because your
A space-separated list of scopes.
Whether or not to force the user to approve the app again if they’ve already done so. If false (default), a user who has already approved the application may be automatically redirected to the URI specified by
The request is typically sent from the browser.
var client_id = 'CLIENT_ID'; var redirect_uri = 'http://localhost:8888/callback'; var state = generateRandomString(16); localStorage.setItem(stateKey, state); var scope = 'user-read-private user-read-email'; var url = 'https://accounts.spotify.com/authorize'; url += '?response_type=token'; url += '&client_id=' + encodeURIComponent(client_id); url += '&scope=' + encodeURIComponent(scope); url += '&redirect_uri=' + encodeURIComponent(redirect_uri); url += '&state=' + encodeURIComponent(state);
Once the request is processed, the user will see the authorization dialog asking to authorize access within the scopes.
The Spotify Accounts service presents details of the scopes for which access is being sought. If the user is not logged in, they are prompted to do so using their Spotify credentials. When the user is logged in, they are asked to authorize access to the resources or actions defined in the scopes.
Finally, the user is redirected back to your specified
the user accepts, or denies your request, the Spotify OAuth 2.0 server
redirects the user back to your
redirect_uri. In this example, the redirect
If the user grants access, the final URL will contain a hash fragment with the following data encoded as a query string.
|access_token||An access token that can be provided in subsequent calls, for example to Spotify Web API services.|
|expires_in||The time period (in seconds) for which the access token is valid.|
|state||The value of the state parameter supplied in authorization URI.|
If the user denies access, access token is not included and the final URL includes a query string containing the following parameters:
|error||The reason authorization failed, for example: “access_denied”.|
|state||The value of the state parameter supplied in the request.|
Learn how to use an access token to fetch track information from the Spotify Web API in the How to use the Access Token guide.