Sessions, and Token Based Auth
what are sessionshttp is stateless. In order to know if user is logged in, or keep any other state, there are few work arounds.
- client-side storage (cookies, webstorage). For each request, client sends cookies.
- sessions. server can create a session id, and just pass this to client, client store it, sends back. Server user session id to get client state from database.
Because http is stateless, in order to associate a request to any other reques, you need a way to store user data between HTTP requests.
Cookies or URL parameters ( for ex. like
http://example.com/myPage?asd=lol&boo=no) are both suitable ways to transport data between 2 or more request. However they are not good in case you don't want that data to be readable/editable on client side.
The solution is to store that data server side, give it an "id", and let the client only know (and pass back at every http request) that id. There you go, sessions implemented. Or you can use the client as a convenient remote storage, but you would encrypt the data and keep the secret server-side.
Of course there are other aspects to consider, like you don't want people to hijack other's sessions, you want sessions to not last forever but to expire, and so on.
In your specific example, the user id (could be username or another unique ID in your user database) is stored in the session data, server-side, after successful identification. Then for every HTTP request you get from the client, the session id (given by the client) will point you to the correct session data (stored by the server) that contains the authenticated user id - that way your code will know what user it is talking to.
above from http://stackoverflow.com/questions/3804209/what-are-sessions-how-do-they-work
problems with server based auth
supposed problems are:
- seems resource intensive. each request needs a database check.
- not scalable. When lots users, server overloads.
- problem with load balancers.
token based auth (For example, JSON Web Token)
- user/client/browser sends name/password to server
- server validates. Sends a token to client.
- client stores the token.
- for each request, client sends the token to server.
- server validates token, reponds.
following are from Session (computer science), it's kinda rambling, needs much work. So be warned.
Server side web sessions
Server-side sessions are handy and efficient, but can become difficult to handle in conjunction with load-balancing/high-availability systems and are not usable at all in some embedded systems with no storage. The load-balancing problem can be solved by using shared storage or by applying forced peering between each client and a single server in the cluster, although this can compromise system efficiency and load distribution.
A method of using server-side sessions in systems without mass-storage is to reserve a portion of RAM for storage of session data. This method is applicable for servers with a limited number of clients (For example, router or access point with infrequent or disallowed access to more than one client at a time).. …
Client side web sessions
This mechanism may work well in some contexts; however, data stored on the client is vulnerable to tampering by the user or by software that has access to the client computer. To use client-side sessions where confidentiality and integrity are required, the following must be guaranteed:
- Confidentiality: Nothing apart from the server should be able to interpret session data.
- Data integrity: Nothing apart from the server should manipulate session data (accidentally or maliciously).
- Authenticity: Nothing apart from the server should be able to initiate valid sessions.
To accomplish this, the server needs to encrypt the session data before sending it to the client, and modification of such information by any other party should be prevented via cryptographic means.
Transmitting state back and forth with every request is only practical when the size of the cookie is small. In essence, client-side sessions trade server disk space for the extra bandwidth that each web request will require. Moreover, web browsers limit the number and size of cookies that may be stored by a web site. To improve efficiency and allow for more session data, the server may compress the data before creating the cookie, decompressing it later when the cookie is returned by the client.
HTTP session token
A session token is a unique identifier that is generated and sent from a server to a client to identify the current interaction session. The client usually stores and sends the token as an HTTP cookie and/or sends it as a parameter in GET or POST queries. The reason to use session tokens is that the client only has to handle the identifier—all session data is stored on the server (usually in a database, to which the client does not have direct access) linked to that identifier. Examples of the names that some programming languages use when naming their HTTP cookie include JSESSIONID (JSP), PHPSESSID (PHP), CGISESSID (CGI), and ASPSESSIONID (ASP).
Web server session management
Hypertext Transfer Protocol (HTTP) is stateless: a client computer running a web browser must establish a new Transmission Control Protocol (TCP) network connection to the web server with each new HTTP GET or POST request. The web server, therefore, cannot rely on an established TCP network connection for longer than a single HTTP GET or POST operation. Session management is the technique used by the web developer to make the stateless HTTP protocol support session state. For example, once a user has been authenticated to the web server, the user's next HTTP request (GET or POST) should not cause the web server to ask for the user's account and password again. For a discussion of the methods used to accomplish this see HTTP cookie and Session ID
In situations where multiple web servers must share knowledge of session state (as is typical in a cluster environment) session information must be shared between the cluster nodes that are running web server software. Methods for sharing session state between nodes in a cluster include: multicasting session information to member nodes (see JGroups for one example of this technique), sharing session information with a partner node using distributed shared memory or memory virtualization, sharing session information between nodes using network sockets, storing session information on a shared file system such as the network file system or the global file system, or storing the session information outside the cluster in a database.
If session information is considered transient, volatile data that is not required for non-repudiation of transactions and does not contain data that is subject to compliance auditing (in the U.S. for example, see the Health Insurance Portability and Accountability Act and the Sarbanes-Oxley Act for examples of two laws that necessitate compliance auditing) then any method of storing session information can be used. However, if session information is subject to audit compliance, consideration should be given to the method used for session storage, replication, and clustering.
In a service-oriented architecture, Simple Object Access Protocol or SOAP messages constructed with Extensible Markup Language (XML) messages can be used by consumer applications to cause web servers to create sessions.
what's JWT (Json Web Token)?
jwt is a new hot thing
JSON Web Token