Asking again because the question was raised by ou...
# ory-network
a
Asking again because the question was raised by our clients once again. What i'd like to avoid is to have multiple « Login with Okta » button on our login page, and ensure the setup remains simple.
s
I consulted chatgpt and it seems this is not possible, but somehow this is a complex topic. We'd recommend that you set up organizations https://www.ory.sh/docs/kratos/organizations and use one client per tenant. With the organization feature, only the relevant provider will be shown to the user, so you can configure multiple.
This was chatgpts answer You can use a single OAuth2 client in Okta to authenticate users across multiple organizations, but this approach requires additional considerations for routing and trust relationships between Okta tenants. The feasibility depends on your requirements and the nature of the multi-tenant setup. Here's how you can use one client: --- ### 1. Using a Single OAuth2 Client for Multi-Tenant Authentication A single OAuth2 client can work if: • Each tenant's Okta instance trusts your central Okta tenant or federated identity provider. • You can dynamically route users to their specific Okta tenant during login. --- #### Centralized OAuth2 Client Configuration 1. Set Up the Central OAuth2 Client: • Create one OAuth2 client in your main Okta tenant. • Configure it with the appropriate redirect URI and scopes (
openid
,
email
,
profile
). 2. Establish Trust Between Okta Tenants: • Org-to-Org Federation: Other Okta tenants (organizations) need to trust your central Okta tenant. This can be done using SAML or OpenID Connect federation. • When a user from an external Okta tenant logs in, their tenant redirects them to your centralized OAuth2 client for token issuance. 3. Dynamic Discovery of Tenants: • When users attempt to log in, use their email domain or another identifier to discover their Okta tenant. • Redirect them to the proper Okta authorization endpoint:
Copy code
https://{tenant-domain}.<http://okta.com/oauth2/default/v1/authorize|okta.com/oauth2/default/v1/authorize>
• Once authenticated, the user's tenant exchanges information with your central Okta tenant. --- ### 2. Challenges of Using a Single ClientTenant Trust Setup: • Each tenant must configure a trust relationship with your Okta instance or use federation. • This requires coordination with every tenant, which can be cumbersome if you have many tenants. • Token Validation: • The ID token will be issued by the user's tenant, so your system must dynamically validate tokens using their tenant's public JWKS endpoint. • Dynamic Routing: • Your application must handle the logic to route users to their respective tenants and accept tokens from multiple sources. --- ### 3. Using Separate Clients for Simplicity If establishing trust relationships is not feasible or too complex: • Create one client per tenant in their respective Okta instances. • Use a centralized configuration in your app (or Ory Kratos) to manage these clients. --- ### When to Use Separate vs Single Clients | Scenario | Recommendation | |-------------------------------------------|---------------------------| | Few tenants, manageable trust relationships | Single OAuth2 Client | | Many tenants, varying configurations | Separate Clients | | Independent tenant management required | Separate Clients | | High centralization and control desired | Single OAuth2 Client | ---
a
Yes, I made a lot of search since my post, and everything points in the same direction: no way to have multi tenant apps. Thank you, I'll check the organization part!
@steep-lamp-91158 do you think it's possible to get in touch with someone from Ory? My understanding is that Organizations are only available on Growth plan, which is a bit overkill for our size.
m
Hello @ambitious-notebook-80494 happy to help out here. I'll write you a DM.