The number of choices for automating login authentication is a messy alphabet soup of standards and frameworks, including SAML, WS-Federation, OpenID Connect, OAuth, and many others. Today I will take a closer look at OAuth and recent developments that favor this standard.

The idea behind all of these standards is to automate the login process, so your users don’t have to remember their many login and passwords for connecting to various resources. That sounds great in theory, but getting the automation to work properly isn’t always easy or obvious. To pull this off, you have to conquer some technical challenges that involve just-in-time user provisioning, adapting to consumer-based SaaS services as well as supporting enterprise apps, and understanding exactly how they provide the automation itself.

OAuth began its life about seven years ago as an open standard that was created to handle authorization by Twitter and Google. It has seen a lot of revisions since then. OAuth now has two different versions in current usage; v2 is the most recent and more capable and more widely used. The two aren’t compatible and rely on two different sets of standards specifications (more specifically, RFC 5849, superseded by RFC 6749).  Today OAuth has dozens of supporters.

A good example of how OAuth is used is when two websites are trying to accomplish something on behalf of a user: both of them have to figure out how to approve the user and get that unit of work done.  If you have to think of it as something, don’t call it a protocol: it actually is the authorization plumbing inside the authentication protocols. A good explanation of the more technical underpinings of OAuth and its relationship to authentication and OpenID and SAML can be found here.

Okay, so having gotten that out of the way, where does OAuth show up in security practice? Typically, enterprises adopt OAuth through using a single sign-on tool, such as Ping Identity, Okta, or SecureAuth. These tools control the overall login process by connecting an identity provider, such as Active Directory, with a collection of applications. The actual process is that instead of a user directly entering their username and password into an app’s login screen, they work with an identity provider that encrypts and then federates their credentials to the apps as part of the authentication process. Once this chain of events is setup, a user doesn’t really see what happens: they click on an app and they are logged in properly. Corporate security managers like this process to be hidden, because then they don’t have to worry about resetting individual users’ passwords.

Another example is with iBoss’ Web Gateway Security. iBoss makes use of OAuth to integrate its security policies with users’ Google accounts to cover BYOD situations and manage guest wireless access. A customizable captive portal automatically binds these BYOD users to a variety of directory services including Active Directory, eDirectory, Open Directory, and LDAP.

Earlier this year, Google updated its G Suite with the ability to do OAuth apps whitelisting. This means that a site administrator can have more granular control over what third-party apps do with G Suite data. You can set up permissions for specific data types, such as allow access to your staff’s Google Drive documents but not their contact lists, for example. This prevents rogue apps from accessing data unintentionally.

OAuth isn’t perfect: attackers can still phish a user’s credentials during the authentication process using man-in-the-middle attacks, which is one of the reasons why Google is providing more control over OAuth across its SaaS app suite. And OAuth also doesn’t provide encryption or client verification: you will need to employ Transport Layer Security for these protective features. Nevertheless, it is being used for more apps and gaining wider acceptance, and should be a part of your security toolkit.