OAuth is designed originally for authorization (granting permission to access specific data) that is abused for authentication (login)
Introduction to OAuth 2.0 and OpenID
Terminology:
Resource Owner: user
Client: front end application
Authorization Server: account provider
Resource Server: account provider who has user data, accessed by Access Token
Authorization Grant: permission grant
Redirect URI: after authentication finished, redirect front end to this page (with Authorization Code)
Authorization Code: Authorization Server will give front end Authorization Code embedded in Redirect URI. Backend can use Authorization Code (along with some pre-defined per-backend secret storing in the backend) to get Access Token. Front end should send Authorization Code to backend once received.
Access Token: JWT access token
Example of request to Authorization Server:
https://accounts.google.com/o/oauth2/v2/auth?
client_id=[Client ID]&
redirect_uri=https://deepvocab.com/callback&
scope=profile&
response_type=code&
state=foobar
Often nonce is provided too. When there exists no backend,
response_type=id_token
is used for obtaining access token to frontend directly (implicit flow).
Example of request to Authorization Server response:
https://deepvocab.com/callback?
error=access_denied&
error_description=The user did not censent
https://deepvocab.com/callback?
code=[Authorization Code]&
state=foobar
Example for getting Access Token:
POST www.googleapis.com/oauth2/v4/token
Content-Type: application/x-www-form-urlencoded
code=[Authorization Code]&
client_id=[Client ID]&
client_secret=[Client Secret]&
grant_type=authorization_code
Example for getting Access Token response:
{
"access_token": "[Access Token]",
"expires_in": 1024,
"token_type": "Bearer",
}
Example for making request with access token:
GET api.google.com/endpoint
Authorization: Bearer [Access Token]
OpenID built on top of OAuth 2.0 and is designed for authentication.
When using OpenID, we send scope=openid
to authentication server, the callback also provides an ID Token
in addition to Access Token. This allow the front end to know immediately who is the user without sending additional request to the backend.
OpenID also specify /userinfo
endpoint for more info from the Resource Server using Access Token.
Web Application (with server backend): authorization code flow Native Mobile App: authorization code flow with PKCE Javascript (single-paged application) (with API backend, no server): implicit flow Microservices: client credential flow
PKCE vs. Nonce: Equivalent or Not?
Table of Content