I'm working on a project, and the backend (java) is completely separate from the front-end , and they communicate with REST . >
My question is, let's start working in the authentication area, and was wondering if you can control authentication using cookies or session , using only JavaScript, and if possible, some cool reference.
You will not be able to authenticate using just Javascript. Some part of the authentication process will have to be done on the server, since you can not trust that the client will execute the code that you sent to it (a malicious client can do HTTP requests directly if he wants). >
First, let's remember what our authentication system has to do:
Associate data with user section (user name logged, when section expires, items in shopping cart, etc.)
Only the server can create a "section". Users can not authenticate themselves.
Section data can not be modified by the user. For example, we do not want to let myself authenticate as hugomg on your site but then change the username field of the cookie to EricoSouza and make purchases on your behalf.
The simplest way to keep sections is to keep all data on the server. Thus, requirements (1) and (3) come free. The basic idea is that when the client authenticates 1 , you generate a session identifier that is difficult to guess 2 and sends it to client 3 . The client can store the identifier in a 4 cookie or wherever it is most convenient and the server maintains the data in the section in a table indexed by those identifiers:
123434561234 -> nome:Erico sessao-expira: ...
467235895637 -> nome:hugomg sessao-expira: ...
Because it is difficult to guess the section identifier and because you only display the identifier for the correct user, your server can trust that the user is authenticated if it has an identifier that is in the table.
1 Using username + password or cryptographic keys or whatever you please
2 Use a fairly long random number generated using a cryptographically secure and unpredictable number generator. Do not use a 1,2,3 counter and do not use rand()
3 Use https, or anyone on the client wifi that has Firesheep installed, will be able to see its identifier and steal the section.
4 A good idea is to mark the cookie as HttpOnly, for extra security.
If, for performance reasons, you do not want or can not store the session data on the server you will have to pass that responsibility on to the client and find a way to prohibit the client from tampering with the data you pass on to him . One way to do this is by using a Message Authentication Code (MAC), which is a hash of the section data that can only to be computed by the server 1 2 .
A concrete version of this is to use a cookie with two fields: one with the section data encoded in JSON and another with the MAC computed by the server:
session={"nome":"Erico","expira":""};
MAC=1253712536127354;
The requirements (1) come for free, since the section data is resubmitted on every request. The requirement (2) is fulfilled because only the server can compute the MAC and the requirement (3) is worth even though the user can see the field of the section, it has no way to change them since this would require recomputing the MAC.
1 The MAC calculation uses a secret key that only its servers know about.
2 Like any other cryptographic thing, use some library that is ready to juggle this hash, as it is very easy to create an insecure implementation. The most common suggestion is to use the HMAC method with the SHA-256 or SHA-1 hash function
A good reference is this question in security.stackexchange