What is OAuth 2 flow?
Your thoughts?
OAuth 1.0 had a single flow. This made OAuth 1.0 suck because it didn't play well with different application types...
Enter OAuth 2.0 and the wonderful wide world of grant types...
1) Authorization code: User is redirected to auth server to enter their username/password. An auth code is returned and the client then uses this to get an actual access token.
2) Implicit grant: Don't use this. It was meant for public clients to get access tokens without needing to go through a backend server or hit some third party authorization endpoint. We can thank CORS for this. Don't use this in 2023...
3) Password: Just don't use this. It's a technicality and using free public Wifi is more secure.
4) Client credentials grant: This is commonly used when an application wants to access resources IT OWNS. This is different from an end user and is considered "service to service" communication. Since a server can securely store sensitive information like client ids and client secrets it can simply pass the username/password as a Bearer token to get an access token...no redirecting end users because it IS the end user for this use case...just make sure you use HTTPS :).
OAuth 2 flow is the second version of OAuth 1
"flow" = "grant types"
OAuth flows with the universe
The OAuth 2 flow is actually a collection of different "flows" or grant types.
The most popular flow (involving end users) is the authorization code grant type. This flow involves redirecting a user to an authorization server where they sign in to validate their identity. Once authenticated, the authorization server sends back an authorization code to the client. The client then uses this authorization code to obtain an access token, giving it limited access to protected resources on the resource server.
Another popular flow is the client credentials grant type. This is popular for service-to-service communication where applications want to access protected resources they have access to (unlike an end user using an application). When an application wants to access resources it owns, it can register with the authorization server and simply pass a cilent id/client secret as a Bearer token in request headers to get an access token.
A less popular / recommended flow is the implicit grant type. With this flow, public clients get back an access token WITHOUT first authorizing. This has some serious security vulnerabilities but was originally intended to help single page web apps address CORS issues.
An even less popular flow is the password flow. This literally involves passing along the user's credentials (username,password) to get a token. This is reserved for special use cases where legacy desktop apps require username/password etc. It is largely not recommended to use in the real world.