An Introduction to OpenID Connect NDC 2013 Pedro Félix @pmhsfelix [email protected] 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 

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 

An hypothetical scenario 4 AppHarbor GitHub Alice User- Agent 

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 

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) 

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 

Authorization Request 8 Client App Resource Server User- Agent Authorization Endpoint redirect_uri scope state Authorization Server client_id 

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 

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 

Authorization Response 11 Client App Resource Server User- Agent Authorization Endpoint redirect_uri scope state state code Authorization Server client_id Grant state code 

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 

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 

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 ) 

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 

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 

Resource Access 17 Client App Resource Server User- Agent Authorization Endpoint Token Endpoint Authorization Server access_token Grant 

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 

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 

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 Client App Resource Server User- Agent Authorization Endpoint Token Endpoint Authorization Server Authentication 

Claims Identity Model 22 Identity Provider Relying Party (Identity Consumer) Security Token {claims} Subject Issues Consumes About 

23 Client App Resource Server User- Agent Authorization Endpoint Token Endpoint Authorization Server Who is whom? Identity Provider Subject Relying Party 

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

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 

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 

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 

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 

Security Token • Container of security-related information – typically claims • Securely packaged for communication between parties • Integrity • Confidentiality • E.g. SAML – Security Assertion Markup Language https://the.issuer.net/ [XML DSIG signature, incl. certificate(s)] Alice https://the.rp.net [email protected] … 29 

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 

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 

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 

JwtSecurityTokenHandler 33 

JwtSecurityToken • Install-Package System.IdentityModel.Tokens.Jwt • General Availability since June 2013 34 

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 

Demo 36 

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 

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 

Thanks! 39