ABP 10 - How to invalid access token after logout #10704

3 Answer(s)

• 

  0

  maliming created 4 months ago

  Support Team Fullstack Developer

  Hi,

  Access tokens issued by ABP / OpenIddict are standard self-contained JWTs and stay valid until they expire. A logout only clears the client-side cookies/session, it doesn't invalidate an already-issued JWT on the server side. This is by design in OAuth2 / OpenID Connect.

  If you want already-issued tokens to be rejected as soon as the user logs out, ABP has this built in via the Session Management + Dynamic Claims feature. Once enabled, every authenticated request looks up the session id (sid) of the token against a server-side store (cache + DB) and rejects the token if the session is gone. Logout (or revoking a session from the Identity UI) removes the record, so the next API call with that token returns 401.

  How it works:

  • On login, a sid claim is added and an IdentitySession record is created.
  • On every API call, IdentitySessionChecker validates the sid (via distributed cache, falling back to DB).
  • On logout via /connect/endsession, or when an admin revokes the session from the Identity Users page, the record is removed and the cache is invalidated.
  • The next request with that access token is rejected.

  Docs:

  • Session Management: https://abp.io/docs/latest/modules/identity/session-management
  • Dynamic Claims (the underlying mechanism, must be enabled): https://abp.io/docs/latest/framework/fundamentals/dynamic-claims

  Starting from ABP v8.0 the startup templates already enable AbpClaimsPrincipalFactoryOptions.IsDynamicClaimsEnabled = true on the auth server / host modules, so if you created your solution with ABP 10 from the official template it should already be active. You can also verify the behavior from the UI: open the Identity → Users page, pick a user, open Sessions, and click Revoke — the user's existing access token will stop working on the next request.

  A couple of things to confirm so I can point you at the right place:

  1. Exact ABP version (e.g. 10.0.x / 10.1.x / ...).
  2. UI type: MVC / Blazor Server / Blazor WebApp / Blazor WebAssembly / Angular / MAUI.
  3. Solution structure: single-layer (app-nolayers-pro), layered (app-pro), tiered (separate AuthServer), or microservice.
  4. How the client triggers logout today — does it call /connect/endsession with id_token_hint (default for Angular, Blazor, MAUI templates), or does it only clear the token locally?
  5. Whether options.IsDynamicClaimsEnabled = true is set on your auth server / host module.

  With those details I can tell you exactly where to look in your solution and what to change if the session check isn't kicking in.

  Thanks

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  DominaTang created 4 months ago

  The ABP version is 10.1.1 Micro Service Template Angular UI, I don't find code that call end-session end point.

  Here is AI analyze to Angular code: Current logout.component.ts: revokeTokenAndLogout() already does the right thing:

  1. Calls /connect/revoke to revoke the access + refresh tokens
  2. Then calls logOut() which redirects to /connect/endsession?id_token_hint=...
  3. OpenIddict removes the IdentitySession record → ABP's IdentitySessionChecker rejects any subsequent request with that token's sid

  The one missing piece — postLogoutRedirectUri is registered in OpenIddict seeder for the Angular client, but it's not in app.config.json, so angular-oauth2-oidc never sends it. Without it, after the auth server processes the logout, the user is left stranded on the auth server's logout page instead of being redirected back to Angular:

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  maliming created 4 months ago

  Support Team Fullstack Developer

  Hi,

  Thanks for the version info. With ABP 10.1.1 + Microservice + Angular all the pieces should be in place by default — every *.HttpApi.Host in the microservice template ships with IsDynamicClaimsEnabled = true, and the Angular client calls /connect/revocat and /connect/endsession from inside angular-oauth2-oidc (in oAuthService.revokeTokenAndLogout()), so you won't see those calls in your own code. Both endpoints are wired on the server to revoke the IdentitySession.

  Since the behavior on your side doesn't match that, could you share two things so we can see exactly what's happening:

  1. HAR file of the full logout flow — capture the network traffic from clicking logout until you land back on the login page. How to capture a HAR: https://abp.io/support/questions/8622/How-to-enable-Debug-logs-for-troubleshoot-problems#answer-3a1f7c9e-eb0b-eb9c-3535-1beae8e8ba43 — we need to see whether /connect/revocat and /connect/endsession are actually called and with what status.

  2. AuthServer Debug logs during the same logout. Set the global log level to Debug (rather than only a couple of categories) so we have full context to keep investigating if needed. How to enable Debug logs: https://abp.io/support/questions/8622/How-to-enable-Debug-logs-for-troubleshoot-problems

  Also, one short note on how you're testing — are you doing it inside the Angular app (UI-driven logout, then making a call from the app), or are you copying the access token out and replaying it with Postman / curl?

  The HAR and logs can be too big for the thread, please email them to liming.ma@volosoft.com and reference this question.

  Thanks

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel