Instructor: In the last section,
we spoke about authentication
and how it is the exchange of some credentials,
like a username and password
for some identifying piece of information.
The really important part here,
is how we include that identifying piece of information
on any request that we want to be authenticated.
So there's two ways that we will
include this piece of information,
either by cookies or by a manually set token.
Let's talk about each one.
So this is a diagram of the differences
between cookies and the use of tokens for authentication.
On the left-hand side, we have our cookies
and on the right-hand side tokens.
Cookies are, of course I have to make the obligatory joke.
It's not a cookie that you eat.
It's a cookie that is included with HTTP requests
by default, made in your browser.
So whenever you visit a website like say google.com
or ebay.com or anything, github.com,
you have some number of cookies
that are associated with that domain.
The purpose of cookies is to kind of bring state
into what is inherently a stateless protocol, which is HTTP.
The HTTP protocol has no concept of state
and it's solely by including these cookies
or this tiny bit of data on requests
that identify us to the server.
Cookies are included on all HTTP requests by default.
They manifest themselves as a property
on the header of any request.
A server can choose to place information
on a user's cookie that identifies them uniquely
to that very particular server.
So if they were, say, logging into a website we were making,
we could stick a piece of information into this cookie
that says, "This is user ID 12794".
Then on any follow-up request that that user made,
they would have a cookie 12794 that told us,
"Hey this is the same user, they're coming back.
It's another request from this same person".
Cookies are automatically included on all requests
and very importantly, are unique to each domain.
And when I say domain, I'm talking about say,
google.com versus ebay.com.
A cookie that you have that is tied to google.com
is not shared and cannot be shared by default with ebay.com.
That's how we get some level of security
in all of our requests.
That's how if I log into Google and then go to
say, hackerwebsite.com, the hacker website couldn't
lift my cookie from Google and hijack my session.
So cookies cannot be sent to different domains
and that is a level, that is something that exists
for security purposes.
It's so that you cannot easily hijack people's sessions.
Opposed to cookies are the idea of tokens.
Now, tokens really isn't any necessarily codified idea here.
It's something that was in, has been introduced
as a convention to use tokens in place of cookies
where cookies start to fall off as being very useful.
So the most important thing about tokens
is that we have to wire them up manually.
There's nothing done automatically for us with tokens.
We have to literally say when we make a request,
include a header with our token,
which might be a string of letters and characters,
excuse me, letters and numbers.
There we go.
And we're going, we might include it
on a very specific header.
So we have to manually wire up our tokens at all times.
The benefit to tokens, however, is that we can send them
to any domain that we wish.
So if I'm on say, google.com
and I wanna make an authenticated request
to some other entirely different domain,
I can do so by using a token.
I would make my request to that other domain,
I would include my very particular token,
and, poof, I'm authenticated on that other domain.
This starts to be very useful if we start
making a distributed system for our application.
Let's say that we are building an app
that consists of many different servers,
hosted on many different domains
but I still want our, my user to be authenticated
on all these different domains.
That would be the use case of a token, instead of a cookie.
So again, the real differentiator here,
the really real difference is that with cookies
we are restricted to singular domains.
So as we move forward in this section,
we're going to move forward with a token-based response
or token-based authentication system.
And the reason for this is that is just the way
that the industry is trending.
You're here to learn the latest and greatest.
That's what tokens are here for.
Tokens are used much more frequently
with very large applications that need to scale.
And the reason for that are is what we're going to discuss
very shortly, in the next section.
I'll see you there.