Examples

Back to Security Architecture

Client Credentials

Demonstrates using the grant_type client_credentials where 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, or those of another resource owner that have been previously arranged with the authorization server.

This example requires that you add 2 users to evo:

• user1/123
• user2/456

The user1 account only has scope=read but the resource (/v1/**) requires scope=write which is, at this time, hard coded in the oauth.xml config (see client-details-service). This client is able to generate an OAuth token but the generated token only allows read access.

The user2 account has both read/write scope and therefore is able to access the resource.

User1 (read access)

Generate Access Token

# Request
curl -u user1:123 'http://localhost:2600/oauth/token' -d grant_type=client_credentials

# Response
{
  "access_token":"7ad593a1-cc63-4c3b-a47c-64c5ccb6775e",
  "token_type":"bearer",
  "expires_in":43199,
  "scope":"read"
}

Access Resource

# Request
curl -H 'Authorization: bearer 7ad593a1-cc63-4c3b-a47c-64c5ccb6775e' http://localhost:2600/v1/twitter/tweet/1

# Response
{
  "error":"insufficient_scope",
  "error_description":"Insufficient scope for this resource",
  "scope":"write"
}

User2 (read,write access)

Generate Access Token

# Request
curl -u user2:456 'http://localhost:2600/oauth/token' -d grant_type=client_credentials

# Response
{
  "access_token":"82067120-00e0-4dca-a906-eb6b948c27b3",
  "token_type":"bearer",
  "expires_in":43200,
  "scope":"read write"
}

Access Resource

curl -H 'Authorization: bearer 82067120-00e0-4dca-a906-eb6b948c27b3' http://localhost:2600/v1/twitter/tweet/1

# Response
{"_index":"twitter","_type":"tweet","_id":"1","_version":1,"exists":true, "_source" : {
    "user" : "kimchy",
    "post_date" : "2009-11-15T14:12:12",
    "message" : "trying out Elastic Search"
}}