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

Designing OpenID Connect and OAuth-based Systems

Designing OpenID Connect and OAuth-based Systems

Dominick Baier

January 24, 2020
Tweet

More Decks by Dominick Baier

Other Decks in Programming

Transcript

  1. Designing OpenID Connect &
    OAuth 2.0-based Systems
    Tips from the Trenches
    Dominick Baier
    @leastprivilege

    View Slide

  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 [email protected]
    blog https://leastprivilege.com
    twitter @leastprivilege
    slides https://speakerdeck.com/leastprivilege

    View Slide

  3. 3
    @leastprivilege
    Agenda
    • Overview
    • Systems design 101
    • Closer look
    – authentication & user management
    – session management
    – protocol flows
    – resource design
    – token design
    – token lifetime & revocation

    View Slide

  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

    View Slide

  5. 5
    @leastprivilege

    View Slide

  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

    View Slide

  7. 7
    @leastprivilege
    Let's start…

    View Slide

  8. 8
    @leastprivilege
    What are you building?
    • Internal application
    • Customer facing application
    • Both
    • How is it deployed?
    – on-premise
    • internal vs customer
    – cloud

    View Slide

  9. 9
    @leastprivilege
    Users

    View Slide

  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.

    View Slide

  11. 11
    @leastprivilege
    Clients

    View Slide

  12. 12
    @leastprivilege
    Clients
    Browser
    Native App
    Server App
    IoT
    Web App
    Web API Web API
    Web API

    View Slide

  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

    View Slide

  14. 14
    @leastprivilege
    Resources

    View Slide

  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

    View Slide

  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
    • …

    View Slide

  17. 17
    @leastprivilege
    More Details…

    View Slide

  18. 18
    @leastprivilege
    Identity
    sub: Subject - Identifier for the End-User at the Issuer.
    OIDC Core: 5.1 Standard Claims
    Bad Examples:
    • dominick_baier
    [email protected]
    • dominick\domain

    Good Example:

    View Slide

  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

    View Slide

  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?

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide

  28. 28
    @leastprivilege
    Example: GitHub Scopes
    https://developer.github.com/apps/building-oauth-apps/understanding-scopes-for-oauth-apps/

    View Slide

  29. 29
    @leastprivilege
    Example: Google Scopes
    https://developers.google.com/oauthplayground/

    View Slide

  30. 30
    @leastprivilege
    Only introduce Scopes when you need them!
    Clients scope: 'backend'

    View Slide

  31. 31
    @leastprivilege
    Introduce Scopes when you need them!
    Web App
    catalog
    Back-Office
    External
    orders
    invoicing.management
    invoicing.delivery

    View Slide

  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")
    }
    }
    };

    View Slide

  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)

    View Slide

  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/

    View Slide

  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

    View Slide

  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

    View Slide

  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

    View Slide