loading...
Cover image for OAuth Tips for the Uninitiated

OAuth Tips for the Uninitiated

antonfrattaroli profile image Anton Frattaroli ・3 min read

Devs are hyped to unload the identity management parts of their apps onto an OAuth provider(s). You know OAuth is a good thing, but you don't have a good grasp on what the impacts will be to your organization. Here are some tips that'll get you comfortable with it.

Decoupling Authentication and Authorization

Customers/employees are now typing their usernames and passwords directly into your websites. If they are inactive for 15 minutes, they get logged out automatically and need to provide their usernames and passwords again to get access. When a user registers, they're creating an identity that is authorized for that website, and that website only.

An OAuth service alone doesn't do much. It needs identities - so it gets hooked up to one or more identity providers. Users will type their usernames and passwords into an identity provider's form to authenticate. That identity provider is handling the authentication part for the OAuth service.

The OAuth service allows users to authorize (registered) applications to use their identity (and possibly other information). Once the user has authenticated with the identity provider, the OAuth service gives the user a token for use on those authorized applications. The token is proof that the user is who they say they are. Your website offloads authentication to the OAuth service (through the OAuth service's identity provider(s)), and only requests authorization to use the identity. With the OAuth service handling authorization and the identity provider handling authentication, authentication and authorization become decoupled.

The internal features of your applications are still under your control, independent of the OAuth service (unless you want them to be).

Short-lived Tokens

Once a token is given out, it can't be taken away (as long as you're using standard JSON web tokens). That's a good thing and a bad thing. Good because it means you don't have to worry about it after you've given it out. Having to track all of those tokens would be a significant amount of overhead you don't need. The bad part is that if someone else gets a hold of that token, they can use it too.

That's why tokens need to have a short lifetime. Say, 20 minutes max until expiration. If someone else gets it, they have at most 20 minutes to do damage.

Refresh Tokens

But you don't want your users re-authenticating every 20 minutes. So when they authenticate the first time, they get two tokens - the Access Token (the 20 minute one) and the Refresh Token. Refresh Tokens are used by your website to say "Hey OAuth provider, my user is still using our services so they need to refresh their Access Token". And the OAuth provider hands out a new Access Token and everyone is happy. The OAuth provider is tracking those refresh tokens, and because of that they can last a long time - a six month or more lifetime on a refresh token is considered reasonable.

That does mean more coding for your website. If services start giving "Unauthorized" errors, the access token probably expired and needs to be refreshed.

Security Process Impacts

It's nice that today, you only need to flag a user account and their authentication quits working, and they can't use your systems anymore. But remember we decoupled authentication from authorization, so you need to have a plan for revoking their refresh tokens, too.

Moving Forward

And then, now that your authentication endpoints are consolidated, maybe you could look into multi-factor authentication and really nail the user experience of the "Forgot Password?" functionality.

Notes

This article is intended as a response and complement to this super-high quality article:

Ganked image from Google Image Search's "labeled for reuse" tool, illustration by Bauke Schildt

Discussion

pic
Editor guide
Collapse
anabella profile image
anabella

Thank you! This cleared a couple of things for me. If you don't mind, I have a couple more questions:

  1. We handle authorization only when serving our own resources, right? Aren't the OAuth provider's resources (the ones that we got access to, life Google profile information) still handled by them, authorization-wise?

  2. I'm interested in what you mentioned about tracking the tokens (or not). What does that mean exactly, how are they "tracked".

  3. Does the refresh token's life span "restart" every time it is used or is their expiration unavoidable? What happens when they expire, do I need to log in again?

Ah, yeah. I almost never mean "just 2" when I say "a couple of X" 😅

Collapse
antonfrattaroli profile image
Anton Frattaroli Author
  1. Yeah, sorry that's very misleading and I'll fix it. [Update: fixed]

  2. Refresh tokens stored in a database. Tracked as in their existence is persisted in a database, but I assume someone is already using that in a creepy facebook-tracking you sort of way.

  3. Can be a sliding expiration. Can be set to never expire too. Some companies want re-authentication like they want you to reset your password.

Collapse
anabella profile image
anabella

Beautiful <3 Thank you again!

Collapse
mortoray profile image
edA‑qa mort‑ora‑y

If you care about your users privacy and security you should not use OAuth as an authentication mechanism. For integration sure, but nothing else.

mortoray.com/2014/02/21/the-danger...

Collapse
antonfrattaroli profile image
Anton Frattaroli Author

In regards to the arguments in the article, it could have just as easily been titled "The dangers of SAML/Social Login".

There are a lot of parts that don't need to be coupled in the way the prepackaged identity/OAuth solutions provided by social media companies do. For example, you could use Facebook as an identity provider for your own SSO service be it using OAuth or SAML.

That example doesn't address the issues you've pointed out, but conflating social logins with OAuth in general would be counter-productive.

Collapse
mortoray profile image
edA‑qa mort‑ora‑y

Yes, the article is about social login. I have yet to see a situation where an OAuth is not some other website however -- do people use internal company OAuth providers?

Thread Thread
antonfrattaroli profile image
Anton Frattaroli Author

Yeah, using them is a monotonous task of configuring identity providers and service providers, and the SSO protocols become abstracted away and lines get blurred.

I feel like there are a lot more on-premises offerings than there had been in just the last few years. Maybe the OpenID Connect specification helped?

One solution is to validate tokens at the load balancer, to offload validation from the applications. In mid-2017 F5 added an OAuth provider to their application launcher software and I wonder if it was to address that specifically.