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.
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
Resource Server- The application that owns the resource that should be accessed.
Authorization Server- The application that issues access tokens that allows the
Clientto access 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
Clientis acting on behalf of the
Implicit- intended for browser based applications without a backend.
Password- For trusted native clients where
Resource Serverbelongs to the same company.
Client Credentials- For clients such as web services, acting on their own behalf.
Refresh token- Allows the
Clientto refresh ones access token without doing the whole auth scheme.
SAML 2.0 bearer- Lets a client use a
SAML 2.0token 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.