I think I mentioned once or twice that OAuth2 is not for authentication. It is rather a set of patterns for doing delegated authorization for HTTP/Web APIs using access tokens. But most people don’t use it like that.

OAuth2 is far from perfect and regardless of what you might have heard about it (see here)– it has some concepts that are useful for the architecting “modern applications”.

Making the client a first class citizen
Unlike in enterprise development where everything is typically part of a big trusted subsystem, OAuth2 takes the software that the human is using to access services into account. Many of my customers are building applications that revolve around a set of Web APIs and a set of client applications that will access them. Sometimes these client applications will be built by themselves, sometimes by a trusted partner, sometimes by some (unknown) third party. Sometimes these apps are side-loaded, sometimes deployed via an app store (sometimes they are just normal old-school web applications). The user (aka the resource owner in OAuth speak) might even use multiple clients throughout the day to access the same backend services.

Clearly we need a way to deal with multiple clients and even multiple client types (server vs client vs devices apps). And even if OAuth2 out of the box has not a good answer for everything, it is important to make that fact a fundamental part of the security architecture.

The concept of consent
Again, this might not apply to every situation (and also might not be perfect), but giving users information about what permissions a client will get and – more importantly – giving them a choice is a nice feature.

Access tokens are so much better than usernames and passwords
Well we all know that. OAuth2 goes long ways trying to minimize the exposure of “master secrets” like passwords. Either by exchanging the password with an access token very early in the process, or by giving the client no access at all to the passwords. Access tokens can have limited access to a resource, they can be renewed, they can be revoked – and they are not passwords that might end up unprotected on some client device.

Cross-platform
That’s pretty much a requirement these days. OAuth2 uses HTTP primitives to make it work on arbitrary OSes and devices.

Modeling application resources
Scopes are a way to logically group functionality in your application, e.g ‘Read data’ or ‘Delete data’. Combined with the concept of a client, you can model applications quite nicely. Especially when your OAuth2 authorization server is feature rich enough to control which client can use which flow and can request which scope for which application etc. This makes for a nice abstraction layer and provides coarse-grained authorization.

The resulting access token can contain information about the audience (application), the scopes (permission), the subject (resource owner) and the client (the software used). The resource server can go from there and provide its part of the authorization story.

Works for me.