Over the last lectures,
we ensured that we can
log in and log out and create users.
And that we protect certain pages.
And that we control which page can be visited,
if we're locked in or locked out.
That certain pages like the profile page
can't be visited that were redirected automatically.
And all of that works now.
All of that works with help of the Next Auth package,
and the session which it checks for us.
And just to make this really clear,
when I say session here,
I am talking about this json web token.
Which is managed automatically by Next Auth.
Which is stored by Next Auth
in our browser this cookie,
which holds this token is created there.
And Next Auth determines whether
we have an active session,
so if this user is logged in,
by checking that cookie and that token
that's stored in that cookie.
That is what happens when we call getsession here,
or in our main-navigation component
when we use the useSession hook.
And that's what we did up to this point.
Now one crucial feature is missing,
one of the main reasons for adding authentication.
Because having this client site protection here is nice,
protecting certain pages and making sure
we can't reach certain pages,
is all nice and good.
But what really matters,
is what we as a user can do.
Which API routes we can hit.
Here we got this change password example.
But of course for example,
if you're building an online shop,
you might only want to allow logged in users,
to create and delete and manage products.
And in the interface which your website
has for managing those products,
you would be sending requests behind the scenes,
to certain API end points,
certain API routes.
Where those requests then trigger certain operations.
Like the creation of a product
or the deletion of a product.
And of course you want to make sure that,
those requests only trigger those operations,
if they come from authenticated users.
So that if you have API routes in your project,
API routes that do certain operations
that are only allowed for authenticated users,
that in those API routes you also verify,
whether that request is coming
from an authenticated user or not.
Because even if you have full control
over this user interface,
requests to APIs can also be sent with other tools.
From the command line, with tools like Postman
which allows you to create http requests.
So there are ways of sending requests to APIs,
that don't require your website.
And therefore protecting the pages on those websites,
is one thing but we also need protection
in those API routes.
Where we validate incoming requests,
and double check that this request
is coming from an authenticated source.
And I'm emphasizing this here,
because this is another key part of authentication.
It's not just about the client site,
it is also about the server site ,
about those API routes.
And that's therefore what we're going to
take a closer look at now.