Hey, what's going on? In this lesson,

we're going to start our discussion on

authentication for user authentication

and API authentication. We'll talk about

some of the differences there. Before we

get started, I did want to mention that

this is part of a larger series. So, you

can check out the description for the

playlist link as well as a link to get

the notes for this lesson and all of my

other videos here. So, if you want to

follow along both video and notes, then

I would highly recommend you check that

link out. And finally, wanted to mention

that I did complete my fundamentals

course. So, if you want to get software

engineering fundamentals for beginner,

intermediate, and advanced topics, I

will have that link down below as well.

Check out my software engineering

fundamentals course if you're looking to

build a solid foundation for building

software. This course will take you from

the very beginning all the way through

intermediate and advanced topics with a

focus on core computer science concepts

and applied software engineering

principles that make you a better

software engineer. Follow the link to

get the first section free. So let's

talk about authentication

and I will also talk about

authorization. So very similar topic but

slightly different in concept. So let's

just talk about that first. So

authentication and authorization.

So let's say we have some web page or

some resource but this isn't available

for just everybody. We want to know do

you have the permissions to view this

content? So what does authentication

have to do with this? Authentication is

you proving you are who you say you are.

So for example you go to the website

says yo dog you can't visit this page

and it kicks you back to a login page.

So you log in

and if you successfully log in then you

are authenticated.

But just because you've proved you are

who you say you are doesn't necessarily

mean you can view this.

So then it comes down to authorization.

Are you authorized?

So we'll look at both of these

throughout these lessons. The main thing

you need to understand is that

difference. Authentication is basically

saying, "Hey, it's me. Here's proof." In

this case, it's proof because I have the

username and password for my account.

Then authorization is what you are

allowed to do. Do I have access to this

page? Are there certain features I have

access to and other ones I do not have

access to? That's all related to

authorization. Now there are two major

classifications for authentication that

I'm going to talk about. we have user

authentication

and then we will also have API

authentication or you can think

authentication for services.

So let's first take a very quick look at

user authentication and then we'll take

a very quick look at API authentication

then we'll go into more details but I

want you to have an understanding of

these categories from the beginning. So

for user authentication that is if you

are a user of a web page or some app and

you log in and this allows you to access

all of the hidden data. This is

basically how login works for web pages.

It's basically a way to identify the

user which would make sense from the

name. One of the most common structures

for this would be using JSON web tokens

and we'll talk about what that looks

like. API authentication is a little bit

different. So let's say we're building

an app and we need to connect to some

other service

and this service exposes an API but it's

not a public API. In order to use it you

have to use an API key.

So this API key kind of acts like a

password to make an API request. So

you're not going to be able to get that

data back unless you provide the

appropriate API key. And then what is

this over here? Most likely this is

going to be some backend of an app and

then this API is likely some thirdparty

thing you're using. So maybe that's for

maps or maybe it is for some AI LLM

integration or really any other app out

there that exposes an API you could put

there. Now in many situations you're

going to be on this side of things.

You're going to be building services

that use APIs. But there are situations

when you're going to be building this

side as well. So let's say you built

some social network

and then you release an API and then

other apps can consume your API.

You will need to have a strong

understanding on API authentication

because you're going to want to make

sure that these other services are

authenticated and they're able to use

your API. Otherwise, you're just going

to have a public API, which you can do,

but in many situations, you don't want

to do that. You actually want to scope

things to just authenticated API users.

It's also step one for controlling what

they can and cannot access and things

like rate limiting by user. So, if

you're wanting to make an API service

layer, this is going to be very, very

important. And in that situation, you're

going to be on this side of the

communication. You'll want to be

familiar with both of those sides,

though. So, consuming APIs using an API

key and building APIs where users use an

API key. This one is definitely more

simple because you're most likely just

going to be working with a front end

that makes a request to some backend

and we need to understand how that

front-end backend flow works. So, now

that we understand those two categories,

let's take a deeper look at user

authentication.

And let's say we have some resource that

we can delete.

So we'll say delete is the method for

the request.

And then this will be something like

slash comments.

So we have the full list of comments and

the user wants to delete one of them.

This is something where we are still

working with an API and this is a very

important clarification I want to show.

Just because we're using the user

authentication and not API

authentication doesn't mean we're not

going to be working with an API. It's

just that the purpose of the user

authentication is to authenticate user

actions. So this is basically how the

flow is going to look. We'll have an end

user.

He's really happy because our app is so

good.

He's going to interact with the app from

maybe his mobile phone

and on there there is a delete button.

When you hit that delete button, it's

going to make a request to the back end.

So that's the back end. This is the

front end. We'll need to make sure that

that request is valid based off of the

token they provide. And if it is, the

backend can then issue a delete to the

database.

But we only want to be able to do this

if this user is logged in

and

they are authorized to do that action.

So that's the overall flow. It's dealing

with what the user can do.

And in code, basically what this is

going to look like

is going to be a protected route.

So some function that handles the

request, but it's protected requiring a

correct token saying that they are able

to do this action. So that's the flow.

Let's talk about what that actually

looks like. First, the user comes to the

page. they log in

that will give them a token

and then this token will then be used

with any of the future requests such as

a delete anything that requires the

token so anything protected that token

will then say hey I'm allowed to do this

action so you should now do that for me

so what happens if the user tries to do

something and they haven't logged in so

let's say we try to delete something. We

can program this to redirect

because the back end will give some form

of off error basically saying hey you

need to log in. So this will allow us to

redirect on the front end

to a login page.

So the user is now on the login page.

They put in their username and password.

This will check the back end to make

sure that the username and password is

correct and exists in the database. And

in exchange, it will give back a token.

And I'm going to write JWT here. We

haven't talked about the JWT structure

yet, but it's just a token that this

user will keep.

And the token basically says, "Hey, I

logged in at some point.

So we know that it's a valid user. And

inside that token, we can also have any

kind of permissions or authorization

stuff.

Once they have that token, they can then

go back and retry

that initial thing that they were not

allowed to do. So this is exactly what

happens when you go to a web page. Maybe

you step away for a couple of hours and

you come back. The web page is still

loaded there. So you do something that

would require you to be logged in. Maybe

you delete something, but your login has

expired. So it redirects you to a login

page. You log in and then it may

reexecute that action or ask you again

to do that action. That's the exact flow

of what's going on behind the scenes.

Also that says login. I was like looked

like a B. I couldn't figure out what it

said. So here's how a token works.

So I mentioned we go through a login

page and if we get the credentials

correct, the server will issue a token.

So here we have the backend server and

this backend will sign

the token

and this gets a bit into

cryptography but basically this digital

signature here is what will allow us to

verify the token in the future. So when

we send the token back to the user and

then the user makes future requests.

This gets sent to the back end and the

backend can verify

the token authenticity.

If the client were to tamper with the

token, try to adjust their permissions

or anything like that, it's going to

invalidate the token because the client

is not able to sign because to sign you

have to have a signing key.

And this signing key is a secret value

that only the server has. So when you

get into user off, you will often have

that secret key. That's very important

to protect because it is used for

signing these tokens. The signing is

important because it allows the backend

to later verify the tokens that are sent

from the client. If the client were to

modify the token,

this would produce a different signature

because the client does not have this

signing key. It never leaves the server.

So the server would be able to identify

that this is a phony token. So what is a

token and what does it actually look

like?

Well, if you look at a token, it's just

going to look like a random sequence of

characters and numbers. So behind that

is encoded information. So let's take a

look at it in more detail. So let's take

a look at JWTs or JSON web tokens. I'm

going to do a dedicated video on JSON

web tokens. So, this is a very light

intro, but it's basically just going to

look like random numbers and letters

separated by dots. And they're going to

be a lot more. I just don't have much

space. So, maybe I'll put like three

dots here

and then a dot and then another section

of characters

and then another dot and then another

section of characters. So, we basically

have three sections here. I wrote that

pretty bad, but that's okay. This one is

called the header.

This one is the payload.

And this is the signature.

The way you can imagine the signature

being made is something like this where

we invoke the signing

but we use the existing information

and then we use the signing key that

only the server has. So the fact that we

are embedding this information into the

signature, changing this information

will change the actual signature value

here. That's an important component if

you want to understand how JWTs work

because that's what allows the

prevention of tinkering with these

values on the client. The client

shouldn't be able to touch these and get

the server to trust that token and is

not going to be possible because if they

mess with this data that is part of the

signature which requires the signing

key. So we don't have that signing key.

We would have to use a different key and

the token would be invalid. Now because

the server is the one creating these

tokens and validating them. The server

can put whatever it wants in this

payload and that could be even something

like if that user is an admin or what

authorization things they have. So this

payload maybe it contains their user ID

which we could then use to look up that

user in a database.

But we could also just embed any other

information that could be useful in the

payload such as if this user is an admin

or any other kinds of privilege

attributes. So in this situation, all of

the authorization is self-contained in

this token and we don't even have to

make a database request. And the way

this works is if this was changed,

let's say the user wanted to tinker with

this token, they changed admin to true.

Well, this would force the token to be

invalid.

Again, just going back to the fact that

the client does not have the signing

key. So, we're not able to make any

changes to the token that the server

would then accept. So, those permissions

are pretty much baked into the token.

It's the full access pass. You don't

want that token to be taken by a

malicious user because they could act on

behalf of another user. Whatever token

they have, it's full access. It's as if

the user logged in themselves. And it's

self-contained. So, this is stateless.

So that means if we had an API endpoint,

we can think of that API endpoint in

isolation. It doesn't need to access a

database or do any extra stuff. All it

needs is the request and a token

and that's enough to give permissions to

do things. Now let's take a look at API

keys.

Similar ideas, but there are some key

differences. So an API key will allow

the user in this situation which is most

likely going to be some other service.

So it will allow the service to do

things but most of the times it's not

stateless.

So it's a different structure than a JWT

and you can think of it sort of just

like a password. You make an API

request, you include the API key. The

backend will take the key.

Can check against the database to see

any kinds of permissions.

If we're good to go, we can send the

data back to the user or the service in

this case. So what this could look like

is you might sign up for some API and in

here you might have multiple keys.

So you can imagine logging in to your

account for the platform. You can go to

your API keys. It lists them out. Every

single one of these keys can be seen as

separate login effectively

and they might have different

permissions,

separate spend tracking

or separate rate limiting. These things

could be set by service B or you could

set them potentially. So when you create

that API key, you could say, "Hey,

here's the permissions I want this key

to have." And we could potentially even

limit that key so it doesn't spend more

than this many API credits or make this

many requests. So in that situation, you

could just use a single one of these API

keys for an application and you could

use these other ones for something else.

So instead of thinking of the API key as

just full access to the API, you're

usually going to be able to limit those

capabilities. Now, what I'm describing

here is a pretty common structure, but

you could see variations. For example,

you could probably make these API keys

be signed and not require database

access. Or maybe you get a key per user

instead of a user being able to create

multiple keys. There are a lot of

variations. So, what I would recommend

is just taking a look at some of the

different API platforms out there. Maybe

take a look at some popular social media

networks. look at some payment

processors. So maybe look at Facebook

and Stripe and see how they run their

APIs. Ultimately both user off and API

off are trying to achieve the same thing

just slightly different in approach. So

this is how I decided to group them but

you might see slight variations or some

crossover in concepts. So for example

with JWTs and user off

you could still check a database if you

needed to keep track of invalid keys or

any other things related to specific

keys you store that all in a database.

So it's not the case that if you're

using JWTs you never use a database.

Now, one big difference between JSON web

tokens and other tokens is that JWTs

can be decoded,

but other keys are typically opaque.

So, what that means is if you have an

API key, it's going to look like a bunch

of random characters. Those characters,

you're not going to be able to interpret

those in some way unless they sometimes

will put something at the beginning. So

it might have like the service

and then like a hyphen and then all the

random characters. But the the main

point here is that you're not going to

have information in that token that you

could see. Whereas with the JSON web

token, you can decode this on the client

side even not just server side

and see the payload.

So you might see something like this.

Obviously, I'm going to be an admin.

This is just encoded. And encoding is

different than encrypted. The

information is still retrievable. It's

just not immediately visible unless you

decode that information. So, if you want

to know more about that, you can read

about B 64 encoding. Whereas API keys,

you're not going to be able to just

decode those and read the information.

And it's probably more likely that the

API platform will access the database to

get additional information about your

permissions for that API key or to check

if the API key is valid. Since you're

often given the capability to

immediately invalidate tokens, we

basically need a way to know if a token

is valid. And for that, you will often

have a database for invalid API keys.

Now let's talk about how API keys and

JSON web tokens are actually passed.

They are typically included in the web

request in an authorization header.

And then the next thing here is the

authorization scheme which typically is

just going to be bearer

and then the actual key.

So let's put some random numbers here.

So this is what that header would look

like with that request if you're doing

it from an application.

You can often include headers with your

request.

So you'll need to understand the syntax

to include an authorization header,

which should be pretty simple. Just look

it up. or if you're doing it from some

other client such as Postman,

there's probably some way to include any

authorization headers from the menu or

wherever it may be. So, whatever tool

you're using, you know, maybe it's in

code, maybe it's some tool, or maybe

you're making just like curl requests or

whatever it may be, you need to include

this as a header. Typically, it's going

to be with the bearer scheme

authorization header, but you might see

custom stuff. So you might see something

like X

API key. This is a custom header. So the

client can include arbitrary headers and

then the server would just need to know

to check for that. So you may see that

as well. But I would say this structure

is the most common. So that's your

introduction to authentication with JSON

web tokens and API keys. We have a lot

more topics for this. So stay tuned.

First thing you should know is a better

understanding of JSON web tokens because

that will deal with access tokens and

refresh tokens. So you'll want to

understand that. You should also

understand social login and OOTH. There

are topics like throttling and rate

limiting and a variety of other things

dealing with APIs and user login. So

stay tuned for the upcoming content. If

you have any questions or different

topics you'd like to see me cover, leave

a comment below. Be sure to check out

the notes, the courses, and anything

else down in the description. and I will

see you in the next lesson. Thank you.