I searched the Internet for days about how to conduct a token-based authentication but still not 100% sure. As far as I know, it contains the following steps according to link:
When the client log in for the very first time, it sends the username U and password over SSL to the server.
The server check if the username and password are correct. If they are, the server generate a token, which contains the HMAC of U and token issuance time stamp T, keyed by a static cryptographically strong key K. The token is then sent to the client.
In the following request sent from the client to the server, the token is included. Then the server can decode the token using K and check if it is valid.
I am confused becaues there is a totally different method, please refer to link. The step should be:
When the client log in for the very first time, it sends the username and password over SSL to the server.
The server generate the token and store it in a table. At the mean time sent to the client, which is stored in cookie.
In the following request sent from the client to the server, the token is included. The server check if the token sent exist.
Which method should be chosen?
Please help~
Related
How does the server validate the JWT token?
Where is it stored?
How does the token expire after specific days?
On the client side, I store the token and send it to each query. But what's happening on the server side?
It could do with some entry that works
I'm not a JWT expert, so if some of what I write is wrong, I'm very happy to be corrected.
1) When distributing the JWT, the server will sign it using a private key. The private key is top secret, and must be stored securely on the server. This signature can then be verified using a public key, which confirms that this token was indeed signed by the server (using the top secret private key). The public key is not necessarily secret and can be widely distributed to anyone who needs to verify that the token was signed by that server.
2) The JWT does not really need to be stored anywhere on the server, as the server can verify that it's a valid token whenever it receives it. As the server is also likely to generate JWT, some servers will use a cache to store generated and valid JWT to increase performance. So in short, the JWT does not need to be stored by the server.
3) The JWT contains lots of data, including an expiration time (or time when it was created, and duration for how long it's valid). In addition to verifying the token using the public key, the server will discard valid tokens that have expired.
4) Before processing your request, the server will at minimum use the public key to verify that the token is genuine and check the expiration time. If it passes those tests, the server might also do additional checks with the data stored in the JWT before processing your request. These checks might include checking if your user ID has permission to access the data you are trying to access, check if you're located in a country to has access to the data, and so on. It can change wildly from a case to case basis.
It's a little bit of a broad question. I'll try to answer some specific points though.
How does the server validate the JWT token?
JWTs are typically digitally signed.
The token server signs the token using either symmetric or asymmetric cryptography.
The resource server validates the token by checking the signature against the symmetric key or public key.
Where is it stored?
This is up to the client.
In the case of a single page application, the client can store the token in local or session storage.
How does the token expire after specific days?
A JWT always has an expiry time, set in the token when it is created.
And since the token is signed, this time cannot be changed by someone without the key.
The resource server must check the expiry time after validating the signature.
Currently I'm learning about JWT and started with the token based authentication. I don't understand the sentence from the article:
Token based authentication works by ensuring that each request to a
server is accompanied by a signed token which the server verifies for
authenticity and only then responds to the request.
What is signed token? What does it mean to sign a token? I can't find the question on SO.
A signature is something that can be verified.
The main problem you're trying to solve is this: the server creates some arbitrary value, the token, which it gives to the client. The client subsequently gives it back to the server as proof of something (proof that they're authenticated, for instance). Now, how can the server be sure that the token is genuine, and the client didn't just make it up?
That's where the signature comes in. It's part of the token, and the server can verify that it had previously created that signature, and that the signature was created for this particular token. In a nutshell, the signature is a hash of the contents of the token plus a secret only the server possesses; to verify the signature the server repeats the hash of the token's contents and the secret only it has, and if it matches, that means the token's signature must have been created the same way which assures the two desired attributes of authenticity.
For the gnarly details of how a JWT signature is computed specifically, read the specification.
I implemented a simple web page where Google Sign In let users enter their Gmail and password in order to authenticate; then I made a simple server with Flask using Google Python API.
Everything is working fine, but I realized that I made the server before asking myself if I really need it: if I got it right, when user's credentials are verified after clicking on Google Sign In, the user is authenticated.
Client-side speaking, after a successful login a GoogleUser object is returned and it contains informations about the user; however, the user has already told me who he is since he provided me username and password.
So, why bother validating on a server an ID token if it is given after a successful login?
Some concepts sound contradictory to me: Google Sign-In for Websites: Authentication with backends video says that:
You can obtain an ID token upon the successful authentication
this would mean that the user is who he claims to be, but then, speaking about a server:
Note that the client libraries verify most of the information, but you still have to check if aud and iss claims are correct [on the server]
I thought that these two claims were verified on the client.
Is the GoogleUser object returned from a successful login enough to say "he is really that user"?
The ID token I send and verify in my server is necessary because there is no Google Sign-in button on the servers and is meant only for client side code?
So, why bother validating on a server an ID token if it is given after
a successful login?
The OAuth 2.0 ID Token provides the "verified" identity of the client. Since it is very easy to create an ID Token, you need to verify that the ID Token was created by a trusted Identity Provider. You verify the ID Token to prevent forgery attacks. How? By using the public key from the Identity Provider to verify the signature attached to the ID Token.
Note that the client libraries verify most of the information, but you
still have to check if aud and iss claims are correct [on the server]
I thought that these two claims were verified on the client.
In terms of security, you cannot trust anything from the client. You must verify everything. Hackers today think nothing of running scripts attacking any resource attached to a public IP address.
Is the GoogleUser object returned from a successful login enough to
say "he is really that user"?
No. The JavaScript code running at the browser can be modified. This means all data coming from the browser to your server should be consider "untrusted".
The ID token I send and verify in my server is necessary because there
is no Google Sign-in button on the servers and is meant only for
client side code?
You can implement 3-legged OAuth 2.0 which puts your server into the Authorization process. This way your server receives the Access Token, Refresh Token and ID Token. You then control what you provide to the client.
When token based authantication is compared to traditional server authantication, it is said that: traditional method keeps login info in memory on server side, but in token based authantication server keeps nothing. Information about logged in user is stored in token itself.
However, I didn't get one point here. If server doesn't store anything, how does server validate the token? I think it should store the secret key to decrypt the token and then validate.
If so, where is it stored? If not what poin did I miss?
The server issuing the token, digitally signs the token with a private key.
The service consuming the token only needs the public key to validate the token. It can download the public key from the issuing server on startup or first use. After that, it does not need to communicate with the issuing server to validate tokens. If the signature is valid, the service trusts the contents of the token.
For example, look at the "jwt", it uses "ssh" keys
What would be a step-by-step description of how cookie-based authentication work?
I've never done anything involving either authentication or cookies. What does the browser need to do? What does the server need to do? In what order? How do we keep things secure?
I've been reading about different types of authentication and about cookies, but I would like a basic description of how to use the two together. I've only read that they are often used together, but I could not find a description of how.
To expand on Conor's answer and add a little bit more to the discussion...
Can someone give me a step by step description of how cookie based authentication works? I've never done anything involving either authentication or cookies. What does the browser need to do? What does the server need to do? In what order? How do we keep things secure?
Step 1: Client > Signing up
Before anything else, the user has to sign up. The client posts a HTTP request to the server containing his/her username and password.
Step 2: Server > Handling sign up
The server receives this request and hashes the password before storing the username and password in your database. This way, if someone gains access to your database they won't see your users' actual passwords.
Step 3: Client > User login
Now your user logs in. He/she provides their username/password and again, this is posted as a HTTP request to the server.
Step 4: Server > Validating login
The server looks up the username in the database, hashes the supplied login password, and compares it to the previously hashed password in the database. If it doesn't check out, we may deny them access by sending a 401 status code and ending the request.
Step 5: Server > Generating access token
If everything checks out, we're going to create an access token, which uniquely identifies the user's session. Still in the server, we do two things with the access token:
Store it in the database associated with that user
Attach it to a response cookie to be returned to the client. Be sure to set an expiration date/time to limit the user's session
Henceforth, the cookies will be attached to every request (and response) made between the client and server.
Step 6: Client > Making page requests
Back on the client side, we are now logged in. Every time the client makes a request for a page that requires authorization (i.e. they need to be logged in), the server obtains the access token from the cookie and checks it against the one in the database associated with that user. If it checks out, access is granted.
This should get you started. Be sure to clear the cookies upon logout!
A cookie is basically just an item in a dictionary. Each item has a key and a value. For authentication, the key could be something like 'username' and the value would be the username. Each time you make a request to a website, your browser will include the cookies in the request, and the host server will check the cookies. So authentication can be done automatically like that.
To set a cookie, you just have to add it to the response the server sends back after requests. The browser will then add the cookie upon receiving the response.
There are different options you can configure for the cookie server side, like expiration times or encryption. An encrypted cookie is often referred to as a signed cookie. Basically the server encrypts the key and value in the dictionary item, so only the server can make use of the information. So then cookie would be secure.
A browser will save the cookies set by the server. In the HTTP header of every request the browser makes to that server, it will add the cookies. It will only add cookies for the domains that set them. Example.com can set a cookie and also add options in the HTTP header for the browsers to send the cookie back to subdomains, like sub.example.com. It would be unacceptable for a browser to ever sends cookies to a different domain.
Cookie-Based Authentication
Cookie-based authentication normally works in these four steps:
The user provides a username and password in the login form and the client/browser sends a login request.
After the request is made, the server validates the user on the backend by querying the database. If the request is valid, it will create a session by using the user information fetched from the database and store them. For each session a unique ID called the session ID is created. By default, the session ID will be given to the client through the browser.
The browser will submit this session ID on each subsequent request. The session ID is verified against the database. Based on this session ID, the server will identify the session belonging to which client and then give the request access.
Once a user logs out of the app, the session is destroyed both client-side and server-side.