Securing REST-ful Web Services with OAuth2

Dave Syer, 2012
Twitter: @david_syer




What is a Lightweight Service?

What Are the Security Requirements

Identity and permissions:

HTTP Basic Authentication


    $ curl "https://$username:$password@myhost/resource"

So what's wrong with that?

User or Client Permissions

Identity Management: Three Corners


Identity Management: Four Corners


Centralized Identity Management


Centralized Identity Management


Centralizing accounts and secrets is great, but what about permissions?

Quick Introduction to OAuth2

A Client application, often web application, acts on behalf of a User, but with the User's approval

Common examples of Authorization Servers on the internet:

Typical Web Application Client


OAuth2 and the Lightweight Service

Example command line Client:

$ curl -H "Authorization: Bearer $TOKEN" https://myhost/resource

Role of Client Application

Obtaining a Client Credentials Token

A client can act in its own right (not on behalf of a user):

$ curl "" 
    -d grant_type=client_credentials -d client_id=myclient


  access_token: FUYGKRWFG.jhdfgair7fylzshjg.o98q47tgh.fljgh,
  expires_in: 43200,
  client_id: myclient,
  scope: uaa.admin

OAuth2 Key Features

UAA Bearer Tokens

Web Application Client Again

The Client wants to access a Resource on behalf of the User


Obtaining a User Token

A client can act on behalf of a user (e.g. authorization_code grant):


Authorization Code Grant Summary

  1. Authorization Server authenticates the User

  2. Client starts the authorization flow and obtain User's approval

  3. Authorization Server issues an authorization code (opaque one-time token)

  4. Client exchanges the authorization code for an access token.

Role of Resource Server

  1. Extract token from request and decode it
  2. Make access control decision
    • Scope
    • Audience
    • User account information (id, roles etc.)
    • Client information (id, roles etc.)
  3. Send 403 (FORBIDDEN) if token not sufficient

Role of the Authorization Server

  1. Grant tokens
  2. Interface for users to confirm that they authorize the Client to act on their behalf
  3. Authenticate users (/authorize)
  4. Authenticate clients (/token)

#1 and #4 are covered thoroughly by the spec; #2 and #3 not (for good reasons).

Client Registration and Scopes

For secure channels a client has to authenticate itself to obtain a token, so it has to be known to the Authorization Server. Registration provides at a mimimum:

Also useful:

More on Scopes

Per the spec they are arbitrary strings. The Authorization Server and the Resource Servers agree on the content and meanings.


Authorization Server has to decide whether to grant a token to a given client and user based on the requested scope (if any).

UAA Scopes

Special Mention for Vmc

The UAA authenticates requests from vmc in a special way:

$ curl
    -d response_type=token -d client_id=vmc
    -d source=credentials
    -d username=$username -d password=$password



Authentication and the Authorization Server

Cloud Foundry UAA Authorization Server


Cloud Foundry Login Server


Role of Login Server

Cloud Foundry UAA as a General Purpose Solution

UAA OAuth Implementation

UAA makes some explicit choices where the spec allows it, and also adds some useful features:

UAA Resources (Endpoints)

Brief list of all the UAA endpoints (with valid scopes if it is an OAuth2 resource):

UAA Resources (continued)

Alternatives to OAuth2

In Conclusion