Need information for external provider

[Rahul21199]

IdentityServer version

Duende IdentityServer- 7.0.6

.NET version

.net 8

Description

We are facing an issue with an external identity provider and need to understand if Duende offers any features that can help us.

Issue: We have an application with a web view that can be accessed using a valid access token. Another application, our Identity Server, uses the Duende framework to handle authorization flow and grant tokens.
Typically, the client initiates the authorization flow with our Identity Server, which then redirects the user to a third-party SSO for authentication. After authentication, the third-party SSO redirects back to our callback URL, and we grant a token from our Identity Server, allowing access to the web view.

However, a new client has a different flow. Their application is directly integrated with the third-party SSO. After logging in successfully, they need to access our web view page. To do this, they initiate the authorization flow with our Identity Server, which challenges them and opens the external client SSO page. The first issue arises here as they are prompted to log in again, which should not happen since they are already authenticated. They are still investigating this issue.

Now, they want to pass their client access token to us and expect us to authenticate the user based on that token, then grant our Identity Server access token/identity token to them. Is there any way to accomplish this?

Reproduction steps

No response

Expected behavior

No response

Logs

No response

Additional context

No response

[RolandGuijt]

Yes. Using token exchange. Where their access token can be exchanged for one coming from "our" Identity Server.
We have an example for this too.
The tricky part here might be the validation of the external token where an extra library could be needed.

[AndersAbel]

I would like to add that token exchange should solve this for the access token. However, it cannot be used to get and id_token, nor to establish a proper distributed OpenID Connect session across the different applications.

I would recommend looking deeper into why single sign on doesn't work with the upstream provider. If you could get that to work, it would be more in line with how the protocols are intended to be used.

[Rahul21199]

@AndersAbel
while reviewing the documentation RFC 8693 https://datatracker.ietf.org/doc/html/rfc8693#TokenTypeIdentifiers, it mentions that other tokens can be granted based on the requested_token_type. Is this not being followed here?

[AndersAbel]

Well, you can of course craft and id_token in a token exchange flow, but IdentityServer would not be aware of it. When an id_token is issued, the client should also be enlisted as participating in the session. If you just issue an id_token through token exchange, then that will not create a session on the IdentityServer.

Then there's a security dimension of it: An id_token should strictly be a business between the client and the OIDC Provider. An access token on the other hand is sent to APIs to authenticate the call. In a normal setup, there is no way that an API can get to an id_token because that is only available through an authorization flow where a registered client application interacts with the OIDC Provider. If you would allow an access token to be used to get an id_token at the token endpoint, that breaches this assumption.

[Rahul21199]

Got it. Thanks for the suggestion