SmartAuth 2.0.58: stolen sessions terminated and logouts propagated to services

A stolen session is fully terminated

A refresh token is used only once: with each renewal, SmartAuth issues a new one, linked to the previous. If an old token is presented again, SmartAuth detects theft and revokes the entire chain.

This revocation previously extended only one level down the renewal chain. After two or more renewals, the most recent token—the one used by the current session—remained valid along with its access token. Revocation now traverses the entire lineage.

Connected services learn each revocation

Services connected via SSO validate access tokens themselves and only learn of a revocation through the list they regularly check with SmartAuth. Several paths revoked the token without adding it to this list, and the service would still accept it until expiration, up to an hour later:

• replay of a refresh token or authorization code;
• password change and reset;
• OIDC logout, logout of all sessions, and session revocation from the account page;
• account deletion by its owner;
• revocation requested by a customer as per RFC 7009.

Publication now occurs at the core of revocation functions, with a reason, rather than at each caller: a new revocation path cannot overlook it. Modules that already published their revocations, such as capsso upon closing a contract, continue to work unchanged.

Update

Replace the module folder; no reactivation is required.