Spring Security 13 : oAuth2 and OpenID Connect

some website alow browser to store and refresh the token so that even if you open website after days , no re-auth needed

Two Probs that oAuth2 allows you to solve is

it stands for Open Authorization , created for "delegated authorization".
single auth mechanism encapsulated separately (may be in authn server) than the business logic

you authorize one app to access your data without giving password

delegated authn / authz (like PhotoApp wants to access google photos)

There are different types of tokens

access token : enables reading data of end user
ID token
refresh token

Grant Types : 5 types

1) Authorization Code

if end user involved, non javascript framework front end
example SLACK and google integration , sign into github using stackoverflow and xxx integration

2) PKCE :

if end user involved with javascript framework front end (like react , angular)

3) Client Credentials

no end user involved , API to API

4) Device Code

no end user involved , when two devices involved, generally for IOT

5) Refresh Token

whenever access token is expired

Implicit Flow (legacy / deprecated)

very similar to "Authorization code" , it is older flow

Password Grant (legacy)

flavor of "Authorization code" , it is older flow

OAuth1 vs OAuth2

https://medium.com/@sidharth.shukla19/oauth1-vs-oauth2-c9d36de1882b

OAuth2.1

no release date yet , based on community feedback that some grant types are confusing on when to use when

https://stytch.com/blog/oauth-2-1-vs-2-0/

https://oauth.net/2.1/

https://aaronparecki.com/2019/12/12/21/its-time-for-oauth-2-dot-1 (best)

OAuth Terminology

Using Google oAuth2

https://developers.google.com/identity/protocols/oauth2

See "Basic Flow" section above.

the app (like slack) get clientID and secret
Obtain an access token from the Google Authorization Server
+more

Why need of two separate ID & Password in Step 3 and 5

in step 3 user proves its identity by sharing its clientID and Credentials
in step 5 client proves its identity by sharing its clientID and Credentials

https://www.youtube.com/watch?v=ZV5yTm4pT8g

Difference Between Authorization Code and Access Token

https://www.reddit.com/r/webdev/comments/11pfzcr/oauth_difference_authorization_code_vs_access/

https://salesforce.stackexchange.com/questions/267618/difference-between-authorization-code-and-access-token

An authorization code is a credential representing the resource owner's authorization (to access its protected resources) used by the client to obtain an access token. It's an intermediary construct in the authorization flow sequence, you don't need to "manage" it in your application. As you correctly pointed out, it only comes in play with specific oAuth flows such as an authorization code flow (referred to as Web Server Authentication in Salesforce universe)

Access tokens are credentials used to access protected resources. Example of a protected resource is a REST API exposed by Salesforce.

Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires.

How will my resource server validate the token issued by Auth server they are two separate servers with no communication between each other ?

Ans in JWT there is a digital signature
using the digital signature you can validate it , without talking to each other

since access token is also in JWT format , it can be validated quickly

How my auth server will know which page of client app it has to land during the (1) auth code flow step (step 4) and (2) during access token flow step (i.e. step 5) ?

Ans below

Playground

https://www.oauth.com/playground/

https://developers.google.com/oauthplayground/

Difference Between oAuth and Okta ?

Auth0 is an organization acquired by okta

https://supertokens.com/blog/the-real-reason-okta-spent-on-auth0

both org have commercial products, using which org can standup auth servers

Implicit Grant Flow (deprecated)

it is deprecated for now
removed in oAuth2.1

reason why this is deprecated is because

~~it tries to share access token in single step~~
or no way for client to validate their identity.
the access token is shared as a response to GET request as a GET reponse (hence visible in URL) ... visible in browser history ( usually around for few days )

my understanding the step to validate user and client seperately is not done.
it is not sending a client secret and it does not make sense to send it either (as its a GET request)

PKCE Flow

it is a modification of Authorization Code Grant type flow , particularly step 5 ... because in step 5 client credential need to be passed and a javascript client cannot store credential securely. (anyone can see javascript code in browser )
using code_verifier the code_challenge will be derived using SHA256.

if code_verfier is 123
code_challenge will be "a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3" using SHA256
link here.

Why it is safe ?

in very fist step client shared the "code_challenge" along with client_id.
this code_challenge will be stored by auth server
4 : if user is validate , auth server sends a temporary "authorization code"
5 : then client sends authz code + client_id + code_verifier.

if server is able to match SHA256 ( code_verfier ) = code_challenge for same client_id it says success and gives "Access Token".

once hashing is completed it will be BASE64 URL encoded.

Note

in above step 5 ... client_Secret is optional
a non javascript client can also use PKCE ( as it is safest )
for every authentication flow "code_verifier" and "code_Challenge" is unique.

Why is Code challenge shared first ?

even if it is stolen it wont make sense without code_verifier

Search This Blog

Misc Learnings