You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When configuring JWT token issuer to generate new tokens without revoking the previous one, a token binding (request binding) with a random value should be generated so that the user + application + scopes + binding combination is unique for each request. This is been handled at the default JWT token issuer implementation [1].
On the other hand, the AbstractAuthorizationGrantHandler is also validating whether there's no token binding on the request and in such case is returning a constant token binding value (NONE) [2]. This leads to a scenario where all token requests for the same user + application + scopes will have the same token binding, which in environments with high workload and concurrency causes stuck threads at [3].
How to reproduce:
Add the following configuration to the deployment.toml file:
Configure an OAuth2 service provider and enable client credentials grant type.
Add a breakpoint at line [3].
Request a token for the configured application using client credentials grant type.
Evaluate the value of the tokenBindingReference variable at line [3].
Expected behavior:
The getTokenBindingReference() method of the AbstractAuthorizationGrantHandler class should have the same logic than the JWT token issuer [1], that is, check whether the generate new tokens without revoking the previous one feature is enabled and in such case generate a random value for the token binding if there's none already.
The issue has been resolved, and the fix has been merged into the master branch [1]. Additionally, the migration documentation has been updated. Therefore this issue is can be closed.
Describe the issue:
When configuring JWT token issuer to generate new tokens without revoking the previous one, a token binding (request binding) with a random value should be generated so that the
user + application + scopes + binding
combination is unique for each request. This is been handled at the default JWT token issuer implementation [1].On the other hand, the
AbstractAuthorizationGrantHandler
is also validating whether there's no token binding on the request and in such case is returning a constant token binding value (NONE
) [2]. This leads to a scenario where all token requests for the sameuser + application + scopes
will have the same token binding, which in environments with high workload and concurrency causes stuck threads at [3].How to reproduce:
deployment.toml
file:tokenBindingReference
variable at line [3].Expected behavior:
The
getTokenBindingReference()
method of theAbstractAuthorizationGrantHandler
class should have the same logic than the JWT token issuer [1], that is, check whether the generate new tokens without revoking the previous one feature is enabled and in such case generate a random value for the token binding if there's none already.Environment information:
[1] https://github.com/wso2-extensions/identity-inbound-auth-oauth/blob/a44d65f762a1b7b9d9c41edc43e34685ab7f8ec2/components/org.wso2.carbon.identity.oauth/src/main/java/org/wso2/carbon/identity/oauth2/token/JWTTokenIssuer.java#L985-L993
[2] https://github.com/wso2-extensions/identity-inbound-auth-oauth/blob/a44d65f762a1b7b9d9c41edc43e34685ab7f8ec2/components/org.wso2.carbon.identity.oauth/src/main/java/org/wso2/carbon/identity/oauth2/token/handlers/grant/AbstractAuthorizationGrantHandler.java#L1155-L1167
[3] https://github.com/wso2-extensions/identity-inbound-auth-oauth/blob/a44d65f762a1b7b9d9c41edc43e34685ab7f8ec2/components/org.wso2.carbon.identity.oauth/src/main/java/org/wso2/carbon/identity/oauth2/token/handlers/grant/AbstractAuthorizationGrantHandler.java#L170
The text was updated successfully, but these errors were encountered: