...
In case of 2-legged OAuth, the client becomes the resource owner.
We can at At a very high-level, it is possible to break the full OAuth flow into two parts.
- Get a token from the authorization server.
- Use the token to access the resource server.
Let's see how the above two steps work under 2-legged OAuth.
OAuth 2.0 defines a concept called "authorization grant" which is a credential representing the resource owner's authorization (to access its protected resources) used by the client to obtain an access token. This specification defines the following four grant types:
...
The OAuth 2.0 specification offers two methods for issuing a set of MAC credentials to the client using ..the following:
- OAuth 2.0 in the form of a MAC-type access token, using any supported OAuth grant type. [This is what we discussed above - an access token with 'MAC' type]
- The HTTP "Set-Cookie" response header field via an extension attribute.
When using MAC type access tokens with 2-legged OAuth - , the request to the protected resource looks like the following:
...
When using Bearer type access tokens with 2-legged OAuth - , the request to the protected resource looks like the following.
...
Also - the issued access token from the Authorization Server to the client, has an 'scope' attribute. [
| Info | ||
|---|---|---|
| ||
2-legged OAuth with OAuth 1. |
...
0 does not have this scope attribute as well as access token concept - so the resource server has to perform authorization separately based on the resource the client is going to access |
...
. |
The client should request access tokens with the minimal scope and lifetime necessary. The authorization server will take takes the client identity into account when choosing how to honor the requested scope and lifetime, and may issue an access token with a less rights than requested.
When securing APIs with OAuth - this 'scope' attribute can be bound to different APIs. So , the authorization server can decide whether to let the client access this API or not.