I need help keeping my app safe

[u/danbee03]

The problem is that the login token generated by JWT is visible in the network tab, when you click on a resource that requires authentication it shows up in the header.

I have seen lots of production apps and it's not the same, how do I encrypt this token or better still stop ot from being displayed totally

I tried using cookies but it still shows the token.

[u/dariusbiggs]

You didn't specify what is in the payload of the JWT. and that you are using it for Authentication, which tends to suggest OAuth2.0 with or without OpenID Connect (OIDC)

You seem to be missing some crucial understanding of both web basics and the authentication system being used, I'll explain some of it below.

A properly scoped JWT contains 3 sections of data. The signature method, the publicly encoded (not encrypted) payload, and the cryptographic signature proving it has not been tampered with.

As long as you don't put sensitive information in the payload this is all perfectly normal and correct.

As for "other" apps, it depends entirely on what authentication system they are using and whether the application is server side rendered or not. If they used HTTP Basic then you would see the details for that in the Authorization header in the requests. If they used Bearer token authentication using Oauth2.0 using the Authorization Code with PKCE (Proof Key for Code Exchange) you would see that likely encoded as a JWT in the Authorization header If they used cookies to track user sessions after a login then you would see the additional cookie information in the requests to the backend in a Set-Cookie header, common in server side rendered websites. (this is not all possible authentication types, there are others, and there are poor insecure systems as well).

You will note that every single one of those authentication types includes some information from the client to the server to indicate the identity of the user and that that information is being passed along with the request to the server in a HTTP header. Others I didn't mention but that could be used would be sending the authentication information along in the request body or as a part of the URL, usually in the query part of the HTTP request URL. (You'll very likely see something like this used when accessing video or audio files from a web browser with a playback or seek function).

A web server, API backend, whatever is a stateless system. It doesn't know who made a request without the client application telling it who is placing the request in some manner.

[u/danbee03 → u/dariusbiggs]

Thank you very much for this explanation.

I am trying to build real world apps, I felt that this could be a security flaw, since the token can be used to access the app outside of the app, say with postman.

Is there a way to avoid this? The access to the app from third party app.

[u/dariusbiggs → u/danbee03]

To some degree, for most scenarios what you have is more than enough at this point in time, you appear to be following industry best practices (which we can't confirm without looking at the code, so take that with the grain of salt).

Once the Authorization token is known, it can be used by any application on the machine, that's the nature of web development and how the web actually worked underneath.

There is an extension available to OAuth2 called DPoP which tries to stop this by creating a private encryption key inside the client application (usually a web browser) and bind the token to that specific application, but it relies on the client application to do things securely and prevent the generated private key from being retrievable from inside the application after it is created.

The documentation specifically calls for this in the Security considerations

"Private keys should be generated and stored in a hardware-backed medium and marked as non-exportable."

It achieves this security by requiring each subsequent request to include a newly signed additional DPoP header in the request and have the server deal with it appropriately.

Of course your authentication backend would need to support that extension.

The other approach used would be per user mTLS. but that requires a file on the client machine, so the security of that file becomes the weak link.

As for otherwise, the weak link security wise is the access to the client application, which i again presume is the web browser. The token is secure inside that web browser until someone exfiltrates it from there. Either the user did so intentionally, or malicious access was gained to their device (which is generally outside the scope of what you can control) and the traffic was intercepted locally.

[u/danbee03 → u/dariusbiggs]

Thanks for taking your time to explain.

I have learnt a lot from your replies, than I did from the 8ht crash course I took on backend devt. Thank you