1 / 40

OpenID Connect Update

OpenID Connect Update. March 25, 2012 Mike Jones Identity Standards Architect – Microsoft. Working Together. OpenID Connect. Working Group Participants. Key working group participants: Nat Sakimura – Nomura Research Institute – Japan John Bradley – Independent – Chile

quang
Télécharger la présentation

OpenID Connect Update

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OpenID ConnectUpdate March 25, 2012 Mike Jones Identity Standards Architect – Microsoft

  2. Working Together OpenID Connect

  3. Working Group Participants • Key working group participants: • Nat Sakimura – Nomura Research Institute – Japan • John Bradley – Independent – Chile • Breno de Medeiros – Google – US • Paul Tarjan – Facebook – US • Axel Nennker – Deutsche Telekom – Germany • Torsten Lodderstedt – Deutsche Telekom – Germany • Kick Willemse – Independent – Netherlands • Chuck Mortimore – Salesforce – US • Justin Richer – Mitre - US • Mike Jones – Microsoft – US • By no means an exhaustive list!

  4. OpenID Connect Intro • Simple identity layer on top of OAuth 2.0 • Enables clients to verify identity of end-user • Enables clients to obtain basic profile info • REST/JSON interfaces => low barrier to entry

  5. OpenID Connect Range • Spans use cases, scenarios • Internet, Enterprise, Cloud, Mobile • Spans security & privacy requirements • From non-sensitive information to highly secure • Spans sophistication of claims usage • From basic default claims to specific requested claims to aggregated and distributed claims • Maximizes simplicity of implementations • Reuses existing OAuth 2.0, JWT, SWD specs • Build only the pieces you need

  6. Key Diffs from OpenID 2.0 • Support for native client applications • Identifiers using e-mail address format • Standard UserInfo functionality for simple “Connect” capability • Designed to work well on mobile phones • Uses JSON/REST, rather than XML • Support for encryption and higher LOAs • Support for distributed and aggregated claims

  7. Presentation Overview • Introduction • Design • A Look Under the Covers • Overview of Connect Specs • Recent Timeline • Developer Feedback Incorporated • Relationship to IETF Specs • Next Steps • Resources

  8. Design Philosophy

  9. Standard UserInfo for Simple “Connect” Ability Simple Things Simple • Designed to Work Well on Mobile Phones

  10. How We Make It Simple • Build on OAuth 2.0 • Use JavaScript Object Notation (JSON) • Can build only the pieces that you need • Goal: Easy implementation on all modern development platforms

  11. Aggregated Claims Complex Things Possible • Distributed Claims • Encrypted Claims

  12. Aggregated Claims Data Source Data Source Signed Claims Claim Values Identity Provider Relying Party

  13. Distributed Claims Data Source Data Source Signed Claims Claim Refs Relying Party Identity Provider

  14. Connect Capabilities • Dynamic Clients • Mobile Support • UserInfo Endpoint • Simple RPs • Session Management • Single Logout • Aggregated and Distributed Claims • Encrypted Claims

  15. Connect Interop Status • Interop at http://osis.idcommons.net/ • By the numbers: • 8 implementations participating • 56 feature tests defined • 507 feature test results recorded • 57 members of interop mailing list • 239 messages to interop mailing list

  16. A Look Under the Covers • ID Token • Claims Requests • UserInfo Claims • Example Protocol Messages

  17. ID Token • JWT token representing logged-in session • Claims: • iss– Issuer • user_id – Identifier for user • aud – Audience for ID Token • exp – Expiration time • nonce – Mitigates replay attacks

  18. ID Token Claims Example { "iss": "https://server.example.com", "user_id": "248289761001", "aud": "0acf77d4-b486-4c99-bd76-074ed6a64ddf", "exp": 1311281970, "nonce": "n-0S6_WzA2Mj" }

  19. Claims Requests • Basic requests made using OAuth scopes: • openid– Declares request is for OpenID Connect • profile – Requests default profile info • email – Requests email address and verification status • address – Requests postal address • phone– Requests telephone number • General claims requests made using JSON OpenID Request Object • Enables specific claims to be requested

  20. UserInfo Claims • user_id • name • given_name • family_name • nickname • profile • picture • website • email • verified • gender • birthday • zoneinfo • locale • phone_number • address • updated_time

  21. UserInfo Claims Example { "user_id": "248289761001", "name": "Jane Doe", "given_name": "Jane", "family_name": "Doe", "email": "janedoe@example.com", "verified": true, "picture": "http://example.com/janedoe/me.jpg" }

  22. Authorization Request Example https://server.example.com/authorize ?response_type=token%20id_token &client_id=0acf77d4-b486-4c99-bd76-074ed6a64ddf &redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb &scope=openid%20profile &state=af0ifjsldkj &nonce=n-0S6_WzA2Mj

  23. Authorization Response Example HTTP/1.1 302 Found Location: https://client.example.com/cb #access_token=mF_9.B5f-4.1JqM &token_type=bearer &id_token=eyJhbGzI1NiJ9.eyJz9Glnw9J.F9-V4IvQ0Z &expires_in=3600 &state=aF0ifJsLD_k9J

  24. UserInfo Request Example GET /userinfo?schema=openid HTTP/1.1 Host: server.example.com Authorization: Bearer mF_9.B5f-4.1JqM

  25. Connect Specs Overview

  26. Basic Client Profile • Single, simple, self-contained Web client spec • All you need for web-based RP utilizing pre-configured set of OPs • http://openid.net/specs/openid-connect-basic-1_0.html

  27. Discovery & Registration • Enables dynamic configurations in which sets of OPs and RPs are not pre-configured • Necessary for open deployments • Discovery enables RPs to learn about OP endpoints • Dynamic registration enables RPs to use OPs they don’t have a pre-existing relationship with • http://openid.net/specs/openid-connect-discovery-1_0.html • http://openid.net/specs/openid-connect-registration-1_0.html

  28. Messages & Standard • Messages spec defines data formats exchanged in OpenID Connect messages • Standard spec is HTTP binding for Messages • (Basic is a profile of Messages and Standard) • Needed for OPs, native client apps, and RPs needing functionality not in Basic • E.g., claims not in default UserInfo set • http://openid.net/specs/openid-connect-messages-1_0.html • http://openid.net/specs/openid-connect-standard-1_0.html

  29. Session Management • For OPs and RPs needing session management capabilities • For example: Logout • http://openid.net/specs/openid-connect-session-1_0.html

  30. Underpinnings • OAuth 2.0 family of specs • OAuth 2.0 Core • OAuth 2.0 Bearer • OAuth 2.0 Assertions • OAuth 2.0 JWT Assertions Profile • JWT family of specs • JSON Web Token (JWT) • JSON Web Signature (JWS) • JSON Web Encryption (JWE) • JSON Web Algorithms (JWA) • JSON Web Key (JWK) • Simple Web Discovery (SWD)

  31. Recent Timeline • Artifact Binding working group formed, Mar 2010 • Weekly spec calls began, Jan 2011 • Open issues closed at IIW, May 2011 • Result branded “OpenID Connect”, May 2011 • Developer feedback, May 2011 to present • Functionally complete specs, Jul 2011 • Formal issue tracking began, Jul 2011 • Interop testing, Sep-Nov 2011 • Simpler specs published incorporating developer feedback, Sep & Oct 2011 • Published Proposed Implementer’s Drafts, Dec 2011 • Implementer’s Drafts Approved Feb 2012 • Interop testing, Feb 2012 to present

  32. Developer Feedback Incorporated • Ask: Simpler, more modular specs • Created Basic Client Profile as a result • Messages and Standard also simplified • Ask: UserInfo schema similar to Facebook Connect • Changed spelling of claim names from camelCase to lowercase_with_underscores • Ask: More meaningful JSON identifiers • Changed OpenID identifiers to be full words, e.g.: • it → id_token • loc → preferred_locales • Ask: Enable single-sign-on without requiring UserInfo • Can now receive just an ID Token, if desired

  33. Connect OAuth Specs • draft-ietf-oauth-v2 – Nearing RFC • draft-ietf-oauth-v2-bearer – Nearing RFC • draft-ietf-oauth-assertions – Last call • draft-ietf-oauth-v2-threatmodel – Last call

  34. Connect JOSE Specs • draft-ietf-jose-json-web-signature – WG Draft • draft-ietf-jose-json-web-encryption – WG Draft • draft-ietf-jose-json-web-algorithms – WG Draft • draft-ietf-jose-json-web-key – WG draft

  35. Connect Homeless Specs • draft-jones-json-web-token – Target OAuth WG • draft-jones-oauth-jwt-bearer – Target OAuth WG • draft-jones-simple-web-discovery – Target OAuth WG Securing homes for these specs a key goal this week

  36. Related Specs • draft-hardjono-oauth-dynreg • Related goals to open-connect-registration • Token type and use case agnostic • Versus openid-connect-registration, which intentionally embed deep knowledge of Connect use case, including token type, etc. • User Managed Access (UMA) Specs • Use Connect specs for authentication

  37. Open Issues • New Session Management spec needed • Need to understand impact on other specs • Want it to work with Account Chooser • Google prototyping possible solutions • Several specific outstanding feature proposals • Resulted from feedback on implementer’s drafts • Mostly already resolved • Need interop on the new features incorporated

  38. Risks • Dependencies on IETF specs/processes • OAuth specifications: • OAuth 2.0 Core, Bearer, Assertions • JOSE specifications: • JWS, JWE, JWA, JWK • Currently homeless specifications: • JWT, OAuth JWT Profile, SWD • IETF could change/delay any of these specs

  39. Next Steps • Continue incorporating spec feedback • Create new Session Management spec • Vote it to Implementer’s Draft status • Encourage/monitor deployments • Once all specs are complete/stable: • Create final specification drafts • OIDF vote to approve final specifications

  40. Resources • OpenID Connect Page • http://openid.net/connect/ • OpenID Connect Working Group Mailing List • http://lists.openid.net/mailman/listinfo/openid-specs-ab • OpenID Connect Interop Wiki • http://osis.idcommons.net/ • OpenID Connect Interop Mailing List • http://groups.google.com/group/openid-connect-interop • Mike Jones’ Blog • http://self-issued.info/ • Nat Sakimura’s Blog • http://nat.sakimura.org/ • John Bradley’s Blog • http://www.thread-safe.com/

More Related