CODEWITHSUNDEEP
angulartypescriptjwtngrxngrx-store
shaziyali
shaziyali

Reputation: 3

Securing User Details and Implementing JWT Tokens and NgRx in Angular Application

I have a concern related to my Angular application's security. Currently, I'm storing user details like isAdmin, isLoggedIn, email, and more in local storage. However, I'm worried about the security risks associated with manual updates to this stored data, especially since my application's authorization relies on the value of isAdmin.

My Problem: How can I securely store user details in Angular to protect against unauthorized access and manipulation, considering the isAdmin value and other sensitive data?

I tried Implementing JWT Token: I've considered using JWT tokens, but I'm concerned about their security. If I place a JWT token on a JWT website, it can be easily decoded, revealing all the data. Is there a more secure way to implement JWT tokens in my application?

I tried Implementing NgRx: I've also tried using NgRx for state management, but I've encountered an issue where the state managed by NgRx is in-memory and doesn't persist across browser refreshes. How can I make sure that the state, which includes crucial user authorization data, remains consistent even after a page refresh?

I would greatly appreciate any guidance or best practices to address these concerns and improve the security of my Angular application. Thank you in advance for your insights!

Upvotes: 0

Views: 390

Answers (1)

Krenom
Krenom

Reputation: 2118

  1. I hate ngrx so it's the first point of any response I give - don't use it. It's a lot of complication for no gain if you set your application up properly.

  2. Welcome to the world of 'nothing I do is ever good enough for security purposes'.

JWT is, as you point out, perfectly readably plain-text once you decode it. As such, you shouldn't have any kind of sensitive information in there.

The various claims someone has, e.g. 'isAdmin' should be fairly irrelevant for anyone to be able to read. Good to know, this person is an admin, woo. Ok, it's a step towards picking a target, but that's all.

The token itself is signed, so that any modification to the token by anyone other than yourself (assuming you are the only one with the key that signed it), means you know it's not the originally provided thing and can raise all the alerts you want about it.

Now, next problem is that just having the JWT is like stealing someone's NFC-capable debit/credit card. So long as they stay under the limit of <insert your country's contactless limit> they can cheekily use your card for purchases.

This is where the expiries come in. You should strive for a short lifetime on your tokens so that even if someone does grab that token, there's limited damage they can do with the short time they have with it before it expires.

An ultra secure method of things? Well, you could encrypt the JWT itself? And you'd have to do it two-ways. One encryption with the server's private key, and then encrypt that with the UI's public key. So long as the UI has (or can request) the server's public key, and it knows its own private key, it can undo the encryptions and read the payload... Though, saying that, if the UI knows something then the user knows something if they care to look hard enough, so I guess the double-encryption doesn't really mean that much...

TL;DR: JWT is fine so long as you use a short expiry time and don't put any sensitive information into it that you don't really really really need. Keep it limited to basic, app-relevant info about the user.

Upvotes: 0

Related Questions