Anton FrattaroliDevs 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
