Introduction to OAuth2 (101)

Intro to Oauth2

Tuesday 1G

Convener: Justin Richer

Notes-taker(s): Garrett Schlesinger

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if

appropriate to this discussion: action items, next steps:

Justin has a full 2 day curriculum on OAuth 2

Author of OAuth 2 in action

Overview of today:

What is OAuth 2

• 3rd party apps getting limited access
• delegation protocol to allow apps to access resources on the owner's behalf
• key players:

1. rescue owner,
2. protected resource (a web API) that protects things on behalf of the resource owner,
3. the client application. the third party accessing the API. Often a web server itself.
4. • problem to solve: granting clients access to these resources.
   • old way of doing this: stealing keys (or copying keys)
   • in the new world, we do multi factor. can't just replay credentials since we're architecting more secure systems now.
   • if you can't steal it, ask for the credentials and login on the owner's behalf...
   • ... but this doesn't help the resource delineate between the resource owner and the third party. still fails int he MFA world, too, but the biggest problem is getting users into bad habits. it's the same as phishing when done maliciously, and it's not a good idea to habituate users to do this.
   • another possible solution: API key/universal key. access is much too coarse. Giving access to everything is bad.

What about service-specific credentials? A token that can only access one protected resource?

"Service-specific password" in Google's terminology. This is good. It's used a lot... doesn't leak user's

credentials. However, the UX is really bad. Forces the user to manage all of these credentials for

different apps. Okay. So let's try to make this usable.

Introducing: Authorization Server (AS). Bridges the gap between client and protected resource.

1. Generates tokens for client
2. Authenticates resource owners
3. Authenticates clients
4. Manages authorizations.

Oauth tokens:

1. Represents granted delegated authorities from resource owner to client for protected resource
2. Issued by authorization server
3. Used by client
4. Consumed by protected resource
5. No specific format... they are opaque to the client. The idea is to have a dumb client that just passes the token without knowing the format of the token.

Everybody has used Oauth... anybody who's used a FB app, an android phone, etc. And it's opaque.

You don't even realize that you're handing off these tokens.

Auth service can do it statefully or entirely self-contained a token. Self-contained makes revoking

tokens difficult. Or token introspection can help you see what a token is good for (often by calling to

a service or even the auth server).

Refresh tokens

• Once a token stops working, just do Oauth again
• Problem: this only makes sense when the user is still there. Scraping data in a long-lived process or batch, for e.g. doesn't make sense.
• However, there can be refreshes. Refresh tokens cannot be used to call resources, though.

It's just for getting a new token and needs to be generated alongside the access token. It's

not a bearer token.

• Bearer tokens exist because they work! It's easy to use them, so even though anyone who has them can use them and this isn't ideal security. Allows for the user to auth only once. Oauth is not an authentication protocol.
• Relies on authentication, but does not communicate anything about the user. However, authentication protocols can be written using Oauth.

Client cannot interpret the token, but it's recommended that your auth server can tell you what a

token is good for.

The Authorization Code Flow (canonical OAuth 2.0 transaction)

• Two forms of communication:
  • Backchannel: direct HTTP connections, server-to- server. User/browser is not involved. Instead, requires user to pass credentials to the wrong place.
  • Frontchannel: uses redirects through web browsers without direct connections. Client redirects browser to the auth server, so the auth server is getting the request. The user talks directly to the authentication server, which was the goal. Woo! Then, the result goes back the the client via another redirect. The key here is that there's something in the middle. This obviously can cause problems with man-in- the-middle attacks, but there could be problems with getting user credentials through this vulnerability even w/o Oauth.

• Step 1) client redirects to authorization server. 2) User (resource owner) authenticates to auth server... OAuth is agnostic to this auth. Auth server could do SFA, MFA, or anything it wants. 3) Resource owner authorizes client (grants scopes... "yes, you can read my profile information and see my bank transactions"). 4) authorization server redirects back to the client with an authorization code (front channel), 5) server-to- server exchange of authorization code. authorization code has a fairly tight timeout. 6) authorization server issues access/bearer token to client. 7) client uses token via backchannel. user doesn't need to be present since the client has a bearer token that resulted from the exchange.

• Layered trust model: whitelist: centralized control, traditional. blacklist: centralized control, also traditional. greylist: end-user decisions... not on a whitelist or blacklist. need extensive auditing and logging. rules on when to move to the white or black lists.

Lots of choices in the Oauth space. need to pick the appropriate one for the apps you're building!

Implicit? Authorization code? Resource owner credentials? Client Credentials? Assertion? Add

PKCE or DynReg? Very tricky decision space to manage, but once you figure out that Oauth is a good

thing, it's a crucial decision to figure out the right way to use Oauth.