I made this note for a quick reference to my future self.
OAuth 2 aimed to replace traditional session based auth, because of security and management issues.
OAuth was originally designed to handle only authorization and not authentication.
Terminology
Resource Owner
User who own the data, the one who is trying to log in. You.
Client
The app requesting your data. eg. Calendly
Authorization Server
Server that verifies user's identity. eg. accounts.google.com
Resource Server
Server that hosts resources needed by client. eg. api.calendar.google.com
Authorization Grant
Permission from authorization server. aka auth code
Redirect URI
Where to pass authorization grant. (usually back to client's servers) eg. api.client.com/callback
Access Token
Token for accessing resources from Resource Server
Response Type
It can be either token or code. Code is more secure involving back channel. Passing response type=token would give you access token directly without authorization grant (auth code).
Scopes
Specific granular permissions. list of scopes that authorization server understands. Client sends list of scopes to request data. eg. Permission to read your age, email, name etc.
Consent
Consent screen popping up when signing in. eg. Consent screen when logging in with Google
Back Channel - highly secured channel
Backend server of client, eg. python code running in Calendly's servers
Front channel - less secured channel
Browser, eg. Javascript Calendly app running on user's browser
Flows
Flow, in laymen terms, means "the login/signup flow" -- process of app requesting access, user providing consent, token generated and passed back to client. There are 4 flows supported:
- Authorization code (front channel + back channel)
- Implicit (front channel only)
- Resource owner password credentials (back channel only)
- Client credentials (back channel only) ## Problems with OAuth 2.0 for Authentication
- No standard way to get users information
- Every implementation is a little different
- No common set of scopes ## OpenID Connect Introduced to solve the authentication problem. It is a small layer on top of OAuth. ### OpenID scope the only new thing added. this mean the flow is now OpenID connect flow. ### ID token similar to access token, but used to identify user instead of authorizing them within some scopes. it is JWT token.
Claims
JWT token has 3 sections. header, signature and body. body is also known as claims or payload. claims is decode by the application and can be used to retrive user data.
/userinfo
this endpoint is implement by the auth server as a standard. the client can hit it to get basic info like name, email and profile pic.
Reference
This is an excellent presentation by Nate Barbettini, who clearly explains OAuth2 in simple terms. Highly recommenced watch.
Top comments (0)