This is also known as the “Authorization Code Flow”.
This variant of OAuth2 is usually supposed to be used in a Server environment because some secret info needs to be used.
This is more widely supported than the “Implicit Grant” authorization flow.
For this authentication type you need:
- Client Id: the ID of the application you create on the API’s website. You can create your Spotify applications here for example.
- Client Secret: a secret key that is used to get access tokens from the API. This shouldn’t be shared with anyone if you don’t want them to be able to get access tokens on the behalf of the app you created. In the case of AutoWeb, since you’re creating your own applications you can safely use it inside the app. You can even share it with everyone else if you don’t mind having other people using your application quotas
- Endpoint: a URL that is used to perform the authentication. In Spotify’s case you can check that url in the Authorization Code Flow section of their authorization guide: https://accounts.spotify.com/authorize
- Refresh Endpoint: a URL that is used to get more valid access tokens that are needed to access the API on the user’s behalf. In the case of Spotify it’s https://accounts.spotify.com/api/token
- Scopes: a list of strings that represent what the application will be able to access on behalf of the signed-in user. For example, if a Spotify application wants to modify user’s private playlists, it’ll need to ask for the playlist-modify-private scope as seen here. You should probably just add all available scopes to cover for all the possible things an API can do.
When this authentication type is used, an authorization header will be added to each request made to the API. This token represents the permission that the user gave the application to act on her/his behalf.
Examples
Todoist – Endpoint is https://todoist.com/oauth/authorize and Refresh Endpoint is https://todoist.com/oauth/access_token