OpenID Connect cast of characters

Introduction

The OpenID Connect protocol provides support for both delegated authorization and federated authentication, unifying features that traditionally were provided by distinct protocols. As a consequence, the OpenID Connect protocol parties play multiple roles at the same time, which can sometimes be hard to grasp. This document, originally published as a post on https://blog.pedrofelix.org/2016/06/06/the-openid-connect-cast-of-characters/ aims to clarify this, describing how the OpenID Connect parties related to each other and to the equivalent parties in previous protocols, namely OAuth 2.0.

OAuth 2.0

The OAuth 2.0 authorization framework introduced a new set of characters into the distributed access control story.

• The User (aka Resource Owner) is a human with the capability to authorize access to a set of protected resources (e.g. the user is the resources owner).
• The Resource Server is the HTTP server exposing access to the protected resources via an HTTP API. This access is dependent on the presence and validation of access tokens in the HTTP request.
• The Client Application is the an HTTP client that accesses user resources on the Resource Server. To perform these accesses, the client application needs to obtain access tokens issued by the Authorization Server.
• The Authorization Server is the party issuing the access tokens used by the Clients Application on the requests to the Resource Server.
• Access Tokens are strings created by the Authorization Server and targeted to the Resource Server. They are opaque to the Client Application, which just obtains them from the Authorization Server and uses them on the Resource Server without any further processing.

To make things a little bit more concrete, leet’s look at an example

• The User is Alice and the protected resources are her repositories at GitHub.
• The Resource Server is GitHub’s API.
• The Client Application is a third-party application, such as Huboard or Travis CI, that needs to access Alice’s repositories.
• The Authorization Server is also GitHub, providing the OAuth 2.0 protocol “endpoints” for the client application to obtain the access tokens.

OAuth 2.0 models the Resource Server and the Authorisation Server as two distinct parties, however they can be run by the same organization (GitHub, in the previous example).

An important characteristics to emphasise is that the access token does not directly provide any information about the User to the Client Application - it simply provides access to a set of protected resources. The fact that some of these protected resources may be used to provide information about the User’s identity is out of scope of OAuth 2.0.

Delegated Authentication and Identity Federation

However delegated authentication and identity federation protocols, such as the SAML protocols or the WS-Federation protocol, use a different terminology.

• The Relying Party (or Service Provider in the SAML protocol terminology) is typically a Web application that delegates user authentication into an external Identity Provider.
• The Identity Provider is the entity authenticating the user and communicating her identity claims to the Relying Party.
• The identity claims communication between these two parties is made via identity tokens, which are protected containers for identity claims
  • The Identity Provider creates the identity token.
  • The Relying Party consumes the identity token by validating it and using the contained identity claims.

Sometimes the same entity can play both roles. For instance, an Identity Provider can re-delegate the authentication process to another Identity Provider. For instance:

• An Organisational Web application (e.g. order management) delegates the user authentication process to the Organisational Identity Provider.
• However, this Organisational Identity Provider re-delegate user authentication into a Partner Identity Provider.
• In this case, the Organisational Identity Provider is simultaneously
  • A Relying Party for the authentication made by the Partner Identity Provider.
  • An Identity Provider, providing identity claims to the Organisational Web Application.

In these protocols, the main goal of the identity token is to provide identity information about the User to the Relying Party. Namely, the identity token is not aimed to provide access to a set of protected resources. This characteristic sharply contrasts with OAuth 2.0 access tokens.

OpenID Connect

The OpenID Connect protocol is “a simple identity layer on top of the OAuth 2.0 protocol”, providing both delegated authorisation as well as authentication delegation and identity federation. It unifies in a single protocol the functionalities that previously were provided by distinct protocols. As consequence, now there are multiple parties that play more than one role

• The OpenID Provider (new term introduced by the OpenID Connect specification) is an Identity Provider and an Authorization Server, simultaneouslyissuing identity tokens and access tokens.
• The Relying Party is also a Client Application. It receives both identity tokens and access tokens from the OpenID Provider. However, there is a significant different in how these tokens are used by this party
  • The identity tokens are consumed by the Relying Party/Client Application to obtain the user’s identity.
  • The access tokens are not directly consumed by the Relying Party. Instead they are attached to requests made to the Resource Server, without ever being opened at the Relying Party.