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