...
After more standardization, in 2010, Microsoft, Yahoo!, and Google created the Web Resource Authentication Protocol (WRAP), which was soon submitted into the IETF WG as input for OAuth 2.0. WRAP proposed significant reworking of the OAuth 1.0a model. Among the changes were was the deprecation of message signatures in favor of SSL, and a formal separation between the roles of ‘token issuance’ and ‘token reliance.’
...
- Third-party applications are required to store the resource owner's credentials for future use, typically a password in clear-text.
- Servers are required to support password authentication, despite the security weaknesses created by passwords.
- Third-party applications gain overly broad access to the resource owner's protected resources, leaving resource owners without any ability to restrict duration or access to a limited subset of resources.
- Resource owners cannot revoke access to an individual third-party without revoking access to all third-parties , and must do so by changing their password.
- Compromise of any third-party application results in compromise of the end-user's password and all of the data protected by that password.
...
This specification defines how 2-legged OAuth works with OAuth 1.0. However, it never became an IETF RFC.
With OAuth 1.0, 2-legged OAuth includes two parties, i.e., the consumer and the service provider. Basically, in this case, the consumer also becomes the resource owner. The consumer first needs to register a consumer_key and consumer_secret with the service provider. To access a Protected Resource, the consumer sends an HTTP(S) request to the Service Provider's resource endpoint URI. The request MUST be signed as defined in OAuth Core 1.0 section 9 with an empty Token Secret.
...
- Authorization code
- Implicit
- Resource owner password credentials
- Client credentials
More information about the grant types can found from here.
Client Credentials is the grant type which goes closely with 2-legged OAuth. With the Client Credentials grant type, the client can request an access token using only its client credentials (or other supported means of authentication) when the client is requesting access to the protected resources under its control. Once the client makes this request to the authorization server - it will return back an access token to access the protected resource. The access token returned back to the client could be either of type bearer of MAC. The "mac" token type defined in ietf-oauth-v2-http-mac is utilized by issuing a MAC key together with the access token which is used to sign certain components of the HTTP requests by the client when accessing the protected resource. The MAC scheme requires the establishment of a shared symmetric key between the client and the server. This is often accomplished through a manual process such as client registration.
...
- OAuth 2.0 in the form of a MAC-type access token, using any supported OAuth grant 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:
...
| Code Block |
|---|
GET /resource HTTP/1.1 Host: server.example.com Authorization: Bearer vF9dft4qmT |
Also - , the issued access token from the Authorization Server to the client, has an a '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. |
...
| Expand | ||
|---|---|---|
| ||
OAuth nonce and timestamp together play an important role when it comes to OAuth Security depending on how they are being implemented in an application. These two help OAuth to be protected from what is called a replay-attack - an attack where the same request is resendresent, maybe over and over again. The term nonce means ‘number used once’. It should be a unique and random string that is meant to uniquely identify each signed request. This string value is used to associate a Client session with an ID Token, and to mitigate replay attacks. In OAuth, the nonce value should be sent by the client during implicit flow. Then the value is passed through unmodified from the Authentication Request to ID token By having a unique identifier for each request, the Service Provider is able to prevent requests from being used more than once. When implementing this, the Consumer/Client generates a unique string for each request sent to the Service Provider. Service Provider keeps track of all the nonces used to prevent them from being used a second time. Since the nonce value is included in the signature, it cannot be changed by an attacker without knowing the shared secret. It becomes a problem when Service Provider keeps a persistent storage of all nonce values received. To make this practical, timestamp comes to play. OAuth adds a timestamp value to each request which allows the Service Provider to keep nonce values only for a limited time. When a request comes in with a timestamp that is older than the retained time frame, it is rejected as the Service Provider no longer has nonces from that time period. It is safe to assume that a request sent after the allowed time limit is a replay attack. The nonce together with the timestamp , provides a perpetual unique value that can never be used again by an attacker. |