The Stack Overflow podcast is back! Listen to an interview with our new CEO.

New answers tagged

0

Problem 0: You don't need to send the hash of the password, because you're already using TLS (HTTPS). If you do send the hash, then the hash becomes the password. Problem 1: Preventing users from generating a fake JWT response. You're already using TLS. Pin your server's certificate. That is, include the server's public key in your app. If anything ...


2

You have a typo in your header: header = '{"alg":"none"","typ":"JWT"}' none has two quotes at the end.


2

Welcome to Security.SE. Let's take a step back and cover some higher-level topics first which will hopefully explain what you are looking for. The short answer is this: Long-lived tokens are dangerous. Session Management The standard session, getting a cookie with a token that is then stored in the database or caching server like Redis, is the way browsers ...


-1

If you want to identify users on behalf of the access token, you should rather think of OpenID Connect standard. As OAuth2 is an Authorization framework, it is NOT designed for Authentication purposes. There you will be able to use identity tokens which can be retrieved on behalf of request to UserInfo endpoint with access token as Bearer. I have never ...


1

Storing a whitelist of access tokens in a database is a great way to perform access token revocation; if it's not in the DB, don't accept the token. However, this undermines one of the main advantages of JWTs: being able to verify tokens without having to access to a centralised DB. Usually, the short lifespan of access tokens is considered a good enough ...


0

I don’t think storing not only JWT secret but any kinds of secret like ssh keys, database passwords/username etc. in docker ENV is not ideal or recommended. You can use Docker Secret for these kinds of things. Though I am not sure how to implement docker secret in your use case but I have used TLS certificates, ssh keys and various credentials on docker ...


0

If you have done some design work, the best would be now to do some Threat Modelling session, where you could identify all possible flaws. AuthN and AuthZ design is hard and requires experience. I will not do the Threat Modelling session for you as 1) I do not know all the context and requirements 2) this is not a place for that. But from my experience, I ...


27

There's a bit of confusion of terminology here. JWT defines the basic format of the claims, and some standard claims. It specifies that the JWT Claims Set should either be the payload of a JWS or a JWE structure. JWS defines a structure for some payload with a signature. While the payload is almost always JWT in practice, this is not a requirement of the ...


14

What you're missing is that your token is signed (or, more precisely, authenticated with a symmetric key) but not encrypted. If you take the token in your question above, split it into three pieces at the periods (.) and feed each piece into a base64 decoder, you'll get the following decoded outputs: {"alg":"HS256","typ":"JWT"} {"sub":"1234567890","name":"...


48

tl/dr: Your selected version of the JWT doesn't encrypt anything, it merely encodes it for easy transport. The data in the payload is not meant to be a secret. You have a JWS (JWT with signature). What you are looking at is simply the base64 encoded data payload. A JWS contains 3 parts: The base64 encoded header The base64 encoded data A cryptographic ...


0

Short answer: Decode the token locally. This is most likely what those other applications / dashboards you mention are doing. Do ask the question of why you would want to show the token to the user. Maybe just display when the session will expire, and/or when they last authenticated (exp and iat fields in the token) Unless you specifically need the ...


0

Does this approach is good or is there a better way to achieve this? I believe there is a better way. When a user signs up for an API key, display it to them once via the GUI and have them copy it. Then one-way hash it into a database. The only way to retrieve it at that point is to create a new one. Think of what you might need to do to secure any data at ...


0

Most importantly: you can't use a JWT as an API token. There is a very important property that API tokens need that JWTs don't (and can't) have: revokability. This is important for you. You mentioned that you will use the tokens to track usage and limit the number of calls the user can make. If a user has their API token stolen then the attacker can use ...


1

For those who mentioned two JWTs (@keithRozario @Sjoerd) or one JWT but two fields (@Michael Baldry @Laurens Rietveld): Let's called the two JWT or two fields access token and refresh token. If the hacker get the access token somehow, then it is very likely that the refresh token is also leaked and the hacker can request the access token by using the ...


Top 50 recent answers are included