Reputation: 1
I have a scenario where a client will need to call my server to handle an OIDC login. They will pass in an identifier to indicate the identity provider to use. Sometimes the IdP is internal and I will be able to authenticate through in-house APIs, which is the normal scenario.
However, at other times the IdP is external and I will need to forward the user to login at the IdP. When the user completes this nested auth flow, they will be redirected to my server. The auth code will be exchanged for tokens and identity established. Part of this identity is an account number that the nested identity has that maps the authenticated user to my system. My server will check on the status of this account number and if everything is good, it will mint new tokens that will be returned to the original client.
When the client needs to call the refresh token flow, my server will call the nested server and validate that the token is still good to cover revocation scenarios. The key here is that all of the tokens returned to the client are issued by my server and consumed by my resource providers. The client does not know about the nested OIDC flow that may be happening.
So is this technically possible with OpenIddict?
Upvotes: 0
Views: 270
Reputation: 42100
The key aspect to remember is that OpenIddict doesn't care about where the user identity comes from: it can be from a local database (e.g using ASP.NET Core Identity), an external provider or even a fake/hardcoded identity.
For the scenario to work, the OpenIddict authorization server app must also be an OIDC client for your other provider. See https://github.com/openiddict/openiddict-samples/tree/dev/samples/Velusia/Velusia.Server for an example of an OpenIddict server app also using the OpenIddict client to delegate authentication to GitHub.
Upvotes: 0