OAuth2.0 and OpenID
Today i will briefly describe the concept of OAuth2.0 and OpenID. OAuth2.0 is an implementation of delegated authorization. When client wants to access a piece of data resource, the resource owner does not make the decision. Instead, the authorization decision is delegated to a third party authorization server.
The screenshots are from Nate Barbettini’s presentation at Okta.
- Authorization code flow
It is used when web client requests permission to access data in other servers. In the example below, yelp.com requests access to contacts at google.com
Authorization code comes with front channel and back channel. Front channel is associated with web client. Back channel is purely in the backend.
2. Implicit flow
Implicit flow is happening in front channel only.
The contrast of implicit flow and authorization code flow is shown below.
3. Client credentials flow
Authorization server provides access token directly to the requesting app (used in web service). It does not requires login.
Next, we combine OAuth2.0 and OpenID. As stated below, OpenID is used for authentication (to verify who you are) while OAuth2.0 is used for authorization (to determine what you can do).
4. OpenID connect authorization code flow
The diagram below is similar to OAuth2.0 authorization code flow. Do take note, the scope is openid profile instead of profile contacts, and the authorization code is exchanged for access token and ID token. The user info is retrieved with access token.
The contrasts of OAuth and OpenID connect is shown below.
An example of web application with server backend, using openID connect authorization code flow, is shown in the diagram below.
An example of native mobile app using openID connect authorization code flow with Proof Key for Code Exchange (PKCE) is shown below.
An example of SPA with API backend using implicit flow is shown below. (can use authorization code flow + PKCE as well)
Finally, a general recommendation of OAuth2.0 grant type based on use cases is shown below.