The usual process is to:

• Choose an Authorization Server (AS) eg Okta
• Your apps only ever interact with the AS
• The AS manages connections to IDPs for you

Your apps use a security library when they interact with the AS:

• APIs might use JOSE to validate JWT access tokens and get public keys from the AS
• A React SPA might use a different library, eg the Okta one you mention - more on this shortly

A good goal is to keep application code based on standard OAuth messages, so that you could switch the AS to a different one with zero or only minor code changes. The Okta library looks good here - similar to oidc-client.

Identity Providers

The Okta system and its library is pretty standards based but not all IDPs are unfortunately. So if you use the Okta library to connect to OneLogin or Google you are likely to find incompatibilities and problems. If you use an AS it will deal with these for you.

Requirements

If you are building React SPAs then you should also clarify the behavior you want in the browser:

• The Okta library uses the traditional SPA flow and stores tokens in the browser. The only way for it to work reliably is to store refresh tokens in local storage, and this is not considered the most secure option.

For a more secure approach (but also a more complex flow), see my Token Handler blog post.

Anyway, hopefully all of the above provides you with some useful background for your own technical choices.

try to use a generic SDK instead of the one provided by a specific identity provider if you want to support multiple IdPs.

here is an example: https://github.com/IdentityModel/oidc-client-js