Where to store tokens obtained through OAuth2 (OpenID Connect)

Question

I build an application that uses some Identity Provider (Auth0, FusionAuth, Azure AD, AWS Cognito) on user's choice.

I'm using Authorization Code flow. And i faced issue with storing tokens. I want to use Identity Provider to only user's sign in, i do not need to store who is the user (name, email etc.). I just need to authenticate user and be sure that user come from Identity Provider that i can trust.

So i have 4 questions:

1. Do i need to store tokens if i am not consider to use them to make requests to the Identity Provider.
2. If no goto 4 question. If yes i want to know what the best way to store them (save in session with db or just send them as accessToken for Header and refreshToken in cookie)
3. How i can validate access token, because as i know access token may or may not be JWT. Make request to IP on each request is not the best way, because of amount of requests.
4. Should i use my own created pair of access and refresh tokens to validate requests from Front End.

I'm only recently started investigate OAuth2 and will appreciate any answers.

As of now i have this flow:

1. From Front End (FE) user redirects to the Identity Provider (IP) to sign in.
2. IP redirects to the Back End (BE) with code.
3. BE make request to IP to obtain tokens.
4. BE validates that authorization is valid (via nonce and state).
5. BE redirects user to the FE with refreshToken in the httpOnly secure cookie and accessToken in query to store it in localStorage.
6. When FE make request to BE i validate accessToken(JWT) using jwks.

Answer 1

1. In OAuth you should not generally have to implement plumbing to build your own token stores. Eg tokens can be stored in strongly encrypted HTTP only SameSite=strict cookies. However you have to stay within cookie size limits. The best way to do this is to issue opaque tokens (such as UUIDs) to inte.net clients. The Phantom Token Pattern has more info on this.

2. You should not use foreign access tokens in your own APIs. As you are discovering, you may not be able to validate them. Also they will not have meaningful scopes and claims and you will not be able to authorize API requests properly. Instead issue your own tokens for your own APIs.

AUTHORIZATION SERVER

It is possible to issue your own tokens in code but this is not recommended. Instead, the preferred option is to use an Authorization Server. One option is the free community edition of the Curity Identity Server .

This component will take care of connections to Identity Providers for you. It will then issue tokens for you, so that your apps and APIs only ever deal with tokens from a single provider.