OpenID Connect - An Emperor or Just New Cloths?

OpenID Connect -An Emperor Or Just New Cloths? October 14, 2012 Oliver Pfaff

Hypotheses –To-Be-Checked in the Following▶ 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 protocolsOct. 2012 - All rights reserved 3

OpenID Connect DetailsOverview▶ OpenID Connect (short: OIDC) defines an identity layer on top of the OAuth 2.0 authorization 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). • Cf. Analyzing OAuth for an overview of OAuth – OIDC exploits this capability for a specific kind of resources: data specific to authentication events and user identity esp. data contained in user accounts. • Ownership is assumed to be with the individual subject whose identifiers/ attributes/credentials are contained in a user account (not the legal entity managing the user repository).▶ OIDC clients can verify the identity of end-users based on an authentication performed against OAuth authz servers and obtain information about user identity from OAuth-protected service endpoints.▶ The OIDC specifications are developed by the OIDF.Oct. 2012 - All rights reserved 4

OpenID Connect DetailsSystem Entities▶ User: subject about whom 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 (role: intermediary) IdC Resources User User agent IdP User repositoryOct. 2012 - All rights reserved 5

OpenID Connect DetailsExtensions to OAuth 2.0▶ OIDC extends OAuth 2.0 in several respects. The most important extensions are: – UserInfo endpoints: • OAuth-protected endpoints supplying identity information about authenticated users • Provided by OIDC servers, queried by OIDC clients – ID token objects: • Provide information about authentication events (e.g. authentication context and time) • Passed from OAuth authz servers to OIDC clients – Request objects: • Allow to request the assertion of e.g. certain user attributes • Passed from OIDC clients to OAuth authz endpoints▶ The OIDC-defined ID token and Request objects result in an extended OAuth authz server that is part of an OIDC serverOct. 2012 - All rights reserved 6

OpenID Connect DetailsProtocol Workflow (Code Flow)2. Authn as user and delegate access User 1. Redirect user agent to IdP rights to the IdC (OAuth authz endpoint), agent opt. provide oidc:Request object 4. Redirect user agent to IdC with oauth:Grant IdP Extended authz UserInfo3. Store entitlement server endpoints endpoint6. Respond with 9. Respond with user info oauth:AccessToken, oidc:IdToken5. Authn with client 8. Authn with credentials, supply oauth:AccessToken, oauth:Grant, request request user info oauth:AccessToken, oidc:IdToken IdC7. Consume oidc:IdToken 10. Process user info Oct. 2012 - All rights reserved 7

OpenID Connect Details Information Exchange (Code Flow) Extended OAuth 2.0 authz server IdP OIDC Authz Token UserInfo endpoint endpoint endpointUseragent API authn Access API authn (client-id, token, (access UserInfo secret), grant ID token token) Scope, Grant (Request) IdC Authz Token UserInfo endpoint endpoint endpoint client client client Oct. 2012 - All rights reserved 8

OpenID Connect DetailsUserInfo Endpoints▶ OIDC UserInfo endpoints are OAuth-protected i.e. OAuth access token objects must be presented by callers. – OIDC supports bearer tokens (RFC 6750) passed via HTTP authn headers, form controls or URL query parameters▶ These 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 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 values for the OAuth URL parameter scope)▶ They return identity data with media-type application/json 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).Oct. 2012 - All rights reserved 9

OpenID Connect DetailsUserInfo Request/Response Sample▶ Request: GET /userinfo?schema=openid HTTP/1.1 Host: idp.example Authorization: Bearer eyJ0e(…).eyJpc(…).dBjft(…)▶ Response: HTTP/1.1 200 OK Content-Type: application/json { "user_id": “0123456789", "name": "John Doe" "email": "john.doe@idp.example", "email_verified": true, "picture": "http://idp.example/johndoe/johndoe.jpg" }Oct. 2012 - All rights reserved 10

OpenID Connect DetailsID Token Objects▶ OIDC ID token objects are represented as JWT, produced by OIDC servers (their OAuth 2.0 authorization servers) and consumed by OIDC clients: – Code flow: provided in response to OAuth token requests – Implicit flow: provided in response to extended OAuth 2.0 authorization requests. ID token must be signed (JWS)▶ Represent information about the authentication event scoped to the OIDC client: – iss: issuing authentication authority – user_id: user identifier – aud: intended audience – exp: expiration time – iat: issuance time – nonce (opt., required for implicit flow): means to associate a session an OIDC client maintains with a user agent – at_hash (opt., required for implicit flow): OAuth access token hash – c_hash (opt., required for implicit flow): OAuth authz code hash – acr (opt.): authentication context reference – auth_time (opt.): time of authentication eventOct. 2012 - All rights reserved 11

OpenID Connect DetailsID Token Sample{ "typ":"JWT", Header "alg":"HS256"}{ "iss": "https://idp.example/oauthAuthzServer", "user_id": “0123456789", "aud": "s6BhdRkqt3", Claims set "exp": "1320502962", "iat": "1320501962", "acr": "1", "auth_time": "1320501351"}{ Checksum Nn8TT52nyZ8dYyMefXOav4ywU6Zr8qwUnWzZjcCrlgc}Oct. 2012 - All rights reserved 12

OpenID Connect DetailsRequest Objects▶ OIDC Request objects are represented as JWT, produced by OIDC clients and consumed by OIDC servers (their OAuth 2.0 authorization endpoints) – Present optional objects that may be provided as value of request URL parameters in extended OAuth 2.0 authorization requests – Must be signed (JWS) and may be encrypted (JWE)▶ Extend OpenID Request objects by following members: – userinfo: instructs on values to-be-returned by UserInfo endpoints: • claims: set of claims requested from UserInfo endpoints. • preferred_locales: list of preferred languages – id_token: instructs on values to-be-provided in ID token objects. It’s content inherits the structure from the userinfo member and adds: • For the claims section following optional claims are highlighted: o user_id: the user identifier for which an ID token is being requested. o auth_time: requests the imprinting of the auth_time into the ID token o acr: requests the desired authentication context classes • max_age: requires that the user must be actively authenticated if any present authentication is older than specified.Oct. 2012 - All rights reserved 13

OpenID Connect DetailsRequest Sample (Only Claims Set Section Shown){ "response_type": "code", Code flow: "client_id": "s6BhdRkqt3", requests OAuth "redirect_uri": "https://idc.example/callback", authz code and ID token supply "scope": "openid profile", "nonce": "af0ifjsldkj", via OAuth token "userinfo": { endpoint "claims": { "name": {"essential": true}, "email": null, "email_verified": null, "picture": null } }, "id_token": { "claims": { "auth_time": {"essential": true}, "acr": { "values":["1"] } } "max_age": 86400, }}Oct. 2012 - All rights reserved 14

OpenID Connect DetailsFurther OAuth 2.0 Utilization/Extensions▶ Flows: OIDC supports the authorization code and implicit flows. This allows OIDC clients to obtain ID token objects from extended OAuth token endpoints or in response to OAuth authz requests: – For pure federated login/SSO scenarios (without a need to fetch further identity data) it is sufficient to consume ID token objects – For further identity information, OIDC clients query UserInfo services▶ Parameters: OIDC extends OAuth 2.0 parameters and esp. defines prompt and display parameters to supply visual appearance instructions to IdPs.▶ Server discovery: OIDC specifies a means of IdP discovery by querying a service based on user-supplied identifiers (e.g. email addresses). This mechanism uses SWD.▶ Server configuration: OIDC specifies an endpoint to lookup metadata concerning the configuration of extended OAuth 2.0 authz servers▶ Client registration: OIDC specifies an endpoint to dynamically register as an extended OAuth 2.0 client to an authz serverOct. 2012 - All rights reserved 15

Assessing - Vs. SAMLSAML Reminder ▶ SAML defines: – XML syntaxes to express facts about subjects and to request/supply them – 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 – Single logout: terminates sessions established through SSOOct. 2012 - All rights reserved 16

Assessing - Vs. SAMLBenchmarked Use Cases ▶ SSO: considered in the following ▶ Assertion query: considered in the following ▶ ID management/mapping: not considered – This use case is not addressed by OIDC ▶ Single logout: not considered – OIDC comprises a session management specification. This document appears to be in an early stage right now. For this reason this use case is not considered for benchmarking OIDC against SAML.Oct. 2012 - All rights reserved 17

Assessing - Vs. SAMLSSO Use Case Details▶ SAML support for this use case needs to be distinguished into: – SP-initiated SSO: 3-party, HTTP-based samlp:AuthnRequest/Response exchange via user agents – IdP-initiated SSO: 3-party, HTTP-based -/samlp:Response exchange via user agents – Proxying: generalizes the 3-party exchanges to n-party exchanges between an SP and multiple IdPs via user agent – With artifact: supplementary 2-party, SOAP-based exchange▶ OIDC coverage for this use case: – SP-initiated: supported • The id_token member in Request objects corresponds samlp:AuthnRequest • The ID token object corresponds saml:Assertion in samlp:Response – IdP-initiated: not supported – Proxying: not yet addressed – With artifact: supported • Request objects can be referred to by URIs in extended OAuth authz requests • ID token objects can be obtained from OAuth token endpoints.Oct. 2012 - All rights reserved 18

Assessing - Vs. SAMLSSO Use Case Benchmark▶ Status: following SSO exchanges do functionally match: – SAML: samlp:AuthnRequest/Response via HTTP Redirect/POST binding and their artifact-style alternatives – OIDC: Request/ID token via HTTP redirects and their artifact-style alternatives▶ Advantages: – Native support for user consent (inherited from OAuth) – Support of claims-based IdM i.e. consumers of identity data that deliberately ask for the identity information they depend on: • The userinfo member in Request objects is capable of expressing instructions on to-be-provided attributes and further information (aka claims) • This goes beyond SAML as samlp:AuthnRequest does not define how to express such requirements – SAML does not specify an equivalent to the implicit flow for relying parties that are provided as user agent-based or native applications▶ Limitations: – OIDC does not provide details on the actual authentication method and does not express requirements or state with respect to multiple means of authenticationOct. 2012 - All rights reserved 19

Assessing - Vs. SAMLAssertion 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: – Authentication information: query authentication state of a subject – Attribute information: query attributes of a subject – Authorization decision information: query authorizations of a subject▶ OIDC coverage for this use case: – Authentication information: not supported – 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 – Authorization decision information: not supportedOct. 2012 - All rights reserved 20

Assessing - Vs. SAMLAssertion 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 extended OAuth authz requests)▶ Advantages: – Native support for user consent (inherited from OAuth) – Capability to present identity data from multiple sources (aggregated/ distributed claims in OIDC)▶ Limitations: – Support for querying attribute information is limited to (an equivalent of) the SAML basic attribute profile: besides some predefined, reserved claim names definition of attributes resp. claims is left to mutual agreements between IdCs and IdPsOct. 2012 - All rights reserved 21

Assessing - Vs. SAMLOverall Benchmarking▶ Origin: – SAML: enterprise IAM – OIDC: Internet/consumer IAM▶ Native use case: – SAML: SSO – OIDC: delegation of resource access authorization (as an OAuth 2.0 extension)▶ Complexity: – SAML: asserting and relying parties are equally complex, user agents are tunneled – OIDC: asserting parties are complex (OIDC IdP complexity matches SAML IdP complexity), relying parties are lightweight, user agents are tunneled▶ Agility: – SAML: ceremonial setup – OIDC: self-registering as relying party▶ User-orientation: – SAML: transparent; user agents need to support login dialogues – OIDC: explicit user consent; user agents need to support login and consent dialoguesOct. 2012 - All rights reserved 22

Assessment – MobilesNetwork 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 service), SAML attribute profile and naming, XML namespace handling▶ The extent to which these overheads affect mobile user agents depends on the chosen message exchange style (next slide).Oct. 2012 - All rights reserved 23

Assessment – MobilesProtocol Messages Passing User Agents▶ OIDC code flow (as described in the basic client profile of OIDC): – ID token acquisition: corresponds saml:Assertion acquisition via HTTP Redirect/Artifact binding – UserInfo exchange: corresponds saml:Assertion acquisition via SOAP binding – Following message objects pass through user agents: • OIDC: extended OAuth authz request/response with authz code • SAML: samlp:AuthnRequest (by-content), samlp:Response (by-indirection)  The SAML message size handicap does not apply▶ OIDC implicit flow (as described in the implicit client profile of OIDC): – ID token acquisition: corresponds saml:Assertion acquisition via HTTP Redirect/POST binding – UserInfo exchange: as for the code flow – Following message objects pass through user agents: • OIDC: extended OAuth authz request/response with access and ID token • SAML: samlp:AuthnRequest/Response (by-content)  The SAML message size handicap applies (but SAML deployments are free to choose a SSO message exchange style that corresponds the OIDC code flow).Oct. 2012 - All rights reserved 24

Assessment – MobilesYet Another SSO Trick▶ Up to now the usual SSO trick in following setup was considered: – User agents reside on mobiles, asserting and relying parties in the network – For this setup, SAML allows configurations that result in about the same footprint for mobile user agents as OIDC▶ OAuth (implicit flow) facilitates also SSO tricks in other setups: – Assign the relying party role to end-user apps on mobile devices – This allows to provide following functionality: • OAuth: clients may transparently access (arbitrary) OAuth-protected services on behalf of a user - subject to access tokens assigned to them • OIDC: dito for the case of the UserInfo service – This requires to implement OAuth/OIDC protocol endpoints for the client-side in such apps. This is eased by the fact that relying parties in OAuth/OIDC are lightweight (compared to asserting parties).▶ Since SSO in absence of the actual user is a critical feature, such tricks have to be utilized with care.Oct. 2012 - All rights reserved 25

Assessment – MobilesUse Cases Beyond SSO▶ Due to the OAuth heritage, use cases beyond SSO and supply of identity data can also be addressed in federated IdM systems that are based on OAuth/OIDC.▶ As such functionality is to be attributed to OAuth rather than OIDC, they are not considered here.Oct. 2012 - All rights reserved 26

Assessing - RESTful Web ServicesRESTful 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 relies on and extends following OAuth-defined endpoints: – Authorization endpoint: user-authn protected endpoint to perform user authentication and conduct user consent. • Extended by OIDC: OIDC-defined request parameters esp. Request objects – Token endpoint: client-authn protected endpoint to fetch tokens. • Extended by OIDC: ID token objects▶ OIDC defines following REST-style endpoints: – UserInfo endpoint: OAuth-protected resource endpoint to query identity data – ClientRegistration endpoint (opt.): resource endpoint to register OIDC clients▶ The Authorization endpoint employs 3-party exchanges with IdCs, IdPs and user agents as actors▶ The Token/UserInfo/ClientRegistration endpoints employ 2-party exchanges with IdCs and IdPs as actorsOct. 2012 - All rights reserved 27

ConclusionsChecking 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 approach 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 assignments of functional roles and use cases that are 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 good match for them.▶ It will replace other federated IdM protocols – Hmmm: the OIDC specification and its underpinnings (OAuth, JWT/S/E/K) are emerging. Adaptation should be expected to start in environments where other approaches are no good fit. This gives some room for coexistence.Oct. 2012 - All rights reserved 28

AbbreviationsAuthn Authentication REST REpresentational StateAuthz Authorization TransferID Identity RP Relying Party (aka SP in SAML)IAM Identity and Access Management SAML Security Assertion Markup LanguageIdC Identity Consumer saml: Namespace prefix forIdM Identity Management SAML assertion syntaxIdP Identity Provider (aka OP abstractions in OIDC) samlp: Namespace prefix forJSON JavaScript Object Notation SAML protocol syntaxJWA/E/K/S/T JSON Web Algorithms/ abstractions Encryption/Key/Signature/ SP Service Provider (aka RP Token in OIDC)OAuth Open Authorization SSO Single-Sign-OnOIDC OpenID Connect SWD Simple Web DiscoveryOIDF OpenID Foundation WS Web ServicesOP OpenID Provider (aka IdP in SAML)REST REpresentational State TransferOct. 2012 - All rights reserved 29

Further Information▶ Home: http://openid.net/connect▶ Specifications: – Minimal: • OpenID Connect Basic Client Profile 1.0 - draft 20 • OpenID Connect Implicit Client Profile 1.0 - draft 03 – Dynamic: • OpenID Connect Discovery 1.0 - draft 09 • OpenID Connect Dynamic Client Registration 1.0 - draft 11 – Complete: • OpenID Connect Standard 1.0 - draft 13 • OpenID Connect Messages 1.0 - draft 12 • OpenID Connect Session Management 1.0 - draft 08 – Others: • OAuth 2.0 Multiple Response Type Encoding Practices - draft 05▶ Utilities: – Demo (with Google as IdP): http://www8322u.sakura.ne.jp/oidconnect/ – JWT tool: http://openidtest.uninett.no/jwtOct. 2012 - All rights reserved 30

http://lafoglia.posterous.com	17
https://twitter.com	16
http://www.linkedin.com	2
http://kred.com	2
http://twitter.com	1

OpenID Connect - An Emperor or Just New Cloths?

by Oliver Pfaff

Accessibility

Categories

Upload Details

Usage Rights

5 Embeds 38

Statistics

OpenID Connect - An Emperor or Just New Cloths? Presentation Transcript