What the Heck is OAuth and OpenID Connect - RWX 2017

OAuth is not an API or a service: it is an open standard for authorization and any developer can implement it. OAuth is a standard that applications can use to provide client applications with “secure delegated access”. OAuth works over HTTP and authorizes Devices, APIs, Servers and Applications with access tokens rather than credentials, which we will go over in depth below. OpenID Connect (OIDC) is built on top of the OAuth 2.0 protocol. It allows clients to verify the identity of the user and, as well as to obtain their basic profile information.

This session covers how OAuth/OIDC works, when to use them, and frameworks/services that simplify authentication.

Blog post: https://developer.okta.com/blog/2017/06/21/what-the-heck-is-oauth

Transcript

1. Matt Raible | @mraible
   What the Heck is OAuth and OIDC?
   December 7, 2017 #RichWeb17
   

   View Slide

2. Blogger on raibledesigns.com
   Web Developer and Java Champion
   Father, Skier, Mountain Biker,
   Whitewater Rafter
   Open Source Connoisseur
   Who is Matt Raible?
   Bus Lover
   Okta Developer Advocate
   

   View Slide

3. View Slide

4. View Slide

5. View Slide

6. developer.okta.com
   

   View Slide

7. Authentication Standards
   

   View Slide

8. What about You?
   Java, .NET, Python, or Node.js?
   Have you ever written authentication
   from scratch?
   Have you implemented OAuth or OIDC?
   Have you heard of Okta? Auth0?
   Why are you here?
   

   View Slide

9. Originally created by Karl McGuinness
   @jankytweet
   

   View Slide

10. OAuth 2.0 Overview
    

    View Slide

11. An open standard for authorization; anyone can implement it
    Provides “secure delegated access” to client applications
    Works over HTTPS and authorizes:
    Devices
    APIs
    Servers
    Applications
    … with access tokens rather than credentials
    What is OAuth?
    

    View Slide

12. Direct Authentication
    GET /index.html HTTP/1.1
    Host: www.example.com
    Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
    

    View Slide

13. Federated Identity
    Identity Provider
    (IdP)
    Service Provider
    (SP)
    End User
    Trust
    Obtains Assertion Provides Assertion
    

    View Slide

14. How Federated Identity Works
    

    View Slide

15. SAML 2.0
    OASIS Standard, 15 March 2005
    Authentication Request
    Protocol
    Assertion
    

    View Slide

16. SAML 2.0 Authentication Request Protocol
    

    View Slide

17. SAML 2.0 Assertion
    IssueInstant="2004-12-05T09:22:05"
    https://example.okta.com
    ...
    
    
    matt@example.com
    
    
    
    
    
    
    https://sp.example.com/saml2/sso
    
    
    
    
    
    urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
    
    
    
    
    
    Matt Raible
    
    
    
    

    View Slide

18. SAML = Web SSO
    

    View Slide

19. View Slide

20. SOA
    

    View Slide

21. What’s
    Changed
    Since
    2005?
    

    View Slide

22. Cloud-native applications are dynamic and public!
    

    View Slide

23. Modern and native applications
    

    View Slide

24. Connected experiences across devices
    

    View Slide

25. Simple Web APIs
    GET POST PUT DELETE
    

    View Slide

26. API Economy
    

    View Slide

27. API-driven Initiatives
    Custom Web and
    Mobile Apps
    B2B Partner
    Integration
    Developer Ecosystem Shared Services
    Platform for the
    Enterprise
    

    View Slide

28. 2017: The Year of the API Economy
    

    View Slide

29. Delegated Authorization Problem
    How can a user authorize an app to access protected data on their behalf?
    

    View Slide

30. Have you ever seen one of these?
    

    View Slide

31. © Okta and/or its affiliates. All rights reserved. Okta Confidential
    

    View Slide

32. OAuth 2.0
    Enables apps to obtain limited access (scopes) to
    a user’s data without giving away a user’s
    password
    Decouples authentication from authorization
    Supports multiple use cases addressing different
    client capabilities and deployment models
    Server-to-server apps
    Browser-based apps
    Mobile/Native apps
    Consoles/TVs
    Web-scale delegated authorization framework for REST/APIs
    Protecting APIs
    Since
    October 2012
    

    View Slide

33. Modern Applications
    Browser
    App
    Server App
    Web API Web API
    Web API
    Native App
    Web App
    

    View Slide

34. Hotel Key Cards, but for Apps
    

    View Slide

35. Hotel Key Cards, but for Apps
    OAuth Authorization Server Resource (API)
    Access Token
    

    View Slide

36. OAuth Simplified
    App requests authorization from User
    1
    User authorizes App and delivers proof
    2
    App presents proof of authorization to server to get a Token
    3
    Token is restricted to only access what the User authorized
    for the specific App
    4
    

    View Slide

37. OAuth 2.0
    Actors
    Clients
    Scopes & Consent
    Tokens
    Authorization Server
    Flows
    

    View Slide

38. Authorization

    Server (AS)
    Resource
    Owner (RO) Client
    Delegates
    Obtains Token
    Uses Token
    Resource

    Server (RS)
    Actors
    

    View Slide

39. Authorization

    Server (AS)
    Resource
    Owner (RO) Client
    Delegates
    Obtains Token
    Uses Token
    Resource

    Server (RS)
    Actors
    

    View Slide

40. Clients
    Public
    (Client Identification)
    Confidential

    (Client Authentication)
    

    View Slide

41. Clients
    Client Registration is the DMV of OAuth
    

    View Slide

42. Scopes
    Additive bundles of permissions
    asked by client when requesting a
    token
    Decouples authorization policy
    decisions from enforcement
    Who owns the data? End user or
    the target service
    Who gets to specify the
    authorization policy? End user or
    application owner
    Scopes to Deny
    Scopes to Allow
    

    View Slide

43. Capturing User Consent
    Authorization Grant (Trust of First Use)
    

    View Slide

44. Tokens
    • Short-lived token used by
    Client to access Resource
    Server (API)
    • Opaque to the Client
    • No client authentication
    required (Public Clients)
    • Optimized for scale and
    performance
    • Revocation is dependent on
    implementation
    Access Token (Required)
    • Long-lived token that is
    used by Client to obtain
    new access tokens from
    Authorization Server
    • Usually requires
    Confidential Clients with
    authentication
    • Forces client to rotate
    secrets
    • Can usually be revoked
    Refresh Token (Optional)
    OAuth doesn’t define the format of a token!
    

    View Slide

45. Access Token Types
    Self-contained tokens
    Protected, time-limited data structure agreed upon between Authorization Server and
    Resource Server that contains metadata and claims about the identity of the user or
    client over the wire.
    Resource Server can validate the token locally by checking the signature, expected
    issuer name and expected audience or scope.
    Commonly implemented as a signed JSON Web Tokens (JWT)
    Reference tokens (aka opaque tokens)
    Infeasible-to-guess (secure-random) identifier for a token issued and stored by the
    OAuth 2.0 Authorization Server
    Resource Server must send the identifier via back-channel to the OAuth 2.0
    Authorization Server’s token introspection endpoint to determine if the token is valid
    and obtain claims/scopes
    

    View Slide

46. JSON Web Token (JWT)
    base64url(Header) + “.” + base64url(Claims) + “.” + base64url(Signature)
    eyJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwczovL2
    V4YW1wbGUub2t0YS5jb20iLCJzdWIiOiIwMHVncmVuT
    WVxdllsYTRIVzBnMyIsImF1ZCI6IncyNTVIRVdpU1U0
    QXVOeEVqZWlqIiwiaWF0IjoxNDQ2MzA1MjgyLCJleHA
    iOjE0NDYzMDg4ODIsImFtciI6WyJwd2QiXSwiYXV0aF
    90aW1lIjoxNDQ2MzA1MjgyLCJlbWFpbCI6ImthcmxAZ
    XhhbXBsZS5jb20iLCJlbWFpbF92ZXJpZmllZCI6dHJ1
    ZX0.XcNXs4C7DqpR22LLti777AMMVCxM7FjEPKZQnd-
    AS_Cc6R54wuQ5EApuY6GVFCkIlnfbNmYSbHMkO4H-
    L3uoeXVOPQmcqhNPDLLEChj00jQwZDjhPD9uBoNwGyi
    Z9_YKwsRpzbg9NEeY8xEwXJFIdk6SRktTFrVNHAOIhE
    Qsgm8
    {
    "alg": "RS256”

    "kid": "123456789"
    }
    {
    "iss": "https://example.okta.com",
    "sub": "00ugrenMeqvYla4HW0g3",
    "aud": "w255HEWiSU4AuNxEjeij",
    "iat": 1446305282,
    "exp": 1446308882,
    "amr": [
    "pwd"
    ],
    "auth_time": 1446305282,
    "email": "karl@example.com",
    "email_verified": true
    }
    Header Claims
    Signature
    Header
    Claims
    

    View Slide

47. Token Issuer and Audience
    Audience
    Issuer
    

    View Slide

48. Token Issuer and Audience
    Resource Server (RS)
    audience: api.example.com
    Authorization Server (AS)
    issuer: org.okta.com
    Resource Server (RS)
    audience: foo.example.com
    Resource Domain
    Client
    trust
    trust
    issuer (iss): org.okta.com
    audience (aud): api.example.com
    

    View Slide

49. Authorization Server
    Authorize Endpoint (/
    oauth2/authorize)
    Token Endpoint
    (/oauth2/token)
    Authorization Server
    Authorization Grant
    Refresh Token
    Access Token
    Introspection Endpoint (/
    oauth2/introspect)
    Revocation Endpoint (/
    oauth2/revoke)
    

    View Slide

50. © Okta and/or its affiliates. All rights reserved. Okta Confidential
    Token State Management
    Developer Friction
    50
    

    View Slide

51. Flow Channels
    Resource

    Server (RS)
    Authorization

    Server (AS)
    Resource
    Owner (RO)
    Client
    Delegates
    Obtains Token
    Uses Token
    Back
    Channel
    Front
    Channel
    

    View Slide

52. Front Channel Flow
    Authorize via User Agent
    Resource

    Server (RS)
    Authorization

    Server (AS)
    4
    2
    3
    1
    Resource Owner starts flow to
    delegate access to protected
    resource
    1
    Client
    2
    Client sends authorization request
    with desired scopes via browser
    redirect to Authorize Endpoint on
    Authorization Server
    3
    User authenticates and consents to
    Delegated Access (Grant)
    4 Authorization Code Grant or Access
    Token is returned to Client via
    browser redirect
    Resource
    Owner (RO)
    

    View Slide

53. Authorization Request
    GET https://accounts.google.com/o/oauth2/auth?

    scope=gmail.insert gmail.send&

    redirect_uri=https://app.example.com/oauth2/callback&

    response_type=code&

    client_id=812741506391&

    state=af0ifjsldkj
    HTTP/1.1 302 Found

    Location: https://app.example.com/oauth2/callback?

    code=MsCeLvIaQm6bTrgtp7&

    state=af0ifjsldkj
    Request
    Response
    Note: Parameters are not URL-encoded for example purposes
    

    View Slide

54. Back Channel Flow
    Exchange Grants for Tokens
    Resource

    Server (RS)
    Authorization

    Server (AS)
    1
    Client
    2
    Client accesses protected
    resource with Access Token
    Resource
    Owner (RO)
    2
    Client exchanges Authorization
    Code Grant with token endpoint
    on Authorization Server for an
    Access Token and optionally
    Refresh Token
    1
    

    View Slide

55. Token Request
    POST /oauth2/v3/token HTTP/1.1
    Host: www.googleapis.com
    Content-Type: application/x-www-form-urlencoded
    code=MsCeLvIaQm6bTrgtp7&
    client_id=812741506391&
    client_secret={client_secret}&
    redirect_uri=https://app.example.com/oauth2/callback&
    grant_type=authorization_code
    Note: Parameters are not URL-encoded for example purposes
    

    View Slide

56. Token Response
    {
    "access_token": "2YotnFZFEjr1zCsicMWpAA",
    "token_type": "Bearer",
    "expires_in": 3600,
    "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA"
    }
    

    View Slide

57. Making Protected Resource Requests
    curl -H "Authorization: Bearer 2YotnFZFEjr1zCsicMWpAA" \
    https://www.googleapis.com/gmail/v1/users/1444587525/messages
    

    View Slide

58. OAuth 2.0 Grant Types (Flows)
    • Optimized for browser-only
    Public Clients
    • Access token returned
    directly from authorization
    request (Front-channel only)
    • Does not support refresh
    tokens
    • Assumes Resource Owner
    and Public Client are on the
    same device
    • Most vulnerable to security
    threats
    Implicit (2 Legged)
    • Front channel flow used by
    Client to obtain
    authorization code grant
    • Back channel flow used by
    Client to exchange
    authorization code grant
    for access token and
    optionally refresh token
    • Assumes Resource Owner
    and Client are on separate
    devices
    • Most secure flow as tokens
    never passes through user-
    agent
    Authorization Code (3 Legged)
    • Optimized for server-only
    Confidential Clients acting
    on behalf of itself or a user
    • Back-channel only flow to
    obtain an access token
    using the Client’s
    credentials
    • Supports shared secrets or
    assertions as Client
    credentials signed with
    either symmetric or
    asymmetric keys
    Client Credential
    

    View Slide

59. OAuth 2.0 Grant Types (Flows)
    • Legacy grant type for native
    username/password apps
    such as desktop apps
    • Username/password is
    authorization grant to
    obtain access token from
    Authorization Server
    • Does not support refresh
    tokens
    • Assumes Resource Owner
    and Public Client or on the
    same device
    Resource Owner Password
    • Allows Authorization Server
    to trust authorization
    grants from third party such
    as SAML IdP (Federation)
    • Assertion is used to obtain
    access token with token
    request
    • Does not support refresh
    tokens
    Assertion
    • Optimized for devices that
    do not have access to web-
    browsers
    • User code is returned from
    authorization request that
    must be redeemed by
    visiting a URL on a device
    with a browser to authorize
    • Back channel flow used by
    Client to poll for
    authorization approval for
    access token and optionally
    refresh token
    Device
    

    View Slide

60. OAuth Flows
    Six different flows
    Necessary because of:
    How you get consent from client?
    Who is making consent?
    Adds a lot of complexity to OAuth
    When people ask if you support OAuth, are they asking for all
    six?
    Image: Ian Sane, Spring Runoff

    https://www.flickr.com/photos/31246066@N04/4620052369
    

    View Slide

61. Common OAuth 2.0 Security Issues
    Too many inputs that need validation
    Token hijacking with CSRF
    Always use CSRF token with state parameter to ensure OAuth flow integrity
    Leaking authorization codes or tokens through redirects
    Always whitelist redirect URIs and ensure proper URI validations
    Token hijacking by switching clients
    Bind the same client to authorization grants and token requests
    Leaking client secrets
    Unbounded & Bearer Tokens
    See draft specification of OAuth Proof-of-Possession Token Extension
    

    View Slide

62. Key Enterprise OAuth 2.0 Use Cases
    Decouples authorization policy decisions from
    enforcement
    Enables the right blend of fine & coarse grained
    authorization
    Replaces traditional Web Access management (WAM)
    Policies
    Restrict and revoke which apps can access specific
    APIs
    Ensure only managed and/or complaint devices can
    access specific APIs
    Deep integration with identity deprovisioning
    workflow to revoke all tokens for a user and device
    Federation with an IdP
    

    View Slide

63. OAuth 2.0 Facts
    Not backward compatible with
    OAuth 1.0
    Interoperability issues exists as
    its not a protocol but rather an
    authorization framework
    OAuth 2.0 is not an
    authentication protocol
    OAuth 2.0 alone says absolutely
    nothing about the user
    

    View Slide

64. © Okta and/or its affiliates. All rights reserved. Okta Confidential 64
    Authorization
    Framework?
    

    View Slide

65. Like WS-Security Security
    

    View Slide

66. Authorization Framework
    Return of Complexity through Extensions
    OAuth 2 Framework
    RFC 6749
    Assertion Framework
    RFC 7521
    Token Introspection
    RFC 7662
    Token Revocation
    RFC 7009
    Dynamic Client Registration
    RFC 7591
    JSON
    RFC 7159
    JSON Web Token Bearer Assertion
    RFC 7523
    Proof Key for Code Exchange (PKCE)
    RFC 7636
    Token Exchange
    Draft
    SAML 2.0 Bearer Assertion
    RFC 7522
    Proof of Possession
    Draft
    JSON Web Token (JWT)
    RFC 7519
    JSON Web Signature (JWS)
    RFC 7515
    JSON Web Encryption (JWE) 

    RFC 7516
    JSON Web Key (JWK)
    RFC 7517
    Bearer Token
    RFC 6750
    

    View Slide

67. Why all the complexity again?
    Enterprise use cases such as federation
    Interoperable tokens that can be signed and encrypted
    Proof-of-Possession tokens that can’t be replayed
    Embedded user agents with unsecure cross-app
    communication channels
    Bindings for non-HTTP transports and legacy protocols such as
    LDAP or IMAP as well as constrained devices (IoT)
    67
    

    View Slide

68. © Okta and/or its affiliates. All rights reserved. Okta Confidential 68
    Not an
    Authentication
    Protocol?
    

    View Slide

69. OAuth 2.0 as Pseudo-Authentication
    Client accessing a https://
    api.example.com/me resource with
    an access token is not
    authenticating the user
    Access tokens just prove the Client
    was authorized, are opaque, and
    intended to only be consumed by
    the Resource Server
    Who is the user (claims)?
    When did the user authenticate?
    Does the user still have an active or
    expired session?
    How did the user authenticate?
    Just password or password + second
    factor
    As made famous by Facebook Connect and Twitter
    

    View Slide

70. OpenID Connect
    OpenID Connect
    

    View Slide

71. OpenID Connect
    Extends OAuth 2.0 with new signed id_token for the
    Client and UserInfo endpoint to fetch user attributes
    Provides a standard set of scopes and claims for
    identities
    profile
    email
    address
    phone
    Built-in registration, discovery & metadata for
    dynamic federations
    Bring Your Own Identity (BYOI)
    Supports high assurance levels and key SAML use
    cases (enterprise)
    OAuth 2.0 + Facebook Connect + SAML 2.0 (good parts)
    

    View Slide

72. Authorization Request
    GET https://accounts.google.com/o/oauth2/auth?

    scope=openid email&

    redirect_uri=https://app.example.com/oauth2/callback&

    response_type=code&

    client_id=812741506391&

    state=af0ifjsldkj
    HTTP/1.1 302 Found

    Location: https://app.example.com/oauth2/callback?

    code=MsCeLvIaQm6bTrgtp7&

    state=af0ifjsldkj
    Request
    Response
    Note: Parameters are not URL-encoded for example purposes
    

    View Slide

73. Token Request
    POST /oauth2/v3/token HTTP/1.1
    Host: www.googleapis.com
    Content-Type: application/x-www-form-urlencoded
    code=MsCeLvIaQm6bTrgtp7&
    client_id=812741506391&
    client_secret={client_secret}&
    redirect_uri=https://app.example.com/oauth2/callback&
    grant_type=authorization_code
    Note: Parameters are not URL-encoded for example purposes
    

    View Slide

74. Token Response
    {
    "access_token": "2YotnFZFEjr1zCsicMWpAA",
    "token_type": "Bearer",
    "expires_in": 3600,
    "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA",
    "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ..."
    }
    

    View Slide

75. Validate ID
    Token
    Token Endpoint
    Authorization Endpoint
    /.well-known/

    openid-configuration
    JWKS Endpoint
    UserInfo Endpoint
    OAuth 2.0 Authorization Server &
    OpenID Connect Provider (OP)
    OAuth 2.0 Resource Server
    Client
    (Relying Party) 1
    3
    2
    5
    4
    1 Discover OpenID Provider Metadata
    2 Perform OAuth flow to obtain a ID
    token and/or access token
    3 Get JSON Web Key Set (JWKS) for
    signature keys
    4 Validate ID token

    (JSON Web Token)
    5 Get additional user attributes with
    access token from UserInfo
    endpoint
    OpenID Connect
    

    View Slide

76. Which grant type is right for you?
    Authorization

    Code
    Implicit Authorization

    Code
    Client Credentials
    OAuth 2.0 Only
    

    View Slide

77. Implicit Flow (SPA)
    Authenticate via User Agent
    1
    User starts flow by visiting Single
    Page App Client with User Agent
    2
    Client sends authentication request
    with openid scope via browser
    redirect to Authorize Endpoint on
    Authorization Server
    3
    User authenticates and consents to
    Client to access user’s identity
    4
    ID Token and optionally Access Token for
    SPA app is returned to Client via browser
    redirect
    4
    2
    3
    1
    User
    SPA

    (Client)
    Resource

    Server (RS)
    /UserInfo
    Authorization

    Server (AS)
    5
    Client optionally fetches additional claims
    with Access Token from UserInfo endpoint
    5
    

    View Slide

78. Authorization Code Flow (Web)
    Authenticate via User Agent
    1
    User starts flow by visiting Web App
    Client with User Agent
    2
    Client sends authentication request
    with openid scope via browser
    redirect to Authorize Endpoint on
    Authorization Server
    3
    User authenticates and consents to
    Client to access user’s identity
    4
    Authorization Code Grant and optionally
    ID Token for Web App is returned to Client
    via browser redirect
    4
    2
    3
    1
    User
    Web App

    (Client)
    Resource

    Server (RS)
    /UserInfo
    Authorization

    Server (AS)
    

    View Slide

79. Authorization Code Flow (Web)
    Exchange Grant for Tokens
    1b
    1a
    User
    Web App

    (Client)
    Resource

    Server (RS)
    /UserInfo
    Authorization

    Server (AS)
    2
    2
    Client optionally fetches additional
    claims with Access Token from UserInfo
    endpoint
    Client authenticates & exchanges
    Authorization Code Grant with token
    endpoint on Authorization Server for an ID
    Token, Access Token and optionally
    Refresh Token
    1
    

    View Slide

80. Session Best Practices
    ID Tokens should be used to create a session for a
    traditional web application or single-page application
    Use subject claim (sub) as stable identifier for the user
    account
    Session cookies should be protected with HTTPOnly flag
    to prevent JS access
    Avoid using ID Tokens as a stateless “session token”
    for Single Page Apps
    API is not the audience of the token
    ID Tokens can be large in size and often contain PII or
    other sensitive data
    ID Token lifetime is not your app’s session lifetime
    

    View Slide

81. Authorization Code Flow (Native)
    Authenticate via User Agent
    1
    User starts flow by launching Native
    App Client
    2
    Client launches User Agent and sends
    authentication request with openid
    scope and PKCE code challenge via
    browser redirect to Authorize Endpoint
    on Authorization Server
    3
    User authenticates and consents to
    Client to access user’s identity
    4
    Authorization Code Grant and optionally
    ID Token for Web App is returned to Client
    via browser redirect and User Agent is
    closed
    4
    2
    3
    1
    User
    Native App

    (Client)
    Resource

    Server (RS)
    /UserInfo
    Authorization

    Server (AS)
    

    View Slide

82. Authorization Code Flow (Native)
    Exchange Grant for Tokens
    1b
    1a
    User
    Native App

    (Client)
    Resource

    Server (RS)
    /UserInfo
    Authorization

    Server (AS)
    2
    2
    Client optionally fetches additional
    claims with Access Token from UserInfo
    endpoint
    Client exchanges Authorization Code
    Grant and PKCE code verifier with token
    endpoint on Authorization Server for an ID
    Token, Access Token and optionally
    Refresh Token
    1
    

    View Slide

83. Native App Best Practices
    Do not use an embedded webviews for authenticating users!
    App (or 3rd party library/script) can directly obtain the user’s
    credentials which goes against OAuth’s raison d'être
    Users can’t reuse their existing session with their IdP (SSO)
    increasing friction for sign-in/sign-up
    IdPs can’t implement new authentication methods
    Do not store client secrets in apps that are distributed via App
    Stores!
    Use PKCE (RFC 7636) to protect authorization code from
    interception
    Follow guidelines outlined in OAuth 2.0 for Native Apps Best
    Current Practice

    https://tools.ietf.org/html/draft-ietf-oauth-native-apps-12
    302 Found

    Location: app://redirect
    

    View Slide

84. Just Use AppAuth!
    https://appauth.io
    Implements OAuth 2.0 for Native Apps Best Current Practice
    

    View Slide

85. OpenID Connect with Okta
    developer.okta.com
    

    View Slide

86. Templated Client Registration with Quickstarts
    

    View Slide

87. Sign-In Widget and JS Auth SDK
    87
    Open-source embeddable widget for end-to-end
    sign-in flow with MFA and account recovery
    Returns an ID Token for authenticated user
    Supports social authentication providers
    Built-on common JS Auth SDK
    Open source: https://github.com/okta/okta-signin-
    widget
    

    View Slide

88. Sign-In Widget and JS Auth SDK
    Wraps Okta authentication and session management APIs in JS callbacks
    for custom UX
    Implements custom web messaging OAuth 2.0 response mode (okta-post-
    message) for single page applications with hidden iframe
    Open source: https://github.com/okta/okta-auth-js
    authClient.signIn({
    username: 'some-username',
    password: 'some-password'
    })
    .then(function(transaction) {
    if (transaction.status === 'SUCCESS') {
    authClient.session.setCookieAndRedirect(transaction.sessionToken);
    }
    });
    

    View Slide

89. Specifications Implemented by Okta
    OpenID Connect Core 1.0 (spec)
    OpenID Provider Metadata (spec)
    OAuth 2.0 (RFC 6749)
    OAuth 2.0 Bearer Token Usage (RFC 6750)
    OAuth 2.0 Multiple Response Types (spec)
    OAuth 2.0 Form Post Response Mode (spec)
    OAuth 2.0 Token Revocation (RFC 7009)
    OAuth 2.0 Token Introspection (RFC 7662)
    Proof Key for Code Exchange by OAuth Public Clients (RFC 7636)
    

    View Slide

90. OAuth and OIDC Demos
    

    View Slide

91. Google OAuth Client Library
    ScribeJava
    Spring Security OAuth
    Nimbus OAuth SDK
    List of client and server libraries for many languages:
    https://oauth.net/code/
    OAuth and OIDC Libraries
    

    View Slide

92. ORY Hydra
    https://github.com/ory/hydra
    Apereo CAS
    https://github.com/apereo/cas
    Keycloak
    https://github.com/keycloak/keycloak
    JHipster UAA
    https://jhipster.github.io/using-uaa/
    Open Source OAuth and OIDC Servers
    

    View Slide

93. OAuth Specification
    oauth.net
    OAuth 2.0 Servers
    oauth.com
    Additional Resources
    

    View Slide

94. developer.okta.com/blog/
    

    View Slide

95. Questions?
    Keep in touch!
    
    raibledesigns.com
    
    @mraible
    
    Presentations
    
    speakerdeck.com/mraible
    
    Code
    
    github.com/oktadeveloper
    

    View Slide