Authorization
This informational guide is geared towards application developers, and provides an overview of OAuth 2 roles, authorization grant types, use cases, and flows.
OAuth Roles
OAuth defines four roles:
Resource Owner:
The resource owner is the user who authorizes an application to access their account. The application’s access to the user’s account is limited to the scope of the authorization granted (e.g. read or write access)
Client:
The client is the application that wants to access the user’s account. Before it may do so, it must be authorized by the user, and the authorization must be validated by the API.
Resource Server:
The resource server hosts the protected user accounts.
Authorization Server:
The authorization server verifies the identity of the user then issues access tokens to the application.
From an application developer’s point of view, a service’s API fulfills both the resource and authorization server roles. We will refer to both of these roles combined, as the Service or API role.
Abstract Protocol Flow
The application requests authorization to access service resources from the user
If the user authorized the request, the application receives an authorization grant
The application requests an access token from the authorization server (API) by presenting authentication of its own identity, and the authorization grant
If the application identity is authenticated and the authorization grant is valid, the authorization server (API) issues an access token to the application.
Authorization is complete.
Note:
The application requests the resource from the resource server (API) and presents the access token for authentication If the access token is valid, the resource server (API) serves the resource to the application The actual flow of this process will differ depending on the authorization grant type in use, but this is the general idea. We will explore different grant types in a later section.
Application Registration
Before using OAuth with your application, you must register your application with the service. This is done through a registration form in the developer or API portion of the service’s website, where you will provide the following information (and probably details about your application):
- Application Name
- Application Website
- Redirect URI or Callback URL
- The redirect URI is where the service will redirect the user after they authorize (or deny) your application, and therefore the part of your application that will handle authorization codes or access tokens.
Grant Type: Client Credentials
The client credentials grant type provides an application a way to access its own service account.
Examples of when this might be useful include if an application wants to update its registered description or redirect URI, or access other data stored in its service account via the API.
Client Credentials Flow
- The application requests an access token by sending its credentials, its client ID and client secret, to the authorization server.
- An example POST request might look like the following:
https://oauth.example.com/token?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET
If the application credentials check out, the authorization server returns an access token to the application.
Now the application is authorized to use its own account.