Activities of "Yaduraj.Shakti"

Hi @maliming

We have done security testing with some third party, and they have given this recommendation that in case access token can be spoofed or stolen then we must allow access token from valid user/device.

Please can you guide if implementing such case is possible or not.

Hi @maliming,

Thanks for the clarification. We are using access token + refresh token flow to minimize the damage (If any case the JWT token is stolen).

Still, can you help with some examples of adding X-Session-Id, HttpOnly cookie in ABP.IO.

OR is there a way to bind token to specific device.

Hi Team,

We have implemented access and refresh tokens in our application, and all standard validations are in place.

However, we’ve observed that even after logging out, the original access token obtained during login remains valid and can still be used for API calls until it naturally expires.

We would like to explicitly mark the access token as expired or revoked during logout to prevent any further usage. Could you please advise how we can achieve this within the ABP.IO and OpenIddict setup?

Looking forward to your guidance.

Current Behavior:

• We were previously using AuthService.login() with JWT tokens, and everything worked fine.

• Recently, we switched to using Reference Tokens (opaque tokens) on the backend to support real-time token revocation and higher security.

• Backend now returns an access_token (reference token) and refresh_token via the /connect/token endpoint.

• Exception message and full stack trace:

• Steps to reproduce the issue:

Hello Team,

Thanks for confirming that AuthService.login() only supports JWT-based flows.

However, our **main concern is not just login, but secure revocation of access tokens during logout or re-login. This is a critical requirement for us.

We’ve already raised another ticket related to this: How-to-Invalidate-Access-Token-on-Logout https://abp.io/support/questions/9531/How-to-Invalidate-Access-Token-on-Logout#answer-3a1abddd-345b-38e4-45e8-b809897a59ba

We’ve implemented token revocation correctly at the backend using OpenIddict.

But since we're using JWT tokens, the token is still considered valid on the resource server after revocation, because:

• JWT validation is stateless
• No DB call or introspection occurs per request So even if the token is revoked, any service or API with the previously issued JWT still allows access until the token expires.

We need guidance on:

• How to properly handle login + token storage in Angular when using Reference Tokens
• Whether ABP.IO plans to support AuthService.login() with Reference Tokens
• Recommended best practice for securely revoking tokens (especially on login/logout scenarios) in both frontend and backend
• Whether we must fully switch to loginUsingGrant() + custom token storage in Angular apps using confidential clients

Looking forward to your input, as this is urgent and security-critical for us. Please let me know if can have a call so that can share the code.

Thanks

Hi @fahrigedik,

Can you create a github repo and post your project there.

Hello ABP.IO Support Team,

We are working with ABP.IO 8.3.1 in a microservices setup using:

• Angular (frontend)
• .NET 8 (backend microservices)
• PostgreSQL + EF Core
• Redis

We have WSL2 (Ubuntu) installed and are able to build container images for our services. However, we are facing issues running them properly with localhost access (e.g., API Gateway, IdentityServer, Angular UI).

Could you please guide us with:

1. Downloading the correct template from ABP.IO for our use case.
2. Recommended Dockerfile/Docker Compose setup for Angular + .NET + PostgreSQL + Redis in ABP.IO.
3. Correct way to configure environment variables, connection strings, and networking so services can communicate properly in containers.
4. Any best practices for Dockerizing ABP.IO microservices.

Our main blocker right now is running the containers and accessing them on localhost through WSL2. We don't have Docker desktop for now.

Thanks in advance for your help!

• Exception message and full stack trace:
• Steps to reproduce the issue: