Single Sign On

This is a protected page.

OAuth

Introduction

OAuth is an open authorization delegation protocol. It allows users (User) to share private resources (photos, videos, contact list, bank accounts) stored on one site (Service Provider) with another (Consumer) without having to hand out username and password. OAuth delegate access scenario, also known as 3-legged scenario, where three parties (legs) are involved: Service Provider, Consumer, and User. But OAuth can be used also for direct access scenario, known as 2-legged scenario – one side authenticates with the other, for example, a person logging to a site using username and password.

Example/Scenario

User wants to print photos using online print shop (in OAuth Consumer). The User logs in the online pirnt shop and say: „Import photos for printing from Flickr“. The user will be redirected to Flickr (in OAuth Service Provider) and has to log in and grant acces to the online print shop to his photos. Mostly is the access time-constrained (e.g. 1 hour). Then the user is redirected to the print shop and can choose from all his imported pictures from Flickr those for printing without sharing his credentials with the printing application.

Roles/Definitions

• Service Provider – Website or web-service where the restricted resources are located (e.g. Flickr)
• User – has account with Service Provider
• Consumer – web or desktop application uses OAuth to access the Service Provider on behalf of the user (e.g. online printing application)
• Consumer Developer - An individual or organization that implements a Consumer.

• Consumer Key - A value used by the Consumer to identify itself to the Service Provider.
• Consumer Secret - A secret used by the Consumer to establish ownership of the Consumer Key.

• Request Token - A value used by the Consumer to obtain authorization from the User, and exchanged for an Access Token.
• Access Token - A value used by the Consumer to gain access to the Protected Resources on behalf of the User, instead of using the User's Service Provider credentials.
• Token Secret - A secret used by the Consumer to establish ownership of a given Token.

• OAuth Protocol Parameters - Parameters with names beginning with oauth_.

OAuth includes a Consumer Key and matching Consumer Secret that together authenticate the Consumer (as opposed to the User) to the Service Provider. Consumer-specific identification allows the Service Provider to vary access levels to Consumers (such as un-throttled access to resources).

Service Providers SHOULD NOT rely on the Consumer Secret as a method to verify the Consumer identity, unless the Consumer Secret is known to be inaccessible to anyone other than the Consumer and the Service Provider. The Consumer Secret MAY be an empty string (for example when no Consumer verification is needed, or when verification is achieved through other means such as RSA).

see Core 1.0

How it works?

OAuth authentication is the process in which Users grant access to their Protected Resources (e.g. Photos) without sharing their credentials with the Consumer (e.g. Printing app). OAuth uses Tokens generated by the Service Provider instead of the User's credentials in Protected Resources requests.

OAuth Authentication is done in three steps:

The Consumer obtains an unauthorized Request Token

(3) The Consumer obtains an unauthorized Request Token by asking the Service Provider to issue a Token. Reques Token URL is used to obtain an unauthorized Request Token. The request MUST be signed and contains the parameters shown in the grafik.

For signature, timestamp and nonce see Hueniverse Security Architecture.

The oauth_callback is an absolute URL to which the Service Provider will redirect the User back when the Obtaining User Authorization step is completed.

(4) The Service Provider verifies the signature and Consumer Key. If successful, it generates a Request Token and Token Secret and returns them to the Consumer in the HTTP response body as defined in Service Provider Response Parameters.

For more information see OAuth Core 1.0 - Obtaining an Unauthorized Request Token

The User authorizes the Request Token

• (5) Consumer directs the User to the Service Provider

In order for the Consumer to be able to exchange the Request Token for an Access Token, the Consumer MUST obtain approval from the User by directing the User to the Service Provider. User Authorization URL is used to obtain User authorization for Consumer access.

• (6) and (7) Service Provider authenticates the User and obtains Consent

The Service Provider verifies the User's identity and asks for consent as detailed. OAuth does not specify how the Service Provider authenticates the User, but definies a set of REQUIRED steps:

• • The Service Provider MUST first verify the User's identity before asking for consent. It MAY prompt the User to sign in if the User has not already done so.
  • The Service Provider presents to the User information about the Consumer requesting access (as registered by the Consumer Developer). The information includes the duration of the access and the Protected Resources provided.
  • The User MUST grant or deny permission for the Service Provider to give the Consumer access to the Protected Resources on behalf of the User. If the User denies the Consumer access, the Service Provider MUST NOT allow access to the Protected Resources.

• (8) Service Provider directs the User Back to the Consumer

After the User authenticates with the Service Provider and grants permission for Consumer access, the Consumer MUST be notified that the Request Token has been authorized and ready to be exchanged for an Access Token.

For more details see OAuth Core 1.0 - Obtaining User Authorization

The Consumer exchanges the Request Token for an Access Token

see [1]

Uniform Resource Locator

HyperText Transfer Protocol

Logging-in system for computer networks