OAuth clarification

Question

I've followed a training in Go as an introduction to microservices architecture a while ago. Getting back to this project I realise that I need more context as we've been quickly digging into the details of the implementations at the time...

I've drawn a simplified sequence diagram of 2 simple use cases:

The user logs in
The user is already logged in and make a purchase

(you can comment / modify the diagram at your convenience) https://drive.google.com/file/d/1gWgkhJipUvWrVidkl7YFt_xlDmZYn_CX/view?usp=sharing

Here are the questions I have:

Here we're dealing with user authentication but what about client authentication? In the case of a web front end client, can I imagine storing an api_key and an api_secret in the env variables for the server that will be hosting this client? Because there use cases where the user is not logged but some services still needs to be available, but at the same time I only want my known clients (the web front and the mobile app) to be able to access those services (putting aside API Gateway solutions, and maybe other API Shields which would probably add another security layer against DOS etc.)
If the client logs in using Google/Facebook, the front app will receive an id_token that needs to be passed to the backend which would then verify the token ( https://developers.google.com/identity/sign-in/web/backend-auth ). In this particular case my OAuth API would not be used. Could please you confirm that it's the way it should be handled?

Many thanks.

EDIT 02/05/2022

Intro / Context

First thing first, Authorization is not Authentication.

Authentication is the process of verifying who a user is, while authorization is the process of verifying what they have access to.

And like @Max said, OAuth is designed to manage Authorization and Open ID Connect (OIDC) is an extension of OAuth to manage Authentication on top of it.

The diagram I've exposed in my question is known in the OAuth world as the password grant, and, from the official documentation :

Because the client application has to collect the user's password and send it to the authorization server, it is not recommended that this grant be used at all anymore.

Authorization of my App (to get access to my APIs)

From the API perspective, we just want to ensure that the incoming requests are coming from the server that is hosting the App. So, in my case, it's simple machine-2-machine communication from backend server to backend server and there's no action required from the user. So, I must implement the Client Credentials Flow

...which would lead me to this flow:

https://drive.google.com/file/d/1qE9JpWRSRPa8z5iNxm7ocGkeT0E149Sv/view?usp=sharing (Feel free to comment / rectify )

Authentication of a user

Because OAuth knows nothing about authentication, I need an OIDC flow. The easiest one is based on the Authorization Code Flow with PKCE from OAuth below (only about authorization) ...

... but the difference is that we're passing an additional scope named openid in the authentication request (step 3), when the app performs the 2nd request to the token endpoint (step 7), the auth server returns an ID Token (which is a JWT containing user info in the payload -> authentication) in addition to the access_token (which do not contain user info but just "random string"). There's other OIDC flows with their pros & cons depending on the situation but it's another topic on its own (https://openid.net/specs/openid-connect-core-1_0.html)

User already identified by Google/Facebook

In case the client logs in using Google, the front app will receive an id_token. This token could be sent to the app server which would then make a request to the API Gateway, which then call the Auth api which would be in charge of verifying the token by calling the 3rd party auth server ( https://developers.google.com/identity/sign-in/web/backend-auth ).

In case of Facebook, we get back an access token, so I don't know how to deal with it ...

https://developers.facebook.com/docs/facebook-login/web https://developers.facebook.com/docs/facebook-login/guides/advanced/manual-flow

Using Firebase, there's an onAuthStateChanged callback, so from the App perspective it will prevent request without the user being logged in, but from the API perspective, it doesn't guaranty that a request is coming from a logged in user...

https://firebase.google.com/docs/auth/web/manage-users#get_the_currently_signed-in_user

user_1891133 · Answer

Warning: the answer below is not complete, it only serves to give a rough idea

Intro

OAuth2 is a protocol for authorization.

Grant Types

Over the OAuth2 protocol, you can use one of the "grant types" or "flow", one of these flows is illustrated in the picture you post and named password grant.

Each of these flows is realized for different scenarios, you rightly point the attention to how securely store the password on a web app.

For example for a front-end authentication (javascript / wasm) you can use a PKCE Flow where the secret_id is not used.

Endpoints

On OAuth2 there are two primary enpoints

Authorize endpoint - where you obtain the authorization code
Token endpoint - where you exchange the authorization code for the token(s)

Tokens

There are two types of tokens on OAuth2

Access Token
Refresh Token

The definition of token on OAuth2 is "an opaque string", you don't need to read it. The access token is used against the API, this token has an expiration date, when it is expired the system use the refresh token to get another access_token whitout user interaction, when the refresh_token expire the user must re-authenticate again.

You can read the content of the access_token (which is a JWT token) from the JWT.io

Scopes

The Access token has, on its body, the scopes (i.e. Read email, read name, etc). Scope is a mechanism in OAuth 2.0 to limit an application's access to a user's account.

Identity

On top of the OAuth2 are build other protocols OIDC aka IdToken aka Open Id Connect is one of them, in other terms OIDC protocol use the OAuth2 for establish an Authentication.

With the OIDC there is another token the id_token, this token came with the user's info and is NOT used has Authorizization in front the API.

There are also OIDC flows you can use to get the id_token and/or the access_token.

Conclusion

I suggest you read about OAuth2 from the references below and try different flows using the playground

References

Which oauth2 flow should I use
OAuth2
PKCE in more depth

user_9019885 · Answer

My advice is to start with the data, which is the deeper area of OAuth.

USE AN AUTHORIZATION SERVER

This will enable you to keep your code simple. It will also handle Google / Facebook and many other forms of authentication for you, with zero impact on your code. The Curity Community Edition is a free and developer friendly option, though there are others. eg Keycloak, Ory Hydra.

PROTECT DATA

OAuth primarily gives you modern ways to protect data. Use scopes and claims to protect data across multiple microservices in a zero trust manner while securely maintaining user context. You will also need to manage joining identity and business data.

IMPLEMENT UI FLOWS CORRECTLY

Mobile apps use the AppAuth pattern. The current best practice for browser based apps is a Backend for Frontend approach. Both of these are tricky.

KEEP CODE STANDARDS BASED

All of the above Curity resources are based on OAuth related standards. If followed your apps will stay simple, with portable code, that can also work with other providers.

OAuth is very architectural though, and the best designs take time to learn, but you can learn the intricacies gradually. Our IAM Primer is a good starting point.