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

Transcript

1. An Introduction to OpenID Connect NDC 2013 Pedro Félix @pmhsfelix pmhsfelix@gmail.com 1
2. 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
3. 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
4. An hypothetical scenario 4 AppHarbor GitHub Alice User- Agent
5. 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
6. 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)
7. 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
8. Authorization Request 8 Client App Resource Server User- Agent Authorization Endpoint redirect_uri scope state Authorization Server client_id
9. 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
10. 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
11. Authorization Response 11 Client App Resource Server User- Agent Authorization Endpoint redirect_uri scope state state code Authorization Server client_id Grant state code
12. 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
13. 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
14. 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 )
15. 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
16. 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
17. Resource Access 17 Client App Resource Server User- Agent Authorization Endpoint Token Endpoint Authorization Server access_token Grant
18. 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
19. 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
20. Implicit Flow 20 Client App Resource Server User- Agent Authorization Endpoint redirect_uri scope state Authorization Server client_id access_token access_token Grant
21. 21 Client App Resource Server User- Agent Authorization Endpoint Token Endpoint Authorization Server Authentication
22. Claims Identity Model 22 Identity Provider Relying Party (Identity Consumer) Security Token {claims} Subject Issues Consumes About
23. 23 Client App Resource Server User- Agent Authorization Endpoint Token Endpoint Authorization Server Who is whom? Identity Provider Subject Relying Party
24. 24 Client App Resource Server User- Agent Authorization Endpoint Authorization Endpoint Authorization Server Who is whom? Identity Provider Subject Relying Party
25. 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
26. 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
27. 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
28. 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
29. 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>alice@wonder.land</AttributeValue> … 29
30. 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
31. Example eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJzZWxmIiwiYXVkIjoiaHR0cDovL3 d3dy5leGFtcGxlLmNvbSIsIm5iZiI6MTM3MDczNjkzOSwiZXhwIjoxMzcwNzM3MDU5L CJ1bmlxdWVfbmFtZSI6IlBlZHJvIiwicm9sZSI6IkF1dGhvciJ9.oKsW1AtfnkaebyAEA0GE udxsTrzQw94SBUULvEe2nGM {"typ":"JWT","alg":"HS256"} { "iss":"self", "aud":"http://www.example.com", "nbf":1370736939, "exp":1370737059, "unique_name":"Pedro", "role":"Author“ } a0ab16d40b5f9e469e6f2004034184b9dc6c4ebcd0c3de1205450bbc47b69c63 31
32. 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
33. JwtSecurityTokenHandler 33
34. JwtSecurityToken • Install-Package System.IdentityModel.Tokens.Jwt • General Availability since June 2013 34
35. 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
36. Demo 36
37. 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
38. 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
39. Thanks! 39