Approach One: Each Customer has an Oidc Client
Every Customer is represented by an oidc Application, At least one Group, One Identity Provider, and their own security policies:
This is perfect for customers that have apps like customer_x.theirapp.com.
Approach Two: Multi tenants per customer app AKA Hub and Spoke
Now if needed we can actually represent multiple apps/tenants and isolate them to their own tenants. So 1,000 customer means 1,000 tenants if needed:
Keep in mind, even though we can do this, a valid question to ask is if this is worth the overhead. The first approach is less overhead so that is a more typical recommendation.
Approach Three: One tenant, and One App
The final approach is using one Okta tenant, and one Oidc application to map multitenancy in Okta:
Here we have one OIDC application where multiple customer groups are present but we use one oidc client. When a user logins you would just extend the login code via an inline hook or custom logic to check the user access the specific url is in the specific group.