O F’ing Auth 2.0 (a.k.a OAuth 2.0)
Due to work (why else would you want to…), I have learned OAuth 2.0 then forgotten it, then relearned it then reforgotten it again, many many times. It is just somehow so unintuitive to me that my brain chooses to forget it no matter how many times I’ve forced my brain to learn it. This is an attempt at jotting down the key, or more adequately for me, confusing terms and concepts so I can recall WTF OAuth 2.0 is and isn’t quickly. I have no hope of it staying in memory so a personally tailored digest would be useful.
OAuth vs OpenID?
OMG… talk about adding salt to injury! This deserves its own article. But for now, just know that OpenID extends OAuth 2. OAuth is intended for delegated authorization, and OpenID is intended for federated authentication. That is, OpenID let’s you know more about the authenticated user via the “id_token” property as part of the access token returned.
Authorization grant types? Grant types? Flows?
They mean the SAME thing! Many times I come across the term “OAuth grant types”, I’m like WTF is this grant type thing again…? Only to realize again after some digging that OAuth grant types maps one-to-one with OAuth flows. Personally I prefer “flows” much better because it naturally describes the steps one must goes through to get the access token.
OAuth 2.0 Grant types / flows
- Authorization Code Flow
Used by server-side websites/services/relying parties/clients/apps (yes, they all mean the SAME thing!! Argh!!) that is able to keep its client secret for authenticating with the identity provider. A phone app or browser-side (Note I did not use the term “client-side” to avoid confusion with the “client” in OAuth context) app cannot use this flow because the client secret would be exposed to the user.
2. Implicit Flow
You cannot get the refresh token using this flow. The implicit flow/grant type is used for phone apps and browser-side apps.
URI with embedded fragment (stuff after # in URI)
3. Resource Owner (Password) Credentials Flow
Try not to use this whenever possible! This flow let’s user provide his/her username and password for the Identity Provider directly to the client/app/relying party/website. This is obviously let’s the client/app do whatever it wants with user’s identity data since it can impersonate as the user directly.
4. Client Credentials Flow
This flow allows the client/app/relying party to use its own app/client ID and secret to authenticate and authorize itself to read and write its own account information. Potential actions include updating redirect URI, app description etc.
5. Refresh Token Flow
This let’s the app/client request for a new access token using the refresh token.