This documentation is for WSO2 Identity Server 5.4.0 . View documentation for the latest release.

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. Authorization code
  2. Implicit
  3. Resource owner password credentials
  4. 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.

...

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.

Expand
titleAbout Nonce and Timestamp..

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 resend, 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 timestamp, provides a perpetual unique value that can never be used again by an attacker.