Designing OpenID Connect and OAuth-based Systems

Transcript

1. Designing OpenID Connect & OAuth 2.0-based Systems Tips from the Trenches Dominick Baier @leastprivilege
2. 2 @leastprivilege Me • Independent Consultant – Specializing on Application Security Architectures & Security Protocols – Working with Software Development Teams (ISVs and in-house) • Co-Creator of IdentityServer & IdentityModel OSS Project – Certified OpenID Connect & OAuth 2.0 Implementation for .NET – https://identityserver.io • Co-Creator of PolicyServer – Authorization for modern Applications – https://policyserver.io email dominick.baier@leastprivilege.com blog https://leastprivilege.com twitter @leastprivilege slides https://speakerdeck.com/leastprivilege
3. 3 @leastprivilege Agenda • Overview • Systems design 101 • Closer look – authentication & user management – session management – protocol flows – resource design – token design – token lifetime & revocation
4. 4 @leastprivilege App2 Authentication Authorization User Management App3 • Same Sign-on • Single Sign-on • Sign-out? • User management • Access management external Authentication • "Social" providers • Integration with identity systems of customers 3rd Party Access/Integration • Access to your system by 3rd parties • Integration with existing 3rd party software App1
5. 5 @leastprivilege
6. 6 @leastprivilege The Big Picture Browser Native App Server App IoT Web App Web API Web API Web API Users - Clients - Resources Security Token Service
7. 7 @leastprivilege Let's start…
8. 8 @leastprivilege What are you building? • Internal application • Customer facing application • Both • How is it deployed? – on-premise • internal vs customer – cloud
9. 9 @leastprivilege Users
10. 10 @leastprivilege Who are your Users? • Employees – Active Directory – Azure Active Directory • Customers – Username/Password – "social" providers (Google etc.) – Federation with customer identity system • ADFS, AAD, Ping etc.
11. 11 @leastprivilege Clients
12. 12 @leastprivilege Clients Browser Native App Server App IoT Web App Web API Web API Web API
13. 13 @leastprivilege Clients Browser Native App Server App IoT Web App Web API 1 Machine to Machine Clients 2 Interactive Clients 1 1 2 2 2 3 Confidential Clients 4 Public Clients 3 3 3 4 4 5 1st Party Clients 6 3rd Party Clients
14. 14 @leastprivilege Resources
15. 15 @leastprivilege Resources • Identity resources – openid: subject identifier – profile: first name, last name… – email: email, email verified • API resources – logical name of API the client wants to access The authorization and token endpoints allow the client to specify the scope of the access request using the "scope" request parameter. The value of the scope parameter is expressed as a list of space-delimited, case- sensitive strings. RFC6749
16. 16 @leastprivilege 1st Approximation • Old App (Web) • Customers • username/password • New App (SPA) • Mobile App • Customers • username/password • Google • customer identity system • Back-office System (Web) • Employees • Automated jobs • service accounts Clients Resources • Monolith • Products API • Customers API • Invoicing API • …
17. 17 @leastprivilege More Details…
18. 18 @leastprivilege Identity sub: Subject - Identifier for the End-User at the Issuer. OIDC Core: 5.1 Standard Claims Bad Examples: • dominick_baier • dominick@baier.com • dominick\domain • <id column of your SQL Server users table> Good Example: • <something_random>
19. 19 @leastprivilege Pass-thru vs Identity Transformation (1) Client Your Identity Provider External Identity Providers sub/issuer + other claims sub/issuer + other claims • Pros • simplifies STS design • Cons • makes client deal with implementation details
20. 20 @leastprivilege Pass-thru vs Identity Transformation (2) Client Your Identity Provider External Identity Providers my sub/issuer + other claims sub/issuer + other claims my sub -> ext sub + issuer + other claims mapping • Pros • clients become agnostic of tech details • Cons • more complicated STS implementation • mapping logic • who's the authoritative data source?
21. 21 @leastprivilege Protocol Flow • Only bother to learn a single flow for interactive clients – authorization code flow w/ PKCE • Works for all user-centric client types – public and confidential – web and native – optional client authentication • "OAuth 2.1" will deprecate the other flows – implicit and password
22. 22 @leastprivilege Authorization Code Flow • Front-Channel – browser-based – user-interaction • Back-Channel – retrieve tokens GET /authorize ?client_id=app1 &redirect_uri=https://app.com/cb GET /cb?code=xyz client id, (secret), code id and access token 3 1 2 UI
23. 23 @leastprivilege Identity Tokens • Authentication response from STS back to client – protocol data, authentication information, session id, subject id, user claims { "iss": "https://issuer", "exp": 1340819380, "iat": 1340818761, "aud": "app1", "nonce": "j1y…a23", "amr": [ "pwd" ], "auth_time": 12340819300, "sid": "ajk9kß90kl99", "sub": "182jmm199", "first_name": "Alice", } Payload https://openid.net/specs/openid-connect-core-1_0.html#IDToken
24. 24 @leastprivilege Session Management Web App 1 Your Identity Provider Web App 2 Mobile App Browser 1 2 3 4 Sessions: n + 1 (n = # of clients) sid sid sid sid
25. 25 @leastprivilege Session Management Web App 1 Your Identity Provider Web App 2 Mobile App Browser 1 2 3 4 Sessions: n + 1 (n = # of clients) sid sid sid sid 0 sid External Identity Provider
26. 26 @leastprivilege Session Management • Protocols only help you to a certain degree – session id distributed via identity token – front- and back-channel notifications • Common discussion topics – what does logout mean to you? • applications, identity provider, upstream identity provider… – client- vs server-side sessions – shared inactivity timer
27. 27 @leastprivilege Accessing Resources • WS-Security used AppliesTo – URI identifying a resource (aka Web Service) – only single resource could be specified • OAuth uses the scope parameter The authorization and token endpoints allow the client to specify the scope of the access request using the "scope" request parameter. The value of the scope parameter is expressed as a list of space-delimited, case- sensitive strings. If the value contains multiple space-delimited strings, their order does not matter, and each string adds an additional access range to the requested scope. The authorization server MAY fully or partially ignore the scope requested by the client, based on the authorization server policy or the resource owner's instructions. RFC6749
28. 28 @leastprivilege Example: GitHub Scopes https://developer.github.com/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/
29. 29 @leastprivilege Example: Google Scopes https://developers.google.com/oauthplayground/
30. 30 @leastprivilege Only introduce Scopes when you need them! Clients scope: 'backend'
31. 31 @leastprivilege Introduce Scopes when you need them! Web App catalog Back-Office External orders invoicing.management invoicing.delivery
32. 32 @leastprivilege Example: Modeling API Resources with IdentityServer var clients = new[] { new Client { ClientId = "webapp", AllowedScopes = { "catalog", "orders" } }, new Client { ClientId = "backoffice", AllowedScopes = { "orders", "invoicing.management" } }, new Client { ClientId = "external", AllowedScopes = { "invoicing.delivery" } } }; var resources = new[] { new ApiResource("catalog"), new ApiResource("orders"), new ApiResource("invoicing") { Scopes = new[] { new Scope("invoicing.management"), new Scope("invoicing.delivery") } } };
33. 33 @leastprivilege Example: Access Token { "typ": "at+jwt", "alg": "RS256" "kid": "1" } { "iss": "https://issuer", "nbf": 1340819020, "exp": 1340819380, "aud": "invoicing", "client_id": "external", "scope": "invoicing.delivery" } External (M2M) { "iss": "https://issuer", "nbf": 1340818761, "exp": 1340819380, "aud": [ "orders", "invoicing" ], "client_id": "backoffice", "scope": [ "orders", "invoicing.management" ] "sub": "182jmm199", "amr": [ "pwd" ] } { "typ": "at+jwt", "alg": "RS256" "kid": "1" } Back-Office (user centric)
34. 34 @leastprivilege Shared vs Resource-specific Access Tokens { "iss": "https://issuer", "nbf": 1340818761, "exp": 1340819380, "aud": [ "orders", "invoicing" ], "client_id": "backoffice", "scope": [ "orders", "invoicing.management" ] "sub": "182jmm199", "amr": [ "pwd" ], "more_data": "…" } orders invoicing trust boundary? https://tools.ietf.org/wg/oauth/draft-ietf-oauth-resource-indicators/
35. 35 @leastprivilege Token Lifetime and Revoking Access to Resources • What's the best value for the access token lifetime? – as short as possible • Do you need revocation? – no – yes – waiting until current access token expires is OK – yes – immediate
36. 36 @leastprivilege Access Token Type • token lifetime: n seconds • refresh token (optional) • lifetime: >n seconds • absolute vs sliding expiration • what can be revoked: • refresh token • max time to revocation • n seconds • token service round-trip for refresh • every n seconds • token service round-trip for validation • 0 Self-contained Token (JWT) Reference Token • token lifetime: n seconds • refresh token (optional) • lifetime: >n seconds • absolute vs sliding expiration • what can be revoked: • access token • refresh token • max time to revocation • immediate • token service round-trip for refresh • every n seconds • token service round-trip for validation • for every usage
37. 37 @leastprivilege Summary • Three main ingredients of a token-based system – users – clients – resources • Solid design around subject identifier • Keep as simple as possible – number of claims / types – session management requirements – resource design – resource access and revocation