HTTP is a stateless protocal. Requests are independent each time which ensures a good efficiency. To share data among all pages within a same hostname, we need session and cookie.
Cookie and Session
- Client send a http request to server.
- Server receive the http request, create a session and send a http response back to clinet. Within the header of this response, set-cookie header is included, sessionId is included as well.
- On client side, stores the sessionID returned from server. As the client send following requests, client browser will automatically add a cookie into the request.
- Server receive a http request again. Server will analyze this cookie, check and varify session ID. If match, processed, server will return response to the client.
Token
- Token based authentication is stateless authentication (server does not store any token), suitable for RESTful API.
- Usually token will be stored in localStorage.
- Client send a http request to server.
- Server receive the http request, generate a token and send it back to the client.
- this token will be stored in client’s localStorage.
- On subsequent requests, this token will be sent within request headers.
- Client get the token sent by client, decode it and validate it.
Public Key encoding
- Client send a login request
- Server response a public key to user
- Client use this public key to encode their credentials, and send the encodec credentials to server.
- Server decode the credentials by using its private key, and validate this credentials.
- Server send back the validation result.
Man-in-the-middle Attack
- Hacker pretends to be the server and send fake public key to users.
- As user trying to encode their credentials by using this fake publica key and send back to server, the hacker will get users request and decode it to get user’s credentials.
- Then login to the server by using usr’s credentials.
RSA KEY fingerprint
- Warning users that the server could not garunteed to be the real server, do you still want to continue connecting or not?
Login with public key automatically
- Client manully add their public key to server. On server side, it stores users’ public keys as authorized keys.
- Client send a login request to server.
- Server get user’s request, and generate a random number R. R will be encoded by user’s public key (authorized key) and send back to users.
- User get the response, decode the string by using its cooresponding private key.
- Client uses MD5 algorithm to encript R & Session key, generating Digest 1 and send to server.
- Server will also generate a Digest 2 by using the same algorithm to encript the same session key and random number R.
- If digest 1 is the same as digest 2, server will proccess the request.
