Again, quickly reviewing cookies and session based authentication.
With cookie based authentication,
we notice that cookies are stored on the client side, and the cookies are included
in every outgoing request message whereby, the server is reminded about
that specific client, by extracting information from the cookie.
Cookie can be used together with sessions, whereby the cookies store the session ID,
and then when the server receives the incoming request from the cookie,
it extracts the session ID and uses that as an index into the server-side session
store to retrieve the session information for the particular client.
Now, this approach as I said,
is not very scalable because if you have thousands of sessions, the server needs to
keep track of all these thousands of sessions on the server side.
Even though it is done independent of HTTP in a store,
either a file store or a database.
But still,
the fact that you need to track all of these information makes it not scalable.
So, again, to remind you one more time,
why do we talk about token-based authentication?
Session-based authentication, as we have seen earlier, works perfectly fine for
web applications and can easily take care of user authentication.
But then, session-based authentication, while it's the principle of
stateless servers and also leads to scalability problems.
The second issue is, mobile applications do not
handled session-based authentications very well.
Similarly, mobile applications have a hard time dealing with cookies.
So, in such circumstances where your server is serving data for
both a web application, as well as a mobile app.
Then, the session based authentication will not be very useful, and
this is where token based authentication becomes a lot more easy to use.
In a token-based authentication as the name in place,
the server will issue a token to a validated user, and all subsequent
requests coming from the client side, will bear the token in the request itself.
Either in the form of a request header or in the body of the request message.
Furthermore, token-based authentication also helps us to
deal with what are called CORS or CSRF problems.
Cross-origin resource sharing problems and so
on, I'll briefly talk about cost in the next module.
But for the moment, token-based authentication addresses some of
the issues that lies with cars and cross-site request forgery related issues.
Not only that, token-based authentication is a lot more easy for
one application to share its authentication with another application.
Of course, this is all done in a secure manner.
But, with session based authentication, that is not straight forward.
How does token-based authentication work?
In token-based authentication,
the user first needs to validate himself or herself on the server side.
Now, this validation could take on the forms that we have seen earlier.
So we can use a local validation using username and password.
Or, we can even use third party validation using
technologies like, oauth or oauth 2.0 or open ID.
We'll talk briefly about oauth and oauth 2.0 in the next module.
But, no matter which way the user authenticates, once the user
is authenticated, right after, your server can simply issue a token to the user.
And all subsequent communication between the user and
the server, can be done simply using this token.
JSON Web Token that we will talk about, is one such token-based authentication
scheme, and there server when it creates this token, it will create a signed token.
Using a secret on the server site which only the server knows.
So thereby, even if a third party in towards and between and
tries to manipulate the token, even if it captures the token and
tries to manipulate the token, the token will become invalid.
And so, that way of protecting the user is
easily feasible, all subsequent requests
from the client side should carry the token in the request,
either, as I said, in the header or in the body of the request message.
So when the server receives this token, the server will verify the token,
to ensure that this is a valid token, and then if it is a valid token,
the server will then respond to the incoming request.
As I mentioned, JSON Web Tokens is one such token-based authentication scheme.
JSON Web Token, is a very simple way of encoding
information in a token then pass it to the client site.
JSON Web Token itself is based on standards,
this is based on the IETF RFC 7519.
IETF here, stands for the Internet Engineering Task Force.
The organization that mandates everything about how the internet works,
and deals with the protocols and the policies, related to the internet.
The RFC, stands for the standards document,
in IETF terms, RFC stands for Request for Comments.
And each such standards document carries a number.
7519 in this case refers to the document,
the standard document related to JSON Web Token.
The JSON Web Token itself is a self contained token, it carries all
the information within itself, that is necessary to identify the user.
Not only that, a JSON Web Token can be shared between two applications.
So for example, one application when it authenticates and then gets hold of
a JSON Web Token, can pass that JSON Web Token to and in that application,
that it is willing to authorize to access the server on its behalf.
This sharing of the token is done in a very secure manner,
so don't worry too much about security in there.
This is not in a secure manner,
where by the sharing of the token between one application to another.
Thereby, the authorization is transferred over to a second application, and
the second application can authorize on behalf of the first application,
to communicate with the server.