In this video we're going to decide whether we should be making use of Jason Webb tokens or cookies.
Now remember this is not an either or decision.
Cookie is in Jason with tokens are two very different things.
The implication here usually when we say that we're using cookie based authentication.
The implication is that we have a cookie that is going to store some kind of encoded token inside of
it and that's going to be encrypted in some way that the user cannot access the information inside there.
So again these are two different things.
But usually when referred to cookie based authentication we're talking about using a very particular
style of off and storing some information inside that cookie.
At any rate let's just take a look at a couple of diagrams and get a better idea of the requirements
of our application and which of these two approaches is going to satisfy those requirements.
OK I've taken a series of diagrams that we've looked at in the past and I've added it in a couple of
notes to each of them the notes I've added in are pointing out some particular aspect of our application
and what that particular aspect is kind of implying or requiring of our authentication mechanism so
in this diagram right here remember we imagine that we had our order service and we were making a request
to say purchase a ticket.
And so inside of our ticket purchase lodge logic we probably needed to figure out whether or not that
user is logged in and OK we can use adjacent token or some cookie based approach for that no problem.
And then after that we probably needed to decide whether or not this user can purchase a ticket.
So maybe whether or not they have billing setup in their account whether or not they have a credit card
or something similar to that that step right there that implication that we need to somehow figure out
whether or not this user or details about this user really implies that our authentication mechanism
needs to tell us information about the person who was just authenticated.
In other words we can't just have some mechanism that says yes this user is authenticated or no they
are not.
Instead this authentication mechanism has to tell us yes this person is authenticated and here is some
information about them.
Here's their user I.D. Here's their email years whether or not they have a credit card tied to their
account.
So we need to have some option or ability to store information inside of our off mechanism that is requirement
Number one here's requirement number two.
So this is similar to the diagram we're just looking at but I customized a couple of things inside of
it to just imagine a new scenario.
Let's imagine that our application has the ability to create free coupons.
So these are coupon codes that allow people to get free tickets.
Of course we probably do not want any arbitrary user to be able to access this root handler and start
creating free tickets that would be catastrophic really bad.
So that would probably be something that we would want to limit to maybe administration users the only
admins can make a request that will create a free coupon code so we can imagine that an admin user would
make a request to create this coupon code it would go to who knows what service maybe order service
doesn't really matter.
Inside there we would access some free coupon creation logic and the first thing we do is check to see
if that person is logged in if they are immediately after that.
We would definitely need to check whether or not this person is authorized to create free coupons.
So we need to decide whether or not this is an admin user so this little step right here even though
our application is not going to do this we could very easily imagine scenarios where we would need to
have something similar to this that separate.
There is really implying that our off mechanism has to include some amount of authorization information
we need to know more information about this user.
Are they user.
Are they an admin.
What's their role.
Stuff like that all right onto the next diagram.
Now this diagram right here was in an optional video.
This was tied to the video where we discussed possible ways of solving that issue where we could be
on a user but they would still have access to our application in this option number two approach that
we're using inside of our app so one way that we discussed to solve this issue was to have a auth mechanism
that would expire after some set of time.
So this is really implying that whatever off mechanism we are going to use it has to have a built in
way and a super secure way.
In other words we would not want a user to be able to tamper with this in some way of expiring our auth
mechanism after a set period of time a very precise period of time so maybe 15 minutes 20 minutes 10
days whatever else.
So that's the next requirement of our off mechanism.
All right.
Just one last one right here.
So last thing I want you to recall is that we are going to have a browser application maybe a mobile
app whatever else it is.
And this is going to be eventually be sending a request to our different services.
One of the big benefits of using a micro services approach is that each of our different services can
be built using a different backend language so we might have the odd service written with node and expressed
orders might be with Ruby on Rails and payments might be with Java spring.
So this is really implying that whatever auth mechanism we decide to use it has to be easily understood
by many different languages.
Because with this option number two fundamental fundamental approach that you and I are using we are
saying that each of these services are in charge of deciding whether or not to authenticate a given
incoming request.
So whatever mechanism we decide to use here just on web token or something else it has to be easily
implementable with Express or Ruby or Java also given the fact that each of these different services
are going to need to somehow authenticate a user.
We probably do not want to force any storage requirements on these services as well.
In other words if we are deciding on some off mechanism that is going to require us to have some back
end server or me a back end database just to store information to support that off mechanism that would
probably be bad.
We don't want to force say our order service to have some kind of specialized database to store information
just to support our off mechanism that would be probably not that great.
All right.
So let's summarize all this stuff up.
These are the requirements for our off mechanism.
First off we have to store information about a user so maybe their user I.D. their email or something
like that within the mechanism itself that is closely coupled with this last item down here so if we
are storing information about that user it has to be inside the off mechanism and it must not require
us to have some kind of backing data store.
Next up we have to build a store some authorization info inside there as well.
So whether or not this person is an admin a normal user or something else we have to have a built in
and tamper resistant way.
So users can appeal to muddy around with this or kind of fool us to expire or invalidate that auth mechanism
automatically without us having to reach out to a user's browser or something like that because we can't
do that and tried to invalidate their off mechanism.
And then finally whatever we choose has to be easily understood between these different languages.
So suffice to say all these requirements right here are very heavily steering us towards a Jason web
token approach.
The reason for this it satisfies Well obviously all these different issues right here on a percent.
Jason Webb tokens we can store only arbitrary information we want about a user.
There are even built in properties of Jason with tokens that lend its to a handling authorization very
well.
Jason Webb tokens can encode code expiration information.
They might be saying hey Steven cookies can do that as well we can have cookies expire after a set period
of time.
Well not quite.
You see we can set some expiration on a cookie but that is us kind of politely asking a browser to expire
the cookie cookie expiration is handled by the browser.
So the browser is going to receive a cookie.
It's going to see that we ask the browser to expire that after say 20 days or something like that.
And after 20 days the browser will expire that cookie for us.
But a user can very easily copy that cookie information and just ignore the expiration date on there
and continue using that cookie in the off mechanism or auth information side there at some point time
in the future even beyond that expiration date.
A Jason web token however is going to encode the expiration time in itself and as soon as the Jason
web token expires then that's it.
It will not be valid anymore Jason what tokens have fantastic support between different languages.
So every language out there you're going to find an official implementation for handling Jason Webb
tokens if we use solely cookie based authentication where we kind of create some kind of custom token
and store inside of a cookie.
It turns out that a lot of these different custom cookie implementations will vary significantly between
different languages.
And if you're super curious I can even show you instances of that with some popular cookie libraries
used in the no J.S. world would be kind of hard to create a cookie that is signed securely.
So has some actual and a secure or encryption around it using no J.S. or express and then reuse that
over in the Ruby on Rails world.
That would be kind of challenging.
And then finally Jason Webb tokens do not strictly require us to have some kind of backing data store
to identify this user now as opposed to cookies.
You will see a lot of people who will use cookies they're going to try to store just say a session I.D.
inside the cookie.
That refers to some session that is stored on a back in server that is not strictly required.
We can't store again any arbitrary information we want inside of a cookie but you're going to see that
a lot of people out there a lot of methodology says that cookie based authentication you're going to
store some kind of session I.D. and so of course that does infer or imply that you will have a back
in data store on the server which again we probably do not want to do.
OK.
So again Jason token that's what we're going to use now that makes it sound really easy and hey these
are great reasons for that but we're still not quite done here.
Remember one thing we looked at earlier when we decide to use a Jason Webb token that's not the end
of the story.
Jason what tokens are just an authentication mechanism.
They're a piece of data that proves that someone is logged in and store some information about the user.
We still have to somehow communicate this information between our browser and our server.
We can do it either manually to a degree using these headers or sticking it into the body of a request.
Or alternatively we can have the browser handle it for us using still this kind of cookie based idea.
Now remember this is where there really is a difference between cookies Becky based authentication and
Jason web tokens.
In this case we're saying that we're going to use a Jason we've token to store our off information but
the cookie is going to be the transport mechanism.
That's how we actually shove or move the cookie around between the browser and the server.
So we still have to decide how we're going to move this token around.
Let's do that in just a moment.