[Removal of Token Persistence] Revocations due to internal events : Application Events

[chamilaadhi]

Description

Subtask of #1664

In the cases where the tokens are revoked without calling the revoke endpoint (application deletion, password change), we won't have the token meta data. In such cases, there will have to be an additional validation of top of data in a table. We will have to implement mechanism to handle this.

Example, there is a token coming for introspection and we have regenerated the secret for an application, we should have a entry such as the tokens generated by this app containing this consumer key before this time is invalid.

Example: When the secret of an application with consumer key “abc” is re-generated at 10.00am on 25//03/2023, a rule has to be generated such as ‘the tokens generated by application having consumer key “abc” before 10.00am on 25//03/2023 are invalid’.

Initial plan is to have an interface with data. We can later decide where we should send these. (Redis, or DB). We can have “return true” for the default implementation. Entries are not deleted from the cache.

Handle user activities. Validate application deletion

Extension is available to capture the events. (UserOperatonEventListener, separate events). Capture the events and update the rules. The DAO and storage mechanism should consume these.

Entries should be persisted. Can't remove or clean.

In the comments We will share more details about the architecture.

[prasa7]

We has a design review about the feature and following is the update of it.

Main points to be addressed are listed below,

• Refresh token invalidation.
• User deletion
• Token revocation and regeneration through management console.

Refresh token scenario

Previously the refresh token is a OAuth2 token and with this token persistence removal feature we are changin it to a JWT and removing the storeign part of the existing scenario. Hence when a refresh token is invalidated due to external events we have to stop getting a new token using an invalidate refresh token. Hence we need to keep an entry in in token endpoint (Key manager) to validate against the refresh token grant.

We can validate this in OAuth2Service’s issueAccessToken method.
https://github.com/wso2-extensions/identity-inbound-auth-oauth/blob/6.9.x/components/org.wso2.carbon.identity.oauth/src/main/java/org/wso2/carbon/identity/oauth2/OAuth2Service.java#L342

Hence when an internal event happens we need to notify it to the gateway as well as the keymanager to add entries.

For the proposed initial design when an indirect token revocation happens the respective client id, username and expired time will be cached in the gateway. This will be done using the REST APIS to facilitate the distributed deployment architecture.

When an API invocation happens we can decode the JWT token and get the relevant client id, token generated time(iat) and uuid(sub) and validate whether a relevant entry exists in the caching layer and block the API request.

Proposed database structure to keep entries related the the tokens

CREATE TABLE AM_INTERNAL_TOKEN_REVOCATION (
id VARCHAR(255) NOT NULL,
clientId VARCHAR(255) NOT NULL,
timestamp VARCHAR(255) NOT NULL,
user_uuid VARCHAR(255) NOT NULL,
PRIMARY KEY (id)
);

In the above table id will be a uuid

[prasa7]

Hi All,

This is to update the progress of the feature.

• JWT Token revocations due to consumer key revoke
• JWT Token revocations due to consumer key regeneration
• JWT Token revocations due to user deletion
• Migration impact analysis and complete the feature

PR's related to the changes
https://github.com/wso2/carbon-apimgt/pull/11980/files
https://github.com/wso2-extensions/identity-inbound-auth-oauth/pull/2066/files
https://github.com/wso2-extensions/apim-km-wso2is/pull/106/files

Please note identity-inbound-auth-oauth PR and apim-km-wso2is includes @chamilaadhi' commits as well since his changes are still not merged. Once those changes are merged we can merge these two PR's. @chamilaadhi' changes were in these PR because this feature is implemented on top of his changes.

Thanks
@prasa7

[chamilaadhi]

@prasa7 plz send the identity-inbound-auth-oauth separately since it is not needed to have my changes for this pr to work

[prasa7]

Added code review related changes to identity-inbound-auth-oauth[1] and apim-km-wso2is[2]

[1] - wso2-extensions/identity-inbound-auth-oauth@819ab10

[2] - wso2-extensions/apim-km-wso2is@babfeb7

@chamilaadhi : Yes I'll send the identity-inbound-auth-oauth related changes separately. Further will finalyse the carbon-apimgt related changes and comment on the issue.

Thanks
@prasa7

[dushaniw]

PR -https://github.com/wso2-extensions/identity-inbound-auth-oauth/pull/2089/files

[Lakith-Rambukkanage]

The PR [1] will be merged once carbon kernel and identity versions are bumped in carbon-apimgt.

[1] wso2/carbon-apimgt#12174

[dushaniw]

fixed with wso2/carbon-apimgt#12263