How to Ensure JWT Access Tokens Are Not Stolen in an Angular SPA + NestJS Setup?

Help
,
1

Hi everyone,

I’ve been following the blog posts and quickstart guides for building an Angular SPA with a NestJS backend, and everything is working great so far. However, I have a few concerns regarding security and would appreciate some guidance:

How can I ensure that the JWT access_token is coming from the intended browser and hasn’t been stolen?

In the past, I relied on HTTP-only cookies for this purpose. When a user logged in, I generated and signed the token on my backend, then stored a random string as an HTTP-only cookie associated with the token in cache. Every time the user sent a request with the JWT access_token, I validated both the token and the cookie in the cache to ensure they matched before allowing access.

Now, I see that the Angular SDK’s HttpInterceptor automatically appends the access_token to requests. Is there a way to hook into the login process or modify the behavior to reintroduce a similar cookie-based validation system?

Do I need to intercept the login response from the authorization server on my backend, create the HTTP-only cookie there, and then redirect the user back to the Angular SPA?

Or is there a newer, recommended approach to ensure the token is being used securely and from the intended browser?

Thanks in advance for your help!

2

Hi,

There is no way to fully secure the access token when using Angular. One way or another, any user can view the token once they are logged in. Yes, the Auth0 SDK will automatically make token calls.

I would recommend not sending sensitive information in the token that shouldn’t be publicly exposed.

Use backend API calls for communication with Auth0 when needed.

Typically, the access token only contains user roles, so avoid using it to share sensitive information.

If you can let me know what type of information you want to secure, I can suggest a different approach to manage it.

3

Hi,

It’s just the user credentials i don’t want them to be able to reply the token in a browser that is not intended to use those credentials, ie: copy token paste in postman or curl cli.

I did found this ietf current best practice “BFF” ( can’t paste link ) , so i think i’m going with this approach