OAuth 2.0
OAuth 2.0 is an authorization framework that allows a client application to acquire limited access to a resource.
For example, suppose that you upload photographs to a photo-sharing site and use a photo-printing service to print them. The photographs are the resource, and the photo-printing service is the client. You want to give the service read-only access, for a limited duration. You don’t want to give the service your password for your resources. OAuth enables exactly this scenario.
| Advantages | Disadvantages |
|---|---|
|
|
OAuth defines four roles:
- Resource owner: The entity that grants access to a resource.
- Client: That application that requests access.
- Resource server: The server that hosts the resource.
- Authorization server: A server that authenticates the owner and issues access tokens to the client.
The same server might perform the “resource server” and “authorization server” roles. Conceptually, the flow in OAuth looks like this:
- The client requests authorization from the owner and receives a special type of credential (called a grant) for the resource. The grant is not the same as the user’s credentials, and typically has limited scope or duration.
- The client uses the grant to get an access token from the authorization server.
- The client uses the token to access the resource.

The specification calls this flow the abstract flow, because the actual implementation depends on the type of client (for example, native client application versus server-side web application).
While ASP.NET Web API does not provide any built-in support for implementing OAuth 2.0 flows, here is the general approach you should take:
- Your back-end web APIs are the protected resources.
- Provide an authorization server that client applications can use to get access tokens for the protected resources.
- Client applications direct the user to the authorization server, to grant the client the access token.
- Depending on the type of client, use one of the different kinds of OAuth 2 authorization grants.
- In your web API, use the access token to create a claims principal, and use the principal to authorize the request.

Comments (0) RSS Feed