OAuth 2.0 was architected with this variety of use cases in mind.
OAuth 2.0 defines several important client profiles:
An OAuth client running on a web server. The web application is accessed by a resource owner (user) and the application makes the appropriate API calls using a server-side programming language. The user has no access to the OAuth client secret or any access tokens issued by the authorization server.
An OAuth client which is very similar to the client-side application, as the credentials are not trusted to be kept confidential. However, since it’s an installed application, it may not have access to the full capabilities of a web browser.
Although signature-based MAC Access Authentication was mentioned earlier, most OAuth 2.0 authorized APIs require only bearer tokens to make authorized requests. Bearer tokens are a type of access token whereby simple possession of the token values provides access to protected resources. No additional information, such as a cryptographic key, is needed to make API calls.
Whether you're building a server-side web application, client-side web application, or a native application, the end goal of using OAuth is the same: you’re trying to obtain an OAuth access token that your application can use to perform API requests on behalf of a user or the application itself.
After obtaining an access token, the token can be sent along with
your requests in one of several ways. The preferred method of
authorizing requests is by sending the access token in a HTTP
GET /tasks/v1/lists/@default/tasks HTTP/1.1 Host: www.googleapis.com Authorization: Bearer ya29.AHES6ZSzX
Authorization header is the preferred
The header is rarely logged by proxy servers and web server access logs.
The header is almost never cached.
The header doesn’t get stored in the browser cache when making requests from the client.
While the other mechanisms are defined in the specification, API providers are not required to implement any of these additional methods, so your mileage will vary:
access_token as a URL query
parameter is useful for debugging and when libraries make it
difficult to modify the
This mechanism is also valuable when using the client-side flow
and sending a token in a JSONP request. For example,
This is a fallback mechanism for when an application cannot
Authorization header on requests. It
is only to be used when a HTTP body would normally be sent and can
then be added as an additional form parameter in an
application/ x-www-form-urlencoded body. This
mechanism is not supported by the Google Tasks API.
Each of the client profiles needs to be accommodated with an appropriate protocol flow for obtaining authorization from the resource owner for access to their data. The core OAuth 2.0 protocol defines four primary “grant types” used for obtaining authorization and also defines an extension mechanism for enabling additional grant types.
This grant type is most appropriate for server-side web
applications. After the resource owner has authorized access to
their data, they are redirected back to the web application with
an authorization code as a query parameter in the URL. This code
must be exchanged for an access token by the client application.
This exchange is done server-to-server and requires both the
client_secret, preventing even the
resource owner from obtaining the access token. This grant type
also allows for long-lived access to an API by using refresh
This grant type enables a resource owner’s username and password to be exchanged for an OAuth access token. It is used for only highly-trusted clients, such as a mobile application written by the API provider. While the user’s password is still exposed to the client, it does not need to be stored on the device. After the initial authentication, only the OAuth token needs to be stored. Because the password is not stored, the user can revoke access to the app without changing the password, and the token is scoped to a limited set of data, so this grant type still provides enhanced security over traditional username/password authentication.
The client credentials grant type allows an application to obtain an access token for resources owned by the client or when authorization has been “previously arranged with an authorization server.” This grant type is appropriate for applications that need to access APIs, such as storage services or databases, on behalf of themselves rather than on behalf of a specific user.
These additional flows are defined outside of the core spec:
The device profile was created to enable OAuth to be used on devices that do not have built-in web browsers or have limited input options—such as a game console or electronic photo frame. The user typically initiates the flow on the device and is then told to use a computer to access a website and approve access for the device by typing in an authorization code displayed in the device. Facebook has a great example of this flow referenced in its documentation.
This profile enables exchanging SAML 2.0 assertion for an OAuth access token. This is useful in enterprise environments that already have SAML authorization servers set up to control application and data access.