https://www.hackmiami.com/hmc5-speakers-day-2 OAuth is one of the most popular authorization frameworks in use today. All major platforms such as Google, Facebook, Box etc support it and you are probably thinking of implementi ng OAuth for your product/platform.We are not debating the popularity of the protocol or the limitations that come with it. We are here to help you implement it securely. When you use OAuth, there are three pieces - The Platform , the Application (using the platform) and the User (of the application). We will go over the common flaws we have seen in applications built on a OAuth platform which can lead to complete account takeover, how they can be a security engineer's nightmare, and how to fix them. We will go over security controls that the platform can put in place to help mitigate security vulnerabilities. We will also cover how bad design decisions, if chained with otherwise lower risk vulnerabilities can result in gaping holes in your OAuth implementation. You will leave this session with a deep understanding of how OAuth implementation should be secured both for a platform and in an application and things to test for during a security evaluation of OAuth implementations.

1. OAuth Nightmares
HARIRAM BALASUNDARAM / YASHVIER KOSARAJU
BOX

2. $whoami
 Hari
 Staff Security Engineer
 ~5 years at Box
 @m4x1mus
 Yash
 Security Engineer
 ~2.5 years at Box

3. About Box

4. Box platform
 ~7 billion API calls per month
 ~90000 developers
 Developers from different industries
 Healthcare
 FinServ
 Tech
 Content APIs
 Webapp integrations
 Partner Integrations
 SDKs

5. Why this talk?
 OAuth RFC is fairly fluid
 And numerous
 RFC 6749 , RFC 6819, RFC 6750, RFC 7523 and so on!
 Framework is flexible
 Hence the success and adoption
 Lessons learned pivoting from a product to a
platform
 There is no one right design

6. Talk Agenda
 Quick overview on OAuth – end-to-end flow
 Grants
 Tokens
 Client registration
 Apps validation process
 Consent screen
 User Controls
 Developer Security

7. What is OAuth
 OAuth is a delegation protocol
 Security heavily driven by
 user-choice
 platform design decisions
 Trust on First use model
 You are using Oauth everywhere!

8. Flow: client registration

9. Flow: client registration

10. Flow: client registration

11. Flow: client registration

12. Roles
 The User: "Resource Owner”
 Authorization server
 The API: "Resource Server"
 The Third-Party Application: "Client”
 Web applications
 Backend services
 Mobile applications
 Native applications

13. Flow: User authorizing an app

14. Flow: User authorizing an app

15. Flow: Tokens granted to access
resource

16. Flow: API interaction to access
resource

17. Grants
 Defines the authorization flow to get tokens
 Types
 Authorization code grant
 Implicit grant
 Resource owner password credentials grant
 Client credentials grant
 JWT Bearer grant

18. Authorization code grant
 Use this if you want to support clients that are web
servers
 Ex. Office Online integration to Box
 Secure Design Considerations
 How long is the authorization code valid?
 How many times can the authorization code be reused?
Hint – zero!
 Rate limits on the authorization code granting endpoint?
 Tie authorization code to client id
 When a secret is not a secret (ex. Mobile apps)
 Will be discussed later in the talk.

19. Anti-CSRF – ”state” parameter
 Used by client to maintain state between request and
callback
 Should be mandated by server
 Attack
 Connect” type features
 Authorization code is the only identifying token in the first
step post authentication
 Generate authorization code for attacker account
 iFrame GET request to platform with authorization code
and trick victim to visit page
 Connect your account to victim’s account on the platform

20. Implicit grant
 Instead of a code, an access token is directly returned
back to the client
 Primarily for clients which has to ship secrets client-side
(ex. Angular JS app)
 Secure Design considerations:
 CORS (to be discussed later in the talk)
 Use this only if no other type of authorization can be used
since access token is exposed client-side.
 Clickjacking
 Confused deputy problem
 Token validation API

21. Confused Deputy problem

22. Token validation API

23. Other grant types
 Resource owner password credentials grant
 Translate username/password to a token
 Hacky way to turn your webapp into a resource server
supporting Oauth
 Secure design considerations
 Your third party clients now have incentive to request
username and password
 “Hacky” is never good – better not to support this grant.

24. Other grant types
 Client credentials grant
 Translate your client id and client secret to a token
 Backend services, trusted internal services
 Do not use this grant unless necessary.
 Compromise of platform DB == compromise of all client
secrets.
 Preferably switch to JWT bearer grant type

25. JSON Web Tokens (JWT)
 Open standard for a self-contained way to transmit
information in a JSON object
 Can be signed
 HMAC (symmetric) / RSA (Asymmetric)
 JWT Assertion Structure
 Header - for algorithm used to sign
 Payload - set of pre-determined claims
 Issuer, expiration, audience etc.
 Allows for custom defined claims
 Signature – contains the signature for the token

26. JWT Bearer grant
 Give me a JWT, I’ll give you an Access Token
 Needs creation of keys during client registration

27. JWT Bearer grant

28. JWT Bearer grant
 Security benefits:
 Supports revocation and rotation
 Assertion material is self-contained
 Can have extremely small lifetime for tokens grants (its easy
for clients to get a new one)
 Almost similar ease of use as client credentials grant
 With more securitah!
 Supports signing and encryption
 Compromise of server DB only exposes the public keys
 The private key material stays with the developer
 Compromise of DB of a platform that supports client credentials
grant leads to immediate compromise of all services.

29. Tokens
 Access token
 Something short lived
 Refresh token
 Can be used to get a new set of access token/refresh
token pair

30. Tokens
 Secure Design considerations:
 Treat tokens like a user password / session cookie
 Limit Token Scope
 Permissions and scope pentesting.
 Determine Expiration Time
 Use Short Expiration Time for Access Tokens
 Limit Number of Usages or One-Time Usage
 Refresh Token Rotation
 Should you rotate the refresh token on every session refresh?
 Revocation of Tokens
 Endpoint to revoke tokens

32. Client Registration
 We will talk about the things a developer has to
configure
 Auth type
 Client ID and Secret
 Redirect URI
 Scopes
 CORS

33. Client Registration
 Authentication method
 JWT vs Standard User Authentication
 vs

34. Client Registration
 Client ID and Secret

35. Client Registration
 Design Considerations
 Option to rotate the secret
 Encrypt the client secret
in the database.

36. Client Registration
 Redirect URI
 Where the token is sent
 If a developer does not specify
a redirect URI?
 Open redirect
 Account Takeover
 https://cloud.app.box.com/api/oauth2/authorize?response_ty
pe=code&client_id=<client_id>&redirect_uri=<redirect_URI>

37. Client Registration
 Design Considerations
 Mandating a redirect URI
 Mandate HTTPS:
 Do I need to talk about this?
 Multiple redirect URI’s
 Redirect URI validation
 redirect_uri.startsWith(registered_value) => Not good
enough!
 Do not allow wild card characters in the redirect URI

38. Client Registration
 Scopes
 Developer chooses the scopes that he wants access to

39. Client Registration
 Design Considerations
 Granular Scopes
 Clearly define the scopes
 Scope Overlap

40. Client Registration
 CORS
 Apps making AJAX requests
 Let the developer set the domains from which AJAX
calls will be made

41. Client Registration
 API / Webapp : Token/ Cookie => ROYALLY SCREWED..!!
 Webapp : abc.com
 API: abc.com/api/
 Also… CORS set to * …... is not all bad

42. Client Registration
 Public Key Security:
 When developer chooses JWT
 Design Considerations
 Prevent duplicate public keys
 Size matters

43. App Validation Process
 Process to validate apps before making them
available to the public.

44. App Validation Process
 Things to look for here are:
 Is there prohibited content in the
name/description/images ?
 Can it be used in Phishing

45. Consent Screen
Scopes
Name of the app
Apps
Logo

46. Consent Screen
 Consent Screen on Re-Association ?
 Scope changes
 User manually deletes
the app from their account

47. User Controls
 Provide users the ability to:
 See all apps they have authorized
 Remove apps

48. User Controls
 Official Apps Section

49. Developer Security
 Developer Console:
 Compromised developer account == compromise of all
application users
 Strong password requirements
 Mandate 2FA for the developers
 Action based 2FA?
 Product is going to hate you forever
 IP whitelisting Feature

50. Q/A