OAuth 2.0 is a protocol to allow applications limited access to remote resources, HTTP services like a REST WebAPI or WCF, on behalf of the resource owner or itself. The specification outline multiple workflows and understanding the differences and scenarios each apply is somewhat challenging. I hope to summarize the OAuth 2 flows and explain how to use each flow.
Authorization Code Flow
The Authorization Code flow is the first core workflow described in the specification. In the Authorization Code flow the client application initiates the workflow by directing the resource owner to a “user agent” which interacts with the authorization server to validate the user credentials. It’s important to understand the “user agent” is a vague term meant to describe a separation between the client application and the resource owner credentials. The “user agent” is an abstract concept that is one of many things; a common example is a browser but the Web Authentication Broker available Windows Store Applications serves the same purpose.
After the Authorization server validates the user credentials the “user agent” requests a “code” and gives this code to the client application. The client requests an access token from the authorization server by sending the “code”, its client ID, and client secret. The authorization server will validate the client and issue an access token to allow the client to make requests to the resource server on behalf of the user.
Implicit Grant Flow
The Implicit Grant flow is a simplify the Authorization Code flow for browser-based JavaScript client applications. The client initiates the process by directing the user to a “user agent” where the authorization server validates the user credentials, same as the authorization code flow. The next step is where the two flows differ, the authorization server redirects the “user agent” to the client resource server where it loads a script. The “user agent” executes the script and extracts the access token from the data passed along by the authorization server. In the last step, the “user agent” passes the access token back to the client so it can make requests on behalf of the user.
Resource Owner Credentials Flow
In the Resource Owner Credentials flow the client application captures the user credentials and requests an access token from the authorization server. The client will pass along the user credentials and the authorization server will issue an access token after the validating the credentials. If the client needs to authenticate itself, it will include the client ID and secret in the request. The specification suggests this flow be used when “the resource owner has a trust relationship with the client, such as the device operating system or a highly privileged application.”
Client Credentials Flow
The last of the core flows is the Client Credentials flow. Here the client can request an access token using only its client credentials when it is requesting access to protected resources under its control. In this case, the client is acting on its own behalf where as all other flows grant the client the ability to act on the behalf of a user.
