OAuth2 and Scratch4All

(short note on how it could be used; Willem van Engen; 14 Nov 2011)

Scratch4All is currently in its implementation phase. It appears that authentication and authorization is not being addressed currently. This document describes shortly how it could be added using OAuth 2.0.

OAuth 2.0

OAuth 2.0 is the successor of OAuth 1.0a, supporting a variety of authorization flows. While this is still in draft, a number of large companies already supports it. There is a number of key terms:

• Client: application that needs to access a protected resource. This could be an application, running on the user's desktop, a web portal, a robot.
• Resource server (RS): the resource that provides a service, requiring authorization based on security tokens.
• Authorization server (AS): issuer of security tokens for one or more resource servers; token endpoint.
• Authorization endpoint (?): service providing input (e.g. authentication) on which the AS bases its decision.

Before the client accesses the RS (or it finds that authorization has been denied), it needs to request an access token from the AS. The AS provides the client with an access token when certain conditions have been met. This could be a recognised client (based on client credentials), a user logging in (using http redirects), or an authorization code or assertion obtained otherwise. OAuth 2.0 allows these different methods to co-exist. With the access token, the client can access the resource using an authentication header as specified in the OAuth 2.0 draft.

Tokens can be anything, simple web tokens (SWT) and java web tokens (SWT) are two common options. Both have a signature possibility (based on a shared secret between two parties).

Application to Scratch4All

Resource servers check that the provided access token is valid and issued by a trusted AS. When working with a specific token format (like SWT), it can also check attributes present in the access token as supplied by the AS.

Authorization servers need to supply access tokens. These could be issued for certain users and certain clients.

Robot scenario (clients)

When an automated service needs to access protected data, for example to build a search index for a user or enhance metadata automatically, it can be identified by its client credentials. The AS could issue an access token for these clients, possibly restricting the scope to just writing part of the user's data.

Interactive scenario (users)

A simple solution would be:

• User accesses a web portal
• User requests to work with a protected resource
• Portal requests an access token by redirecting the user's browser to the AS
• AS asks user to login
• Upon success, it redirects the user's browser to the web portal with an access token
• The web portal accesses the resource with the access token

Another solution would be:

• User accesses a web portal
• User requests to work with a protected resource
• Portal requests an authorization code by redirecting the user's browser to the authorization endpoint
• Authorization endpoint asks user to login
• Upon success, it redirects the user's browser to the web portal with an authorization token or assertion
• The web portal requests an access token using the authorization token or assertion
• The web portal accesses the resource with the access token

This allows a separation between authentication and AS roles, for example when more then one AS is involved.

Token expiration and refresh

Access tokens can expire. OAuth 2.0 specifies that authorization servers can supply refresh tokens to clients, which can be used to obtain a new access token from the AS.