Comments (7)
Hey @vpszi,
Thanks for sponsoring the project! Much appreciated ❤️
If I own and trust the OIDC Identity Provider, I guess there wouldn’t be a benefit in having separate signing keys. Can you agree?
There are actually two related - but separate concepts - at play here:
-
The provider identity (a.k.a issuer), which is returned by the authorization server as an
issuer
node in the OIDC discovery document and as aniss
claim in JWT identity tokens. This value uniquely identifies an OIDC server, so if you decide to adopt a multitenant model for your authorization server, the sameissuer
value MUST NOT be shared between instances to help prevent confused deputy attacks (otherwise, a client or resource server might tricked into accepting identity or access tokens meant to be used with a different OIDC server instance/tenant). That's what Cyberark means when they sayDo not set a single OIDC Identity Provider issuer (often referred to as the Entity ID or "issuer") to serve multiple tenants (two or more)
. -
The encryption and signing credentials used to protect the tokens. Technically, nothing prevents reusing the same set of credentials across OIDC servers/tenants. But it's really something to avoid for at least two reasons:
-
If an attacker somehow manages to steal the encryption or signing keys used by a tenant, he'll be able to not only decrypt the tokens issued by that tenant, but also by any other tenant, which is far from ideal from a security perspective. Information theft isn't the only risk since the attacker can also forge counterfeited tokens that will be considered valid by all the resource servers trusting one of the OIDC server instances and do unauthorized operations via privilege escalation.
-
Some client or resource server implementations are known to either completely skip
iss
validation or use a relaxed validation logic (e.g some implementations support wildcard domains, solegit.domain.com
andmalicious.domain.com
are considered valid, even if they point to completely separate instances). In this case, the only line of defense is the signing key used to sign the tokens: if you, as the OIDC server operator, decided to share the same signing key for multiple tenants, then there's a serious risk a client or resource server configured to trusttenant-a.domain.com
will end up accepting tokens issued fortenant-b.domain.com
(that may be operated by a malicious party).
-
Do you have any particular reason for wanting to use the same set of credentials? Any chance you could tell me more about your scenario?
Hope it was clear (it's definitely not easy stuff 😄)
from openiddict-core.
Hi @kevinchalet
Thanks for your detailed reply. I will share some background information.
Our system looks as follows:
- We have a deployment monolith that contains everything, identity provider, authorization server, user management etc.
- All tenants communicate with the same application instance and they use the same domain.
- The distinction between tenant a and tenant b depends on the
tenant
claim - not on a subdomain or any other url-segment. - Access to TenantA-Db is only granted if the current user has the claim
tenant: A
.
One could say that our authorization logic doesn't solely rely on oidc.
it's based on a higher level.
For me it looks like the argumentation assumes path-based tenant distinction.
Could it be that other rules apply for claim-based tenant distinction?
Regarding our monolithic deployment, i think that an attacker who manages to steal one tenants signing key would also be able to steal signing keys of the other tenants since they are stored in the same place. How would such an attack actually look like? An attacker would probably need access to the host system..?
Do you have any particular reason for wanting to use the same set of credentials?
Since open-iddict doesn't support multi tenancy out of the box there would be a lot of work to achieve this - especially since we share the same open-iddict code with multiple projects.
I want to see a clear benefit before extending the code.
from openiddict-core.
Thanks for sharing these details, @vpszi!
It's not 100% clear to me whether the OIDC server is itself multitenant - with a different config' per tenant - or if it's only the user part that is multitenant. E.g, where do you store the OpenIddict entities? In a shared database or in tenant-specific databases? Are your client registrations shared between all the tenants or are they tenant-specific?
Regarding our monolithic deployment, i think that an attacker who manages to steal one tenants signing key would also be able to steal signing keys of the other tenants since they are stored in the same place. How would such an attack actually look like? An attacker would probably need access to the host system..?
In general yes, but it really depends on how you implemented things (e.g I had a case a few years ago where the team had implemented a scripting logic that allowed the tenant manager to customize the OpenIddictServerOptions
instance using JS scripts: sadly, there was no check at all regarding what properties could be customized so it was very easy to extract the private signing key via OpenIddictServerOptions.SigningCredentnials
and append it to the JWKS endpoint path so it would be leaked in the OIDC discovery document 🤣)
from openiddict-core.
The OpenIddict entities are stored in the shared database as well as the client registrations (a.k.a. users).
from openiddict-core.
The OpenIddict entities are stored in the shared database as well as the client registrations (a.k.a. users).
Ah, in this case, I wouldn't really call that a "multitenant" OIDC server (tho' it's multitenant-aware as it's able to resolve the user details from the right place using a custom "tenant" claim).
Multitenant OIDC servers are generally more involved: e.g they don't share any client registration between tenants, they typically allow you to customize the enabled flows/endpoints per instance and they will generally maintain different credentials per tenant. It's the model used by OrchardCore, whose OpenID module is based on OpenIddict.
Since you essentially have a single OIDC server instance, having a single set of credentials makes sense 😃
from openiddict-core.
thanks a lot @kevinchalet
now everything is clear 😄
from openiddict-core.
My pleasure, @vpszi! Thanks for sponsoring the project 😃
from openiddict-core.
Related Issues (20)
- OpenIddict + SPA UI Question HOT 9
- Remove `Uri.IsWellFormedOriginalString()`/`Uri.IsWellFormedUriString()`
- The specified token is invalid since we renewed SSL certificate in Azure key vault HOT 14
- invalid_token returned by authorization callback HOT 14
- Claims not found in token of external provider (Microsoft) HOT 5
- Using KeyVaultSecurityKey as asymmetric signing key and/or symmetric encryption key HOT 6
- unauthorized_client when changing url HOT 6
- Using "role" claims from external providers in access tokens HOT 7
- Update the OpenIddict client ASP.NET Core/OWIN integrations to support overriding the requested scopes via `AuthenticationProperties`
- openiddict 5.0.1 => 5.1.0, breaking change when adding amr array claim to id_token HOT 5
- Enable the use of Azure Workload Identities with `.AddClient(options => { options.UseWebProviders().AddMicrosoft...})` HOT 3
- Microsoft Entra: ResponseMode "query" is not working good HOT 12
- Use TimeProvider HOT 3
- Empty string reading Httpcontext body from x-www-form-urlencoded POST HOT 4
- Revoked token is still valid for `UseLocalServer()` configuration HOT 4
- Calling AuthenticateInteractivelyAsync from api server in windows installed app HOT 9
- Calling OpenIdDict identity server from a .Net Framework 4.8 client HOT 20
- Multi-tier deployment: reverse-proxy support? HOT 3
- For testing purposes how to create a fake web provider that returns tokens from fake identity? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from openiddict-core.