Affected component
Duende.AccessTokenManagement
Version
4.1.1
Describe the bug
The IdentityToken record defines a MaxLength of 32 * 1024.
Our IdentityTokens are much, much larger than that.
Which means we cannot use the atm on our backend http clients, even though we're not depending on the IdentityToken in the refresh response.
It'd be nice if we could either:
- configure/override the max string length
- or specifiy that we accept failure of the nullable
UserToken.IdentityToken parsing
Meanwhile we're relying on a BackchannelHttpHandler that strips id_tokens from refresh responses 🙈
Steps to reproduce
- Set up an idp that returns id_tokens larger than 32K in response to token refresh requests
- add atm to a backend http client
- use the application until a token refresh is needed
Expected behavior
- the refresh requests do not throw an exception due to a large IdentityToken
Additional context
Microsoft uses a Microsoft.IdentityModel.Tokens.TokenHandler.MaximumTokenSizeInBytes property that defaults to 250K and can be set to anything up to Int32.MaxValue.
This is how we make authentication work with the really large tokens coming from the idp.
Affected component
Duende.AccessTokenManagement
Version
4.1.1
Describe the bug
The
IdentityTokenrecord defines a MaxLength of 32 * 1024.Our IdentityTokens are much, much larger than that.
Which means we cannot use the atm on our backend http clients, even though we're not depending on the IdentityToken in the refresh response.
It'd be nice if we could either:
UserToken.IdentityTokenparsingMeanwhile we're relying on a BackchannelHttpHandler that strips
id_tokens from refresh responses 🙈Steps to reproduce
Expected behavior
Additional context
Microsoft uses a
Microsoft.IdentityModel.Tokens.TokenHandler.MaximumTokenSizeInBytesproperty that defaults to 250K and can be set to anything up to Int32.MaxValue.This is how we make authentication work with the really large tokens coming from the idp.