Upgrade to Pro — share decks privately, control downloads, hide ads and more …

An Introduction to OpenID Connect

An Introduction to OpenID Connect

Slides for my NDC 2013 introduction to OpenID Connect, presented as a guest lecture on Dominick Baier's "Claims-based Identity & Access Control for .NET 4.5 Applications" workshop

Pedro Felix

June 15, 2013
Tweet

More Decks by Pedro Felix

Other Decks in Programming

Transcript

  1. whoami • Professor at the Lisbon Polytechnic Institute • Independent

    Consultant • Currently with the Service Delivery Broker team (SAPO- Portugal Telecom) • Co-author of Designing Evolvable Web APIs with ASP.NET (to be published in 2013 by O’Reilly) 2
  2. Goals and outline “OpenID Connect 1.0 is a simple identity

    layer on top of the OAuth 2.0 protocol” in http://openid.net/connect/ • Quick review of OAuth 1.0 • Why does OAuth 1.0 needs a “identity layer”? • OpenID Connect parties and flows • ID tokens and the JSON Web Token format • Discussion 3
  3. Cast of characters • Resource Server • E.g. An HTTP

    based API • Client application • Accesses the resource on the User’s behalf • User • Might not be the resource owner 5 Client App Resource Server User (aka Resource Owner) User- Agent
  4. Not a simple client-server model • In classical Consumer to

    Business models • The client app is transparent • Only the User identity is taken into consideration • In classical Business to Business models • Only the client app identity is taken into consideration • OAuth – Three entities in three different trust boudaries 6 Client App Resource Server User- Agent User (aka Resource Owner)
  5. The client • Server-side web applications • Native applications •

    Client-side web applications • Devices (e.g. IPTV Set Top Boxes) • Hybrid: native application and server-side Web API • From same trust boundary • From different trust boundaries 7
  6. Authorization Request 8 Client App Resource Server User- Agent Authorization

    Endpoint redirect_uri scope state Authorization Server client_id
  7. Front-channel interaction 9 Client App Resource Server User- Agent Authorization

    Endpoint Authorization Server Out-of-protocol interaction: User Authentication and Authorization Grant Consent Grant
  8. The grant concept • Represents the logical outcome of the

    User’s authorization • (User identity, Client identity, Scopes) • Additional attributes such as time validity as redirect_uri • Not a protocol concept • Core domain concept • Bound to all the Authorization Server artifacts • Code • Access token • Refresh token 10
  9. Authorization Response 11 Client App Resource Server User- Agent Authorization

    Endpoint redirect_uri scope state state code Authorization Server client_id Grant state code
  10. Token Request and Response 12 Client App Resource Server User-

    Agent Authorization Endpoint Token Endpoint client_id code client_secret access_token Authorization Server Grant refresh_token
  11. Front and back channels • Front channel • Authorization Endpoint

    (AE) • Authorization request – redirect from Client to AE via the User-agent • Authorization response – redirect from AE to Client via the User-agent • Human interface – User authentication and authorization granting • Out-of-protocol interactions • Not secure for Client secrets – no Client authentication • Back channel • Token Endpoint (TE) • Direct request-response between Client and Token Endpoint • No User interaction • No Human interface • Optional Client authentication 13
  12. Client Types • Confidential “Clients capable of maintaining the confidentiality

    of their credentials” (e.g. client implemented as a secure Web server) • Public “Clients incapable of maintaining the confidentiality of their credentials” (e.g. clients executing on the device used by the resource owner, i.e., native apps or client-side Web apps )
  13. Client and Users • Three scenarios • Single client –

    all the users (web app, native app) • One client per user (native app) • One client per multiple users (family shared tablet, IPTV Set Top Box) • Dynamic Client Registration • Client Registration Endpoint – still in draft • Turning public clients into private client instances • Not a closed problem – see OAuth 2.0 mailing list circa May 2013
  14. Token Request and Response 16 Client App Resource Server User-

    Agent Authorization Endpoint Token Endpoint client_id code client_secret access_token Authorization Server Grant refresh_token
  15. Resource Access 17 Client App Resource Server User- Agent Authorization

    Endpoint Token Endpoint Authorization Server access_token Grant
  16. Bearer Tokens (RFC 6750) • Bearer tokens • Usable by

    any entity • similar to a bearer check or a hotel room key card • This is both good and bad • Always using TLS • Major OAuth 2.0 critique • Constrasts with MAC tokens • Requires prooving a key possession • Used by OAuth 1.0 18 Client App Resource Server User- Agent Authorization Endpoint Token Endpoint Authorization Server access_token Grant
  17. Access token format and processing • OAuth 2.0 • Does

    not define access token format • Does not define token processing rules • Tight coupling between Authorization Server and Resource Server • Typically run by the same organization • Using opaque formats and processing rules • No protocol provision for cross-boundary AS and RS interaction 19
  18. Implicit Flow 20 Client App Resource Server User- Agent Authorization

    Endpoint redirect_uri scope state Authorization Server client_id access_token access_token Grant
  19. 21 Client App Resource Server User- Agent Authorization Endpoint Token

    Endpoint Authorization Server Authentication
  20. Claims Identity Model 22 Identity Provider Relying Party (Identity Consumer)

    Security Token {claims} Subject Issues Consumes About
  21. 23 Client App Resource Server User- Agent Authorization Endpoint Token

    Endpoint Authorization Server Who is whom? Identity Provider Subject Relying Party
  22. 24 Client App Resource Server User- Agent Authorization Endpoint Authorization

    Endpoint Authorization Server Who is whom? Identity Provider Subject Relying Party
  23. What is missing? • No standard resource to obtain User

    identity information • No UserInfo endpoint • No identity representation format • No token audience • Bearer authentication must be directed 25
  24. OpenID Connect 26 Client App UserInfo User- Agent Authorization Endpoint

    redirect_uri scope state state code Authorization Server client_id client_id code client_secret access_token id_token Token Endpoint access_token standard scopes: openid profile email address phone ... Identity Assertion Standard UserInfo endpoint
  25. OpenID Connect standard claims • name - string • given_name

    - string • family_name - string • middle_name - string • nickname - string • preferred_username - string • profile - string • picture - string • website - string • email - string • email_verified - boolean • gender - string • birthdate - string • zoneinfo - string • locale - string • phone_number - string • phone_number_verified - boolean • address - JSON object • updated_at - number 27
  26. Scope – claim mapping • profile: name, family_name, given_name, middle_name,

    nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, updated_at • email: email, email_verified • address: address • phone: phone_number, phone_number_verified • offline_access: requires refresh token 28
  27. Security Token • Container of security-related information – typically claims

    • Securely packaged for communication between parties • Integrity • Confidentiality • E.g. SAML – Security Assertion Markup Language <Assertion ID = “…” IssueInstant = “…” Version = “2.0”> <Issuer> https://the.issuer.net/</Issuer> <Signature> [XML DSIG signature, incl. certificate(s)]</Signature> <Subject> <NameID>Alice</NameID> <SubjectConfirmation Method=“Bearer”/> </Subject> <Conditions NotBefore=“…” NotAfter=“…” > <AudienceRestriction><Audience>https://the.rp.net</Audience></AudienceRestriction> <AttributeStatement> <Attribute Name = “emailaddress”> <AttributeValue>[email protected]</AttributeValue> … 29
  28. JSON Web Token • Based on the JSON format •

    “Intended for space constrained environments such as HTTP Authorization headers and URI query parameters.” • Relies on • JWS – JSON Web Signature • JWE – JSON Web Encryption • Represented as • Sequence of Base64url encoded parts • Separeted by ‘.’ 30
  29. Reserved claim names • JWT • iss – issuer •

    sub – subject • aud – audience • (nbf – not before, exp – expiration) • iat - issued at • jti – JWT ID • typ – type • OpenID Connect • azp – authorized party • auth_time – authentication time • nonce • at_hash – access token hash • acr – authentication context class reference • amr – authentication methods reference 32
  30. UserInfo Endpoint • “The UserInfo Endpoint is an OAuth 2.0

    Protected Resource that returns Claims about the authenticated End-User” • Access using the issued access_token • Response is a JSON object with the User’s claims as members 35
  31. Conclusions and final remarks • OpenID Connect 1.0 • “is

    a simple identity layer on top of the OAuth 2.0 protocol” • Adds to OAuth 2.0 • Scopes • ID token • UserInfo • Extra UI-related authorization request parameters • Discovery and metadata • Integrates authentication with API authorization 37
  32. References • http://openid.net/connect/ • Vittorio Bertocci, “OAuth 2.0 and Sign-In”,

    http://www.cloudidentity.com/blog/2013/01/02/oauth-2-0-and-sign-in-4/ • John Bradley, “The problem with OAuth for Authentication” http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html • Google implementation • Documentation - https://developers.google.com/accounts/docs/OAuth2Login • Authorization Endpoint - https://accounts.google.com/o/oauth2/auth • Token Endpoint - https://accounts.google.com/o/oauth2/token • UserInfo https://www.googleapis.com/plus/v1/people/me 38