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

OAuth: When Things Go Wrong - Oktane19

OAuth: When Things Go Wrong - Oktane19

Aaron Parecki

April 03, 2019
Tweet

More Decks by Aaron Parecki

Other Decks in Technology

Transcript

  1. Aaron Parecki
    OAuth: When Things Go Wrong
    @aaronpk

    View Slide

  2. This presentation contains “forward-looking statements” within the meaning of the “safe harbor” provisions of the Private Securities Litigation Reform Act of 1995, which include, but are not limited to, statements
    regarding our financial outlook, product development, business strategy and plans, and market trends, opportunities and positioning. These forward-looking statements are based on current expectations,
    estimates, forecasts and projections. Words such as “expect,” “anticipate,” “should,” “believe,” “hope,” “target,” “project,” “goals,” “estimate,” “potential,” “predict,” “may,” “will,” “might,” “could,” “intend,” “shall” and
    variations of these terms or the negative of these terms and similar expressions are intended to identify these forward-looking statements, although not all forward-looking statements contain these identifying
    words. Forward-looking statements are subject to a number of risks and uncertainties, many of which involve factors or circumstances that are beyond Okta’s control.
    In particular, the following factors, among others, could cause results to differ materially from those expressed or implied by such forward-looking statements: the market for our products may develop more slowly
    than expected or than it has in the past; quarterly and annual operating results may fluctuate more than expected; variations related to our revenue recognition may cause significant fluctuations in our results of
    operations and cash flows; assertions by third parties that we violate their intellectual property rights could substantially harm our business; a network or data security incident that allows unauthorized access to
    our network or data or our customers’ data could harm our reputation, create additional liability and adversely impact our financial results; the risk of interruptions or performance problems, including a service
    outage, associated with our technology; intense competition in our market; weakened global economic conditions may adversely affect our industry; the risk of losing key employees; changes in foreign exchange
    rates; general political or destabilizing events, including war, conflict or acts of terrorism; our ability to successfully identify and integrate acquisitions, strategic investments, partnerships or alliances; our ability to
    pay off our senior convertible notes when due; and other risks and uncertainties. Past performance is not necessarily indicative of future results. Further information on potential factors that could affect Okta’s
    financial results is included in its Annual Report on Form 10-K for the year ended January 31, 2019 and other filings with the Securities and Exchange Commission that are posted on investor.okta.com.
    Any unreleased products, features or functionality referenced in this or other presentations, press releases or public statements are not currently available and may not be delivered on time or at all. Product
    roadmaps do not represent a commitment, obligation or promise to deliver any product, feature or functionality. Customers who purchase our products should make their purchase decisions based upon features
    that are currently generally available.
    The forward-looking statements contained in this presentation represent the Company’s estimates and assumptions only as of the date of this presentation. Okta assumes no obligation and does not intend to
    update these forward-looking statements whether as a result of new information, future events or otherwise.
    This presentation contains estimates and other statistical data that we obtained from industry publications and reports generated by third parties. These data involve a number of assumptions and limitations, and
    you are cautioned not to give undue weight to such estimates. Okta has not independently verified the statistical and other industry data generated by independent parties and contained in this presentation and,
    accordingly, Okta cannot guarantee their accuracy or completeness. Expectations, estimates, forecasts and projections are subject to a high degree of uncertainty and risk. Many factors, including those that are
    beyond Okta’s control, could cause results or outcomes to differ materially from those expressed in the estimates made by the independent parties and by Okta.
    Safe Harbor Statement

    View Slide

  3. Disclaimer:
    This presentation does not necessarily reflect

    the views of Okta.
    The examples given here are not meant to 

    pick on any one company in particular.

    View Slide

  4. oauth.net

    View Slide

  5. View Slide

  6. @aaronpk

    View Slide

  7. What is OAuth?
    And Why Does It Matter?

    View Slide

  8. THE PASSWORD ANTI-PATTERN

    View Slide

  9. THE PASSWORD ANTI-PATTERN
    facebook.com ~2010

    View Slide

  10. @aaronpk

    View Slide

  11. @aaronpk
    the app can't just get access to the user's data directly

    View Slide

  12. @aaronpk
    the app isn't allowed to ask for the user's password and use it

    View Slide

  13. @aaronpk
    so...
    how can I let an app
    access my data
    without giving it my password?

    View Slide

  14. @aaronpk
    Connect with Google
    https://yelp.com/

    View Slide

  15. @aaronpk
    the app needs to ask the user for an access token

    which it can use with the API
    password

    View Slide

  16. @aaronpk
    POST /resource/1/update HTTP/1.1
    Authorization: Bearer RsT5OjbzRn430zqMLgV3Ia
    Host: api.authorization-server.com
    description=Hello+World

    View Slide

  17. @aaronpk
    A HOTEL KEY CARD, FOR APPS

    View Slide

  18. How OAuth Works

    View Slide

  19. @aaronpk
    ROLES IN OAUTH
    OAuth Server
    (Authorization Server)
    aka the token factory
    API
    (Resource Server)
    The Application
    (Client)
    The User's Device
    (User Agent)

    View Slide

  20. User: I’d like to use this great app
    App: Please go to the authorization server to grant me access
    User: I’d like to log in to “The Best App Ever”, it wants to access my photos
    AS: Here is a temporary code the app can use
    App: Here is the temporary code, and my secret, please give me a token
    User: Here is the temporary code, please use this to get a token
    AS: Here is an access token!
    App: Please let me access this user’s data with this access token!
    User Agent
    App OAuth Server
    API

    View Slide

  21. Front Channel
    Back Channel
    https://accounts.google.com/?...
    Passing data via the browser's address bar
    The user, or malicious software,
    can modify the requests and responses
    Sent from server to server
    Code is run on a server,
    not on the user's computer,
    so requests cannot be tampered with

    View Slide

  22. Back Channel Benefits ‣ The application knows it's
    talking to the right server
    ‣ Connection from app to server
    can't be tampered with
    ‣ Response from the server can
    be trusted because it came
    back in the same connection

    View Slide

  23. OAuth Server OAuth Client
    Passing Data via the Back Channel

    View Slide

  24. OAuth Server OAuth Client
    access token!
    Passing Data via the Front Channel

    View Slide

  25. Front Channel Benefits
    https://accounts.google.com/?...
    ‣ The user being involved
    enables them to give consent
    ‣ Doesn't require the receiver to
    have a publicly routable IP

    (e.g. can work on a phone)

    View Slide

  26. Front-Channel Risks
    ▸ The sender has no guarantee the receiver will get the data

    e.g. if the redirect is intercepted
    ▸ The data is written to the browser history

    which may be synced to "the cloud" or other devices
    Any data received via the front channel must be verified before it is used!

    View Slide

  27. What Can Go Wrong?

    View Slide

  28. What Can Go Wrong with OAuth?
    ▸ Lots!
    ▸ Stolen API Keys
    ▸ Stolen Access Tokens
    ▸ Redirect URL Interception
    ▸ Phishing
    ▸ ... and more

    View Slide

  29. RFC 6749 Section 10
    RFC 8252 Section 8
    RFC 6819
    draft-ietf-oauth-security-topics
    What can go wrong with OAUTH?

    View Slide

  30. @aaronpk
    TWITTER
    STOLEN API KEYS

    View Slide

  31. @aaronpk
    2013

    View Slide

  32. @aaronpk

    View Slide

  33. @aaronpk
    ANYONE CAN 

    IMPERSONATE 

    THE TWITTER APPS

    View Slide

  34. @aaronpk
    DON'T PUT SECRETS

    IN NATIVE APPS!
    https://developer.okta.com/blog/2019/01/22/oauth-api-keys-arent-safe-in-mobile-apps

    View Slide

  35. @aaronpk
    PKCE
    PROOF-KEY FOR CODE EXCHANGE
    RFC 7636
    (pronounced "pixie")

    View Slide

  36. @aaronpk
    PKCE PKCE
    Authorization Code Flow

    View Slide

  37. OAuth Server
    (Authorization Server)
    API
    (Resource Server)
    The Best
    App Ever
    User: I’d like to use this great app
    App: Please go to the authorization server to grant me access, take this hash with you
    User: I’d like to log in to this app, here's the hashed secret it gave me
    AS: Here is a temporary code the app can use
    App: Here's the code, and the plaintext secret, please give me a token
    User: Here is the temporary code, please use this to get a token
    AS: Let me verify the hash of that secret... ok here is an access token!
    App: Please let me access this user’s data with this access token!
    App: Hang on while I generate a new secret and hash it

    View Slide

  38. @aaronpk
    AppAuth.io
    iOS / Android / JavaScript

    View Slide

  39. @aaronpk
    FACEBOOK
    STOLEN ACCESS TOKENS
    improperly issued

    View Slide

  40. @aaronpk
    2018

    View Slide

  41. @aaronpk
    https://newsroom.fb.com/news/2018/09/security-update/
    The vulnerability was the result of the interaction of three distinct bugs:

    View Slide

  42. @aaronpk
    https://newsroom.fb.com/news/2018/09/security-update/
    The vulnerability was the result of the interaction of three distinct bugs:

    View Slide

  43. @aaronpk
    https://newsroom.fb.com/news/2018/09/security-update/
    The vulnerability was the result of the interaction of three distinct bugs:
    ??!

    View Slide

  44. @aaronpk
    By using the "View As" feature to see what your profile looks like to someone else,
    you would end up with an access token belonging to that user,
    which had the permissions of the Facebook mobile app.

    View Slide

  45. @aaronpk
    Treat components of your application

    the same way you'd treat third-party applications

    View Slide

  46. @aaronpk
    JWT
    ALG=NONE
    photo by flickr.com/quidox

    View Slide

  47. @aaronpk
    2015

    View Slide

  48. An Example JWT
    eyJraWQiOiJvQ1JjR3RxVDhRV2tJR0MyVXpmcEZUczVqSkdnM00zSTNOMHgtZDJhSFNNIiwiYW
    xnIjoiUlMyNTYifQ.eyJ2ZXIiOjEsImp0aSI6IkFULkp3eVRTcTlqNDU0bDNTNmRTM1VTV1hMV
    VpwekdKdWNSd1ZEbFZCNWNIc3cuVVM1V1NGYVFiQllUMC9GM2tjMG8vK1ZUY3VZZzdwVnZqZXZ
    TT3hkUHhCMD0iLCJpc3MiOiJodHRwczovL2Rldi0zOTYzNDMub2t0YXByZXZpZXcuY29tL29hd
    XRoMi9kZWZhdWx0IiwiYXVkIjoiYXBpOi8vZGVmYXVsdCIsImlhdCI6MTU0MzgwMzAyNSwiZXh
    wIjoxNTQzODA2NjI1LCJjaWQiOiIwb2FoenBwM3RjcEZyZmNXSTBoNyIsInVpZCI6IjAwdWkwZ
    mpraWV5TDQ2bWEwMGg3Iiwic2NwIjpbIm9mZmxpbmVfYWNjZXNzIiwicGhvdG8iXSwic3ViIjo
    iaW5xdWlzaXRpdmUtYWxiYXRyb3NzQGV4YW1wbGUuY29tIn0.ncVkzcc6qrFJSXE3-5UsRu_kH
    vbwIMKYL3PFaMwReYTquPAcOQ8t93xF0bxbS8wrP0udCDvk6eYq4VbjoFdD59Yy6ltz0OKQl3-
    g8uFg2RwqTBMOKR0mYtQH0RCr9ORhSsmKolaDDt4TcRX78ZOAyhZ_Qg_UcEoHM4uZikpzBJYpY
    KbCCfbx-6FzYyHuvevSFzURISYpSHv3nbzirkEzKbOv7eZlg1cCYBdUoGuVBskyHxfMxFpoKQU
    3mwIFdlQJR8LZ8hA_5ZdYjjMeSXfjnhlP2rppJiHy1NreGXXcUsUA74V2t_keY44deTrnPgoFO
    Se9IchWqcj6sDMDutC4ag

    View Slide

  49. Attacking a JWT
    {
    "typ": "JWT",
    "alg": "RS256"
    }
    {
    "ver": 1,
    "jti": "AT.JwyTSq9j454l3S6dS3USWXLUZpzGJucRwVDlVB5cHsw.US5WSFaQbBYT0/F3kc0o/+VTcuYg7pVvjevSOxdPxB0=",
    "iss": "https://dev-396343.oktapreview.com/oauth2/default",
    "aud": "api://default",
    "iat": 1543803025,
    "exp": 1543806625,
    "cid": "0oahzpp3tcpFrfcWI0h7",
    "uid": "00ui0fjkieyL46ma00h7",
    "scp": [
    "offline_access",
    "photo"
    ],
    "sub": "[email protected]"
    }
    header
    claims
    signature

    View Slide

  50. Attacking a JWT
    {
    "typ": "JWT",
    "alg": "HS256"
    }
    {
    "ver": 1,
    "jti": "AT.JwyTSq9j454l3S6dS3USWXLUZpzGJucRwVDlVB5cHsw.US5WSFaQbBYT0/F3kc0o/+VTcuYg7pVvjevSOxdPxB0=",
    "iss": "https://dev-396343.oktapreview.com/oauth2/default",
    "aud": "api://default",
    "iat": 1543803025,
    "exp": 1543806625,
    "cid": "0oahzpp3tcpFrfcWI0h7",
    "uid": "00ui0fjkieyL46ma00h7",
    "scp": [
    "offline_access",
    "photo"
    ],
    "sub": "[email protected]"
    }
    header
    claims
    signature

    View Slide

  51. Attacking a JWT
    {
    "typ": "JWT",
    "alg": "none"
    }
    {
    "ver": 1,
    "jti": "AT.JwyTSq9j454l3S6dS3USWXLUZpzGJucRwVDlVB5cHsw.US5WSFaQbBYT0/F3kc0o/+VTcuYg7pVvjevSOxdPxB0=",
    "iss": "https://dev-396343.oktapreview.com/oauth2/default",
    "aud": "api://default",
    "iat": 1543803025,
    "exp": 1543806625,
    "cid": "0oahzpp3tcpFrfcWI0h7",
    "uid": "00ui0fjkieyL46ma00h7",
    "scp": [
    "offline_access",
    "photo"
    ],
    "sub": "[email protected]"
    }
    header
    claims

    View Slide

  52. @aaronpk
    Never let the JWT header

    determine your verification mechanism

    View Slide

  53. @aaronpk
    Thankfully most JWT libraries

    fixed this in 2015-2016

    View Slide

  54. @aaronpk
    GOOGLE
    OAUTH PHISHING

    View Slide

  55. @aaronpk
    2017

    View Slide

  56. https://accounts.google.com/oauth/authorize?response_type

    View Slide

  57. https://arstechnica.com/information-technology/2017/05/dont-trust-oauth-why-the-google-docs-worm-was-so-convincing/

    View Slide

  58. https://accounts.google.com/oauth/authorize?response_type

    View Slide

  59. View Slide

  60. View Slide

  61. Prompting the User for Authorization Consent
    • Provide clear and straightforward information
    • Provide enough detail so the user knows what the
    application can access
    • Don't provide too much detail that they are overwhelmed
    and just click "ok"

    View Slide

  62. View Slide

  63. View Slide

  64. View Slide

  65. View Slide

  66. View Slide

  67. View Slide

  68. View Slide

  69. View Slide

  70. View Slide

  71. Authorization Interface

    View Slide

  72. Authorization Interface
    Identify your service
    Identify the
    third-party app
    List the scopes the
    app is requesting
    Identify the
    developer name
    Show which user
    is logged in
    Allow/Cancel
    buttons

    View Slide

  73. oauth.net/security
    oauth2simplified.com

    View Slide

  74. Find me in the Developer Lounge!
    @aaronpk
    aaronpk.com

    View Slide

  75. Rate this session 

    in the mobile app
    OAuth: When Things Go Wrong

    View Slide

  76. Recommended Sessions
    Keeping Mobile Secure Roadmap: Okta Security
    (Repeat)
    WEDNESDAY, APRIL 3
    3:30 - 4:15 PM
    Speaker:
    Hans Reichenbach - Staff Software
    Engineer
    WEDNESDAY, APRIL 3
    3:30 - 4:15 PM | Room 2022
    Speakers:
    Alex Bovee - Dir, Product Management
    Tranh-ha Nguyen - Sr. Associate Product
    Manager

    View Slide