Steps: 1. Request to login 2. Server sends user to identity provider or authorization server 3. Perform authentication - grant the requested authorizations 4. We don't immediately get back an access token, instead authorization code is received which is used by the web app 5. Client ID, client secret & above auth code can be used to hit the /token endpoint -> gets back the access and refresh token Done entirely via backend, and since it requires client secret, it can not be used for microservices

Single page apps and mobile apps where there is not way to keep a client-secret(source-code is in the hands of user where they can decompile it and get any credentials needed in the browser), PKCE flow is used. 1. Doesn't use client secret 2. Client Application generates a code verifier 3. Generates a code challenge from Code Verifier 4. Code challenge is sent with authorization request 5. After successful authorization, auth server responds with auth-code like above 6. Application exchanges auth-code for the tokens, it has to send code-verifier in the request

Client applications that are not acting on behalf of a user, but rather accessing resources on their own behalf 1. client sends a request to the auth server for an access token, including its own credentials (such as a client ID and secret) in the request. 2. auth server authenticates the client and verifies the necessary permissions to access the requested resources. 3. Client successfully authenticated -> auth server issues an access token. This token can then be used to access the desired resources.