OpenID Connect - An Emperor or Just New Cloths?

OpenID Connect -
An Emperor Or Just New Cloths?
April 06, 2014
Oliver Pfaff

2April 2014 - All rights reserved
Contents
▶ Hypotheses
▶ OpenID Connect details
▶ Assessing OpenID Connect
– Vs. SAML
– For mobiles
– As RESTful Web services
▶ Conclusions

Hypotheses – To-Be-Checked
▶ Despite its name, OpenID Connect is unrelated to OpenID
▶ It can do the same tricks as SAML
▶ It is a better fit for mobiles
▶ It suites RESTful Web services
▶ It will replace other federated IdM protocols

OpenID Connect Details
Overview
▶ OpenID Connect (short: OIDC) defines an identity layer on top of the OAuth 2.0
authz framework (RFC 6749):
– OAuth allows resource owners to delegate resource access rights to third-
parties in a discretionary fashion with a limited scope (functionality, time)
• Note: this refers to OAuth in its original flavor; various others have been
added over time. Cf. OAuth Base Camp for an overview of these flavors
– OIDC exploits this capability for a specific kind of resources: data specific to
user authn events and user identity
• Ownership is assumed to be with the individual subject whose identifiers/
attributes/credentials are stored in a user repository - not the provider
managing the user repository
▶ Relying parties may obtain from asserting parties:
– Information about user authn from OAuth authz servers i.e. based on explicit
user consent
– Information about user identity from OAuth-protected endpoints
▶ The OIDC specifications are developed by the OIDF. They became OIDF
standards by Feb. 2014

System Entities
▶ User: subject about whom authn event resp. identity data is asserted
– OAuth 2.0 term: resource owner
▶ OIDC server: asserting party – provider of identity data (short: IdP)
– OAuth 2.0 terms: authz server, resource server
▶ OIDC client: relying party - consumer of identity data (short: IdC)
– OAuth 2.0 term: client
User
agent
IdC
IdP
User
User repository
Resources

Extensions to OAuth 2.0
▶ OIDC extends OAuth 2.0 in several respects. The most important extensions are:
– Authn request instructions:
• Allow to request the assertion of information about user authn and identity
– for the current user
• Passed from OIDC clients to OIDC servers (their OAuth authz servers)
– ID token objects:
• Provide information about authn events (e.g. authn context and time)
• Passed from OIDC servers (their OAuth authz servers) to OIDC clients
– UserInfo endpoints:
• OAuth-protected endpoints supplying identity information about
authenticated users
• Provided by OIDC servers, queried by OIDC clients
▶ The functionality defined by OIDC results in an extended OAuth 2.0 authz server
that is part of an OIDC server

Transfer of information
Information Exchange (Code Flow)
User agent
Extended OAuth 2.0 authz server
Get with
access_token
200 OK with30x Redirect with
code
User authn
and consent
dialogues
Authorization
endpoint
30x Redirect
Redirection
endpoint
Token
endpoint
Post with client
creds, code
200 OK with
access_token
Token
client
IdC
IdP
Get data by access_tokenGet data by code
,
id_token
(application/json)
UserInfo
(application/json
or jwt)
OAuth-protected
UserInfo endpoint
UserInfo
client
with authn
request
instructions

Information Exchange (Implicit Flow)
User agent
Get with
access_token
access_token,
id_token
User authn
and consent
dialogues
Authorization
endpoint
30x Redirect
Redirection
endpoint
Token
endpoint
Token
client
IdC
IdP
Get data by access_token
UserInfo
(application/json
or jwt)
OAuth-protected
UserInfo endpoint
UserInfo
client
with authn
request
instructions

Information Exchange (Hybrid Flow)
User agent
Get with
access_token
code, access_token
and/or id_token
User authn
and consent
dialogues
Authorization
endpoint
30x Redirect
Redirection
endpoint
Token
endpoint
Post with client
creds, code
200 OK with
access_token
Token
client
IdC
IdP
Get inputs by access_tokenGet inputs by code
,
or id_token
(application/json)
UserInfo
(application/json
or jwt)
OAuth-protected
UserInfo endpoint
UserInfo
client
with authn
request
instructions

Authn Request Instructions
▶ OIDC defines instructions to request (information about) user authn from
asserting parties
▶ These OIDC authn requests take the form of extended OAuth 2.0 authz requests.
The extensions comprise:
– Added parameters: new (optional) parameters in OAuth 2.0 authz requests
• nonce: means to associate a session an OIDC client maintains for a user
• display: instructions on how to prompt the user for authn/consent
• prompt: instructions on whether to prompt the user for authn/consent
• max_age: maximum authn age
• ui_locales: I18N preferences
• id_token_hint: previously issued ID token
• login_hint: login identifier the user might use to log in
• acr_values: requested authn context class reference values
– Added parameter values: new values for OAuth-defined parameters e.g. the
value openid for the OAuth parameter scope (signalizes the usage of OIDC)
▶ The instructions of OIDC authn requests can be provided in following ways:
– Multiple URL query or post parameters with primitive values
– Single URL query or post parameter with a structured object

Authn Request Samples
▶ Primitive:
GET /authorize?response_type=code&scope=openid profile email&
client_id=s6BhdRkqt3&state=af0ifjsldkj&
redirect_uri=https://idc.example/callback&
prompt=login HTTP/1.1
Host: idp.example
▶ Structured:
GET /authorize?response_type=code&scope=openid&
client_id=s6BhdRkqt3&state=af0ifjsldkj&
redirect_uri=https://idc.example/callback&
request={…} HTTP/1.1
Host: idp.example
▶ Remarks:
– OIDC clients trigger such requests by sending HTTP 30x redirection responses
with Location headers (referring to the OAuth authz endpoint of an OIDC
server) to user agents
– OIDC-defined extensions to OAuth 2.0 authz requests are highlighted (bold)
– URL encoding was stripped to improve readability

Request Objects
▶ OIDC Request objects allow OIDC clients to express authn request instructions
in form of a structured object that is passed (by-value or by-reference) to an
OIDC server:
– These objects are represented as JWT. They may be signed (JWS) and/or
encrypted (JWE)
– They are optional and are provided as value of the OIDC-defined URL
parameter request in OIDC authn requests
▶ Besides supporting cryptographic protection, the Request object allows to
request claims in a refined way. Its claims member comprises following child
members:
– userinfo: instructs on values to-be-returned by UserInfo endpoints
– id_token: instructs on values to-be-provided in ID token objects

Request Sample (Claims Set Section Only)
{
"response_type": "code",
"client_id": "s6BhdRkqt3",
"redirect_uri": "https://idc.example/callback",
"scope": "openid",
"nonce": "af0ifjsldkj",
"max_age": 86400,
"claims": {
"userinfo": {
"name": {"essential": true},
"email": null,
"email_verified": null,
"picture": null
},
"id_token": {
"auth_time": {"essential": true},
"acr": { "values":["urn:idp.example:loa:nist-800-63:3"] }
}
}
}
Code flow:
requests OAuth
authz code supply

ID Token Objects
▶ OIDC ID token objects are represented as JWT. They are produced by OIDC
servers (their OAuth 2.0 authz servers) and consumed by OIDC clients:
– Code flow: ID token objects are provided in response to OAuth token requests
– Implicit flow: ID token objects are provided in response to OIDC authn
requests. ID token must be signed (JWS)
– Hybrid flow: ID token supply is subject to instructions provided in the request
▶ Provide information about the event of user authn:
– iss: authn authority issuing the token
– sub: subject identifier
– aud: intended token audience
– exp: token expiration time
– iat: token issuance time
– auth_time: time of authn event
– nonce: means to associate a session an OIDC client maintains for a user
– acr (opt.): authn context references
– amr (opt.): authn method references
– azp (opt.): authorized party

ID Token Sample
{
"typ":"JWT",
"alg":"HS256"
}
{
"iss": "https://idp.example",
“sub": “0123456789",
"aud": "s6BhdRkqt3",
"exp": "1320502962",
"iat": "1320501962",
"auth_time": "1320501351“,
"acr": "urn:idp.example:loa:nist-800-63:3"
}
{
Nn8TT52nyZ8dYyMefXOav4ywU6Zr8qwUnWzZjcCrlgc
}
Header
Claims set
Checksum

UserInfo Endpoints
▶ OIDC UserInfo endpoints are OAuth-protected i.e. OAuth access tokens must be
presented by callers
– OIDC supports bearer tokens (RFC 6750) passed via HTTP authn headers, URL
query parameters or as post parameters
▶ UserInfo endpoints do not depend on explicit input parameters:
– They rely on OAuth access tokens which provide a reference for the identity
data of an authenticated user that is to-be-released under user consent
– Instructions on to-be-supplied identity information are provided as structured
objects (OIDC Request objects) or in a primitive way (OIDC-defined authn
request parameters)
▶ They return identity data in form of JSON (plain data) or JWT (signed and/or
encrypted data) objects and distinguish:
– Normal claims: identity data which is returned from a UserInfo endpoint of
an IdP and that is asserted by this IdP
– Aggregated claims: identity data returned from a UserInfo endpoint of an
IdP but that is asserted by another IdP (by-value, included as JWT)
– Distributed claims: as for aggregated claims but the identity data of the
other IdP is provided by-reference: an IdC needs to query the provided OAuth
resource endpoint to obtain the actual values (supplied as JWT)

UserInfo Request/Response Sample
▶ Request:
GET /userinfo HTTP/1.1
Host: idp.example
Authorization: Bearer QaY2WSx3eDC
▶ Response:
HTTP/1.1 200 OK
Content-Type: application/json
{
"sub": “0123456789",
"name": "John Doe“,
"email": "john.doe@idp.example",
"email_verified": true,
"picture": "http://idp.example/johndoe/johndoe.jpg"
}

Further OAuth 2.0 Utilization/Extensions
▶ Exchanges: OIDC supports the code, implicit and hybrid flow. This allows OIDC
clients to obtain ID token objects in response to OIDC authn or OAuth token
requests:
– For pure federated login/SSO scenarios (without a need to fetch further identity
data) it is sufficient to consume ID token objects
– To obtain further identity information, OIDC clients query UserInfo services
▶ IdP discovery: OIDC specifies a means of IdP discovery by querying a service
based on user-supplied identifiers e.g. email addresses. This mechanism uses
WebFinger (RFC 7033)
▶ IdP metadata lookup: OIDC specifies how clients may lookup metadata
concerning the configuration of a OIDC server
▶ IdC registration/configuration: OIDC specifies endpoints to dynamically
register as a client to an OIDC server as well as to manage this client registration

Assessing OpenID Connect - Vs. SAML
SAML Reminder
▶ SAML defines:
– XML syntaxes to express facts about
subjects as well as to request/supply
such assertions
– Prefabricated courses of action based
on standard protocols (HTTP, SOAP)
▶ The SAML specifications support various
use cases in federated IdM:
– SSO: transfer the representation of a
subject authenticated at an asserting
party to a relying party
– Assertion query: provide
supplementary information about an
authenticated subject
– ID management/mapping: manage/
map long-lived identifiers sustained by
asserting and relying parties
– SLO: terminate sessions established
through SSO

Use Cases Considered for Benchmarking
▶ SSO: considered in the following
▶ Assertion query: considered in the following
▶ ID management/mapping: not considered
– This use case is not addressed by OIDC
▶ SLO: not considered
– OIDC comprises a session management specification. This document is not
yet final. For this reason this use case is not considered for benchmarking
OIDC against SAML

SSO Use Case Details
▶ SAML support for the SSO use case needs to be distinguished into:
– SP-initiated SSO: 3-party (SP, user agent, IdP) samlp:AuthnRequest/
Response exchange traversing user agents via HTTP
– IdP-initiated SSO: 3-party (IdP, user agent, SP) -/samlp:Response exchange
traversing user agents via HTTP
– Proxying: generalizes the 3-party exchanges to n-party exchanges between an
SP and multiple IdPs
– With artifact: supplementary 2-party (SP, IdP) SOAP-based exchange
▶ OIDC coverage:
– SP-initiated SSO: supported
• Request objects correspond samlp:AuthnRequest
• ID token objects correspond saml:Assertion in samlp:Response
– IdP-initiated SSO: not supported
– Proxying: not yet addressed
– With artifact: supported
• Request objects in OIDC authn requests can be referred to by URIs
• ID token objects can be pulled from OAuth token endpoints (referred to by
OAuth codes)

SSO Use Case Benchmark
▶ Status: following SSO exchanges do match:
– SAML: samlp:AuthnRequest/Response via HTTP Redirect/Artifact and
Redirect/POST bindings
– OIDC: Request/ID token via code and implicit flows
▶ Advantages:
– Native support for user consent (inherited from OAuth)
– Support of claims-based IdM i.e. relying parties can deliberately ask for identity
information they depend on:
• The Request object is capable of expressing instructions on to-be-provided
attributes and further information (aka claims)
• The samlp:AuthnRequest does not define how to express such requirements
▶ Limitations:
– OIDC does not address proxying i.e. multiple IdPs that collectively make
assertions about a subject

Assertion Query Use Case Details
▶ SAML addresses this use case by means of 2-party, SOAP-based exchanges
between SPs and IdPs. They allow the acquisition of:
– Authn information: query (supplementary information about) the authn
state of a subject
– Attribute information: query attributes of a subject
– Authz decision information: query authorizations of a subject
▶ OIDC coverage:
– Authn information: not fully supported
• As 2-party (IdC, IdP) exchanges: not supported
• As 3-party (IdC, user agent, IdP) exchanges: supported by submitting OIDC
authn requests with the directive prompt=none and adequate acr_values
– Attribute information: supported
• The userinfo member in Request objects (sent to the OAuth authz
endpoint at the IdP) corresponds samlp:AttributeQuery
• The UserInfo endpoint response contents corresponds the attribute
information in saml:Assertion in samlp:Response
– Authz decision information: not supported

Assertion Query Use Case Benchmark
▶ Status: following query exchanges do functionally match:
– SAML: samlp:AttributeQuery/Response via SOAP binding
– OIDC: UserInfo request/response via HTTP (required claims specified
through OIDC authn requests)
▶ Advantages:
– Native support for user consent (inherited from OAuth)
– Capability to present identity data from multiple sources (aggregated/
distributed claims in OIDC)
▶ Limitations:
– OIDC does not address the querying of authn information (in form of 2-party
exchanges directly between IdCs and IdPs) and as well as authz decision
information

Overall Benchmarking
▶ Original use case:
– SAML: cross-organization Web SSO according an IAM mindset where the
asserting party does assume ownership of identity data
– OIDC: cross-organization Web SSO according an IAM mindset where the
asserting party does not assume ownership of identity data
▶ Software complexity:
– SAML: asserting and relying parties are equally complex
– OIDC: asserting parties are complex (OIDC IdP complexity matches SAML IdP
complexity), relying parties are lightweight
▶ User-orientation:
– SAML: explicit user consent is feasible but not commonly deployed
– OIDC: explicit user consent is mandatory
▶ Federation agility:
– SAML: associations between asserting and relying parties are established in a
ceremonial way – requiring manual administration (user consent is not
mandatory and absent by default)
– OIDC: associations between asserting and relying parties are established
automatically (exploits the mandatory user consent)

Assessment OpenID Connect – For Mobiles
Network Transfer Overhead
▶ Representing identity information for network transfer adds overhead
▶ The amount of overhead varies with the chosen object syntax:
– SAML: saml:Assertion objects aim at optimizing expressiveness
– OIDC: JSON Web tokens aim at reducing size. They can represent the same
raw information - assume some 60-70 bytes as an example - more compact:
• ID token representation requires ca. 450 bytes (RSA-1024-SHA-256 without
X.509 certificates)
• saml:Assertion representation requires ca. 2500 bytes (with RSA-1024-
SHA-1 checksum, without X.509 certificates) for the same raw information
▶ The amount of representation overhead also depends on various other factors:
– OIDC: cryptographic checksum (symmetric or asymmetric), keying information
(implicit, by-reference, by-content)
– SAML: as above plus style of attribute supply (via SAML SSO or attribute
exchanges), SAML attribute profile and naming, XML namespace handling
▶ However, the SAML message size handicap can be avoided/mitigated by
choosing the artifact profile for supplying the saml:Assertion objects

Assessment OpenID Connect – For Mobiles
Further SSO User Experiences
▶ Up to now server-side SSO was considered:
– A user uses a single user agent e.g. Web browser to access multiple applications
– A single login shall allow access to these applications in the network
– OIDC as well as SAML facilitate server-side SSO - in particular when the network
applications belong to different Web domains (*.mycompany.com and
*.mysubsidary.com) or organizations (*.mycompany.com and *.yourcorp.net)
▶ Other SSO user experiences that are relevant for mobiles comprise:
– Persisted login:
• A user uses a single user agent on a device (mobile app on a tablet/smart-
phone) to access a specific Web application e.g. Gmail
• A single login shall allow access to this application over time - user agent
or device stop/restart shall not require the user to (explicitly) login again
– Client-side SSO:
• A user uses multiple user agents on a device (e.g. various mobile apps on a
tablet/smart-phone) to access a specific provider e.g. Google
• A single login shall allow access to this provider from various user
agents
– OAuth allows to facilitate persisted login and client-side SSO. Such SSO tricks
are beyond the scope of SAML

Assessing OpenID Connect – As RESTful Web Services
RESTful Identity and Access Management
▶ OIDC supports RESTful Web services by relying on HTTP (not SOAP or WS-*) for
communications and JSON (instead HTML or XML) for exchanging data objects
▶ OIDC uses and extends following endpoints defined by OAuth 2.0 (RFC 6749):
– Authz endpoint: endpoint that establishes user authn and consent
• OIDC extensions: parameters and parameter values
– Token endpoint: endpoint to fetch tokens
• OIDC extensions: ID token objects
▶ OIDC defines following OAuth-protected endpoint in REST style:
– UserInfo endpoint (opt.): endpoint to query identity data
– Registration/configuration endpoint (opt.): endpoints to register OIDC
clients and manage their configuration
– EndSession endpoint (opt.): endpoint to request that the current user shall be
logged-off at the IdP
▶ The Authz and EndSession endpoints employ 3-party exchanges between IdCs,
user agents and IdPs
▶ The Token/UserInfo/Registration/Configuration endpoints employ 2-party
exchanges between IdCs and IdPs

Conclusions
Checking the Hypotheses
▶ Despite its name, OIDC is unrelated to OpenID
– Easy: OIDC is closely related to OAuth - it turns solution for the delegation use
case into an approach for the federation use case. It’s relation to the original
OpenID specifications (OpenID 1.x and 2.0 protocols) is loose
▶ It can do the same tricks as SAML
– Almost: covers the mainline use cases in federated IdM – based on another
syntax and with native support for user consent and claims-based IdM
▶ It is a better fit for mobiles
– Clearly: replacing XML by JSON allows to reduce federated IdM protocol
overhead. But SAML allows optimizations to suit mobile user agents. On the
other hand, OAuth-based systems facilitate use cases not addressed by SAML
▶ It suites RESTful Web services
– Depends: differences diminish with a lax interpretation of ‘RESTful’. For an
orthodox interpretation it’s a yes - SAML is not a real match for them
▶ It will replace other federated IdM protocols
– Hmmm: OIDC deployments are emerging. Adaptation should be expected to
start in environments where other approaches are no good fit. This gives room
for coexistence

Abbreviations
Authn Authentication
Authz Authorization
I18N Internationalization
IAM Identity and Access
Management
ID Identity
IdC Identity Consumer
IdM Identity Management
IdP Identity Provider (aka OP
in OIDC)
JSON JavaScript Object Notation
JWA/E/K/S/T JSON Web Algorithms/
Encryption/Key/Signature/
Token
OAuth Open Authorization
OID OpenID
OIDC OpenID Connect
OIDF OpenID Foundation
OP OpenID Provider (aka IdP
in SAML)
REST REpresentational State
Transfer
RP Relying Party (aka SP in
SAML)
SAML Security Assertion
Markup Language
saml: Namespace prefix for
SAML assertion syntax
samlp: Namespace prefix for
SAML protocol syntax
SOAP Simple Object Access
Protocol
SP Service Provider (aka RP
in OIDC)
SSO Single-Sign-On
SLO Single Logout
WS Web Services

Further Information
▶ Home: http://openid.net/connect
▶ Specifications:
– OIDC specifications:
• Core - final
• Discovery - final, optional
• Dynamic Client Registration - final, optional
• Session Management - draft, optional
– OAuth additions specified by OIDC:
• OAuth 2.0 Multiple Response Types - final
• OAuth 2.0 Form Post Response Mode - draft, optional
– Additional OIDC deliverables:
• Basic Client Implementer’s Guide – draft, optional
• Implicit Client Implementer’s Guide – draft, optional
▶ Utilities:
– Demo (with Google as IdP): http://www8322u.sakura.ne.jp/oidconnect/
– JWT tool: http://openidtest.uninett.no/jwt

Author
▶ oliver.frank.pfaff@gmail.com

OpenID Connect - An Emperor or Just New Cloths?

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to OpenID Connect - An Emperor or Just New Cloths?

Similar to OpenID Connect - An Emperor or Just New Cloths? (20)

More from Oliver Pfaff

More from Oliver Pfaff (17)

Recently uploaded

Recently uploaded (20)

OpenID Connect - An Emperor or Just New Cloths?