Authentication and Authorization Flows
Hey guys, it's Mathieu2em here, let's talk about authentication and authorization!
First, make sure to differenciate Authorization Code flow from Authorization Code Flow with PKCE!
one is secure for an SPA and the other is not recommended !
Authorization Code Flow
Because regular web apps are server-side apps where the source code is not publicly exposed, they can use the Authorization Code Flow , which exchanges an Authorization Code for a token.
Pretty simple, right? I got a code, you got a secret room, I give you the code, you say : 'come in, my dude. '
Well for this obvious reason, if your code is all visible from the browser you shouldnt use it !
You shouldn't use this flow if you develop an SPA (single page application) which is exposed to the web.
THE SOLUTION ?
Authorization Code Flow with Proof Key for Code Exchange (PKCE)
This flow is an OpenId Connect flow! It is designed to authenticate native or mobile apps as well as SPAs for which it is (as of 2021) considered the best practice.
PKCE reduces security risks for native apps, as embedded secrets aren’t required in source code, which limits exposure to reverse engineering.
During authentication, mobile and native applications can use the OAuth 2.0 Authorization Code Flow, but they require additional security. Additionally, single-page apps have special challenges. To mitigate these, OAuth 2.0 provides a version of the Authorization Code Flow which makes use of a Proof Key for Code Exchange (PKCE)->recommended in pluralsight class Authentication and Authorization in ASP.NET Core
How does it work?
In place of the client_secret (the code I talked about for authorization code flow), the client app creates a unique string value,the code_verifier, which it hashes and encodes as a code_challenge. When the client app initiates the first part of the Authorization Code flow, it sends a hashed code_challenge.
Once the user authenticates and the authorization code is returned to the client app, it requests an access_token in exchange for the authorization code.
In this step, the client app must include the original unique string value in the code_verifier parameter. If the codes match, the authentication is complete and an access_token is returned.
So if you still dont understand, let's speak human language:
You need to proove to the Identity Provider (click here to read the article about what is an IDP) that when you receive the token, you are the same than whom asked for the tokens and provided the credentials.
So the code_verifier and code_challenge part is where everything happens
you send some hashed value (the challenge) that cannot be decrypted without the Code Verifier and you send the authorization code.
Now, the Idp send you back to your site with a one-use code.
You then send back from your site this one-use code as well as your code-verifier to the IdP to proove that you are indeed the one who initiated all this process.
The IDP validates the code verifier with the code challenge , because your code challenge can only be correctly decifered with the code verifier, then WOOHOOO he FINALLY sends you your precious little tokens
PKCE sequence diagram . source : https://auth0.com/docs/flows/concepts/auth-code-pkce
another example :
source : source link
Implicit grant Flow with Form Post
As an alternative to the Authorization Code Flow, the OAuth 2.0 spec includes the Implicit Flow intended for Public Clients, or applications which are unable to securely store Client Secrets. This is no longer considered a best practice for requesting Access Tokens
But when used with Form Post response mode, it offers an ok workflow if the application needs only an ID Token to perform user authentication.
deprecated since 2018
source : source link
the implicit grant flow vs the PKCE flow
SECURITY DANGER : Notice that after you authenticate, the Authorization Server (like Google) responds directly with tokens. This means that the tokens are in your browser’s address bar as a result of the redirect. That’s problematic since Google can’t definitively know that your browser (the intended recipient) actually received the response. It’s also problematic because modern browsers can do browser history syncing and they support browser extensions that could be actively scanning for tokens in the browser address bar. Leaking tokens is a big security risk.
These security issues led to a reassessment of the value of the Implicit flow, and in November of 2018, new guidance was released that effectively deprecated this flow.
I will not discuss these flows here but they exist : Client Credentials Flow(pretty obvious) , Device Authorization Flow.
I hope this article has been helpful for you !
Dont hesitate to leave a comment and share me what you tought about this post! :D
Have a great and secure day/night/apocalypse/whatever .