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
Top comments (7)
Thank you! This cleared a couple of things for me. If you don't mind, I have a couple more questions:
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?
I'm interested in what you mentioned about tracking the tokens (or not). What does that mean exactly, how are they "tracked".
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" 😅
Yeah, sorry that's very misleading and I'll fix it. [Update: fixed]
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.
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.
Beautiful <3 Thank you again!
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...
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.
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?
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.