The World of OAuth Part 1

To prepare for a meeting I needed to read up on OAuth, and I would say it was really nice. Especially I liked how OAuth2 lightened the protocol by pushing the security concern over to the TSL protocol. In my view it seemed that OAuth 1 was giving a bit too much flexibility to the implementer. I also liked how the handshakes were being performed to ensure that the actors were who they said that they were. I feel like this kind of flows is a way of thinking that will become more and more common. It seemed familiar to me once I started to read up a bit on Web Hooks. It seems that this concept is to some extent using the same kind of token concepts as OAuth to ensure being safe.

Still, I find that OAuth has been eluding me. How does it really work? When reading up on it I understand why it has been eluding me. It is because OAuth2 is not just one flow. It is many.

Terminology

We have four parties:

• Client - The application that wants to get access to a specific resource.
• Resource Owner - This is typically you. The entity that wants to grant access to a resource to a Client.
• Resource Server - The application that owns the resource that should be accessed.
• Authorization Server - The application that issues access tokens that allows the Client to access the Resource Server.

The Client can get access to the resource by presenting the correct Grant to the Resource Server. The Grant is basically the proof that the Client should be allowed access to the resource. There are different type of Grants available in OAuth2:

• Authorization Code - Typically used by web applications. Uses single sign-on to verify that the Client is acting on behalf of the Resource Owner
• Implicit - intended for browser based applications without a backend.
• Password - For trusted native clients where Client and Resource Server belongs to the same company.
• Client Credentials - For clients such as web services, acting on their own behalf.
• Refresh token - Allows the Client to refresh ones access token without doing the whole auth scheme.
• SAML 2.0 bearer - Lets a client use a SAML 2.0 token to get an access token
• JWT bearer - Lets a client with a JWT assertion from one security domain get OAuth 2 token for another domain.
• Device - For devices with constrained input
• Token exchange - Lets applications obtain token in delegation or impersonation scenarios.