A
A
Alexander2019-12-05 14:31:19
JSON Web Token
Alexander, 2019-12-05 14:31:19

Secure user authentication without sessions?

Hello.
Interested in whether there is a secure option for user authentication without sessions?
Googled that there is jwt. But if the token is stolen, the attacker can use the account within the lifetime of the access token.
Is there something safer?

Answer the question

In order to leave comments, you need to log in

4 answer(s)
F
FanatPHP, 2019-12-05
@FanatPHP

It is rarely possible to get a meaningful answer to a question taken from the ceiling.
When asking "is there anything safer" it is necessary to formulate security criteria.
When asking how to make user authentication "without sessions", it is necessary to explain why without sessions.

A
Alexander Aksentiev, 2019-12-05
@Sanasol

Well, just the same JWT will be stolen from you and you will not recognize it, and the session can be tied to the user agent / ip / anything on the server side. Although you can enter this in JWT, it’s easier with sessions then.
And so, apart from sessions, there are no more authorizations as a class. In any case, something is stored in the browser that the server can recognize, and this is the "session".

V
Vladimir Skibin, 2019-12-05
@megafax

https://gist.github.com/zmts/802dc9c3510d79fd40f9d...
know how to use the search here

X
xmoonlight, 2019-12-06
@xmoonlight

The token is bound to the browser.
1. During authentication, the client's fingerprint (fingerprint) is encrypted with the user's password hash (on the client side!) and from above, "turns around": encrypted with the server's public key, and then sent to the server.
2. The server opens the package with its private key, decrypts it using its password hash (for this particular user, from the database), and receives fingerprint data.
3. The server binds the fingerprint data to the token and sends the token and the fingerprint's hash function to the client.
4. With each request, the client sends its token and signs the request with the fingerprint's hash.
5. The server checks the token and the signature of the request (the fingerprint hash).
6. If they do not match, the token becomes invalid (the session ends).
When IP is changed, a "transparent" re-initialization of the session will occur (and with a request for a real fingerprint of the client), imperceptible to the end user (if he has a valid token for the newly defined fingerprint).
When stealing cookies or intercepting traffic - the attacker does not know the real fingerprint.
And without it, he will not be able to forge a signature in order to use the current token.

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question