Single Sign On

From MPDLMediaWiki
Jump to navigation Jump to search



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 delegates 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.


User wants to print photos using online print shop (in OAuth Consumer). The User logs in the online print shop and says: „Import photos for printing from Flickr“. The user will be redirected to Flickr (in OAuth Service Provider) and has to log in and grant access to the online print shop to his photos. Mostly the access is 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.


  • 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 OAuth Core 1.0

How it works?[edit]

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 allStepFlow.PNG

OAuth Authentication is done in three steps, for more details see OAuth Core 1.0 - Authenticating with OAuth:

The Consumer obtains an unauthorized Request Token[edit]

OAuth Step 1.PNG

(3) Consumer Obtains a Request Token

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

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) Service Provider Issues an Unauthorized Request Token

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[edit]

OAuth Step 2.PNG
  • (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 defines 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[edit]

OAuth Step 3.PNG

The Consumer exchanges the Request Token for an Access Token capable of accessing the Protected Resources.

  • (9) Consumer Requests an Access Token

The Request Token and Token Secret MUST be exchanged for an Access Token and Token Secret. To request an Access Token, the Consumer makes an HTTP request to the Service Provider's Access Token URL.

  • (10) Service Provider Grants an Access Token

If successful, the Service Provider generates an Access Token and Token Secret and returns them in the HTTP response body as defined in Service Provider Response Parameters. The Access Token and Token Secret are stored by the Consumer and used when signing Protected Resources requests.

Fore more details see OAuth Core 1.0 Obtaining an Access Token

Accessing Protected Resources[edit]

OAuth Step 4.PNG

The Access Token is used by the Consumer to access the Protected Resources on behalf of the User.

  • Access Tokens MAY limit access to certain Protected Resources, and MAY have a limited lifetime.
  • Service Providers SHOULD allow Users to revoke Access Tokens.
  • Only the Access Token SHALL be used to access the Protect Resources.

After successfully receiving the Access Token and Token Secret, the Consumer is able to access the Protected Resources on behalf of the User. The request MUST be signed per Signing Requests, and contains the parameters shown in the graphic.

Software Package[edit]

OAuth-Code: These libraries are contributed by members of the community and have not been tested or are necessarily known to work.

Implementation of OAuth are available for following languages:

  • .NET
  • ColdFusion
  • CommonLisp
  • Java
  • JavaScript
  • Ruby
  • PHP
  • Perl
  • Python
  • OCaml
  • Objective-C for Mac developers
  • OAuth Plugin for the Jifty Framework

For more details see OAuth Code


OAuth Core 1.0 Revision A


OAuth code libraries and supporting examples

Beginner’s Guide to OAuth – Part I: Overview

Beginner’s Guide to OAuth – Part II : Protocol Workflow

Beginner’s Guide to OAuth – Part III : Security Architecture

Twitter4J OAuth code example



Shibboleth is standard based, open source software package for web single sign-on across or within organizational boundaries. Shibboleth implements widely used federated identity standards, principally OASIS' Security Assertion Markup Language (SAML), to provide a federated single sign-on and attribute exchange framework.


In the past, universities, companies or government agencies, that offer services and collaborate online, required its own ID and password for each service. Also users typically access both online resources inside or outside their organizations. For the user this workflow meant set of credentials for the applications and for the institution a challenge to close security holes for services and manage access changes.

Shibboleth Single Sign-on and Federating Software was developed specifically to address the challenges of:

  • multiple passwords required for multiple applications
  • scaling the account management of multiple applications
  • security issues associated with accessing third-party services
  • privacy
  • interoperability within and across organizational boundaries
  • enabling institutions to choose their authentication technology (Shibboleth sits on top and provides the web single sign-on functionality)

For more details see Shibboleth About

Shib manageIdentity.PNG

With Shibboleth:

  • the campus manages the authentication of users
  • service providers decide whether the user can acces the resource according to the user attributes

Shibboleth Federation[edit]

A Federation is a group of organisations usually with common purpose (e.g. research and education), who trust one another. Federations operate to a set of agreed rules, some of which will be common to all federations, others may be useful or necessary to be developed locally. Federations can have their own legal status as an organisation in their own right.

A Shibboleth Federation is an agreement between resource (service) providers and institutions (identity providers) wishing to access those resources or services. For sharing to occur, all parties need to agree on a common set of acceptable authorisation attributes for their users, and a schema to describe them.

For using Shibboleth federations are not required. At least one Identity Provider is required for federation. Federation for one - federation with one IdP (e.g. Facebook Connect).

For more information about federations see:

  • DFN-AAI - Authentifikation Autorisierungs Infrastruktur DFN-AAI


  • Identity Provider (IdP) - the software run by an organization with users wishing to access a restricted service; Objectives:
    • Authentication (optional)
      • User Management (optional)
    • Authorisation (mandatory, part of Shibboleth)
      • User Management (optional)
  • Service Provider (SP) - the software run by the provider managing the restricted service.
    • Access Control (expected successful authentication and user attributes)
  • Discovery Service (optional) - List with organization's Identity Provoiders; can be separate service or run by the Service Provider
  • Attributes - the base for authorisation and access control.
    • IdP provides the attributes for the user

How it works?[edit]

Shib workflowMedium.png

User wants to access a Resource. The workflow can be separated in 3 phase:

User connect to Resource and is redirected[edit]

If the user has a valid Shibboleth session, the access to the resource is granted directly. Otherwise the user is redirected to the Discovery Service.

  • (1) When the "resource link" is clikced a HTTP request is send to the site of the Service Provider
  • (2) User is redirected to the WhereAreYouFrom-Service (wayf) and can choose his home organization

This step is not required. In SAML the organization name could be send tranparent for the user.

Authentication request[edit]

  • (3) After choosing the home organization the Discovery Service redirects the user to the session initiator of the resource
  • (4) The session initiator creates an authentication request for the choosen Home Organization and submits it through the users browser to the Home Organization (IdP). (Start here if you know already the address of the IdP of Home Organization.)
  • (5) The Home Organization shows a login page

Authentication and Access[edit]

Besides of login and password other forms of credentials could be used - e.g. hardwaretoken (Smartcard)/password, Softwaretoken (public key)/password, biometric authentication method.

  • (6) The user provides his credentials to the IdP. The credentials are checked and an assertion including the users attributes is created according to the attribute filter rules.
  • (7) The assertion is submitted through the users browser back to the resource. According to the user attributes the authorization is successul or not.

Software Package[edit]

Installation-Packages for IdP, SP and DP can be found at Shibboleht Installation

Supported Operation Systems[edit]

  • Linux
  • Mac OS
  • X–Solaris
  • Windows


Out of date? Shib Specification


Comparison OAuth/Shibboleth[edit]

Characteristic OAuth Shibboleth
user authentication yes - for SP mandatory, app-specific yes - part of IdP, not requiered
user authorisation no - user authorises the SP-app, that can give user data to Consumer yes - SAML-Assertions
federation support no - only pairwise arrangements between apps yes
multiple psw for multimple apps yes - user credentials are hold by each app no
IdP, SP Roles IdP and SP are the same entity IdP authenticate the user and give attributes, SP understand and handle according to attributes
Consumer, SP Roles Consumer wants to access user ressources ot the SP, SP holds user ressources and obtains user's consent for giving the res to Consumer Consumer, SP are IdP, SP at once
API requiered, see Spec no API requiered, just read HTTP-Header or CGI vars
Protocols yes, defined see Spec yes, SAML definies set of protocols
Tokens no, token format not defined yes, token format defined