OpenID Connect - An Emperor or Just New Cloths?

  • 8,295 views
Uploaded on

Update - reflects the final OpenID Connect 1.0 specifications (OpenID Foundation standards) now

Update - reflects the final OpenID Connect 1.0 specifications (OpenID Foundation standards) now

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
8,295
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
0
Comments
0
Likes
13

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. OpenID Connect - An Emperor Or Just New Cloths? April 06, 2014 Oliver Pfaff
  • 2. 2April 2014 - All rights reserved Contents ▶ Hypotheses ▶ OpenID Connect details ▶ Assessing OpenID Connect – Vs. SAML – For mobiles – As RESTful Web services ▶ Conclusions
  • 3. 3April 2014 - All rights reserved 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
  • 4. 4April 2014 - All rights reserved 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
  • 5. 5April 2014 - All rights reserved OpenID Connect Details 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
  • 6. 6April 2014 - All rights reserved OpenID Connect Details 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
  • 7. 7April 2014 - All rights reserved Transfer of information OpenID Connect Details 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
  • 8. 8April 2014 - All rights reserved Transfer of information OpenID Connect Details Information Exchange (Implicit Flow) User agent Extended OAuth 2.0 authz server Get with access_token 200 OK with30x Redirect with 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
  • 9. 9April 2014 - All rights reserved Transfer of information OpenID Connect Details Information Exchange (Hybrid Flow) User agent Extended OAuth 2.0 authz server Get with access_token 200 OK with30x Redirect with 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
  • 10. 10April 2014 - All rights reserved OpenID Connect Details 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
  • 11. 11April 2014 - All rights reserved OpenID Connect Details 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
  • 12. 12April 2014 - All rights reserved OpenID Connect Details 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
  • 13. 13April 2014 - All rights reserved OpenID Connect Details 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
  • 14. 14April 2014 - All rights reserved OpenID Connect Details 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
  • 15. 15April 2014 - All rights reserved OpenID Connect Details 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
  • 16. 16April 2014 - All rights reserved OpenID Connect Details 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)
  • 17. 17April 2014 - All rights reserved OpenID Connect Details 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" }
  • 18. 18April 2014 - All rights reserved OpenID Connect Details 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
  • 19. 19April 2014 - All rights reserved 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
  • 20. 20April 2014 - All rights reserved Assessing OpenID Connect - Vs. SAML 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
  • 21. 21April 2014 - All rights reserved Assessing OpenID Connect - Vs. 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)
  • 22. 22April 2014 - All rights reserved Assessing OpenID Connect - Vs. SAML 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
  • 23. 23April 2014 - All rights reserved Assessing OpenID Connect - Vs. SAML 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
  • 24. 24April 2014 - All rights reserved Assessing OpenID Connect - Vs. SAML 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
  • 25. 25April 2014 - All rights reserved Assessing OpenID Connect - Vs. SAML 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)
  • 26. 26April 2014 - All rights reserved 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
  • 27. 27April 2014 - All rights reserved 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
  • 28. 28April 2014 - All rights reserved 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
  • 29. 29April 2014 - All rights reserved 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
  • 30. 30April 2014 - All rights reserved 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
  • 31. 31April 2014 - All rights reserved 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
  • 32. 32April 2014 - All rights reserved Author ▶ oliver.frank.pfaff@gmail.com