support RFC 8693 (OAuth 2.0 Token Exchange) for getting new One Time Password token from existing access token

[lucatmedmij]

Would be nice if duende identity server in token endpoint would support exchanging existing token to new One Time Password token.

[RolandGuijt]

Can you please tell us more about why you need this? The specific scenario? That'll help us answering this better.

[lucatmedmij]

Of course,

Scenario, you already have an access token from duende identity server for api calls backchannel(=read api), Now you get a more restrictive access token(=read One Time Password access token) from this access token to use one time over frontchannel(=read browser) with max 1 minute lifetime. Rule is that OTP token is at least always more restictive in scope and lifetime as original access token. When One Time password access token is used in frontchannel it cannot be used again. In other words OTP token when check for second time with introspect endpoint must fail even when its lifetime is within 1 minute. This with restrictive lifetime is more secure for use over frontchannel then long duration less restrictive access token. We need this for healthcare solution.

My suggestion is to use RFC 8693 (OAuth 2.0 Token Exchange) for token endpoint in duende identity server and also use token introspect endpoint for validation of OTP token.

[AndersAbel]

There are a couple of design decisions here that I would like to discuss.

The first one is if the one time token should really be possible to acquire from the access token or if a refresh token should be used. The access token has potentially been sent to various APIs and a rogue API could turn around and use the access token it received to get a one time token. In a general case this means that the refresh token and a client secret is more secure to use when requesting a custom token. In your specific case however I think it would be fine to use the access token as the new token is down-scoped and won't give any more access than the existing token. I just wanted to mention this as a possible approach (and also mention it for the record if someone else reads this thread).

The second design decision here is on how to handle a one-time-use semantic on an access token. I think that it would make sense to use a reference token for this and customize IdentityServer to revoke/remove the reference token once it's used.

All token exchange scenarios are more or less custom in that they have different requirements for different scenarios. If IdentityServer were to implement a configuration model that supports all possible scenarios, it would get very complex. IdentityServer has instead chosen to offer a clear extension scenario on the token endpoint which enables any custom requirements to be expressed in code.

Would it be possible for you to implement what you want using the provided extension model?

[maartenba]

You could implement this using a custom IExtensionGrantValidator and related extension points (potentially replay detection for your scenario).

We'll keep this feature request open for others to chime in, but your scenario seems a specific use case where a custom implementation will be better suited.