OAuth 2.0 and OpenID Connect (OAtuh 2.0 in depth)

https://www.youtube.com/watch?v=996OiexHze0&t=96s&ab_channel=OktaDev 

 

 

 

History

basic security from has some downsides on security and maintenance

 

OAuth 2.0 terminology

Resource owner = me , who owns google account

Client = application , here yelp.com

Authorization server = accounts.google.com (clicking yes)

Resource server = api that holds actual data that client want to access, contacts.google.com api

sometimes Authorization server == Resource server

Authorization grant = it proves user clicked "yes" and client have premission to some contacts api

Redirect URI = callback, where should i go next when user click "yes"

Access Token = client need this, it can access to Resource server

owner allow client and click "yes" and gives authroization code -> authroization server validates and give access token to client

 

More OAuth 2.0 terminology

Scope = level of permission , list of permisssion

Consent = client is asking form permissino about A,B,C are you going to allow this?  it can be very explicit

 

Even more OAuth 2.0 terminology

Back channel (highly secure channel) = https , going through my backend server to some other systems with secure path

Front channel (less secure channel) = browser , with chorme developer people can see my code or query parameters , not trusting fully

dashed line = back channel , for secure thing

solid line = front channel , to interact with user easily

to get access token not only you need authorization code but with client's secret key

 

 

OAuth 2.0 flows

Authorization code (front channel + back channel)
Implict (front channel only)

Rsoruce owner password credential (back channel only)
Client credentials (back channel only)

 

every other company , facebook, microsoft is adding little code to OAuth 2.0 to resolve authentication issue

so OpenID Connect is here to combine all different implementation detail about authentication

 

 

at starting point we are asking for openid in Scope

we get access toekn and ID token which let client know who is authenticating

 

 

now actual app is sperated from authentication and authorization

both can evovle seperately