Hey, guys. 1
In this lesson we're going to be learning all about API authentication and authorization, the ability 2
to prove that you have the rights to access a particular API. 3
Previously we saw that we were able to make very simple GET requests using Axios or coming from our 4
server side and also doing it via Postman, 5
but you can imagine that there are a lot of scenarios where maybe you don't want everybody to be able 6
to access your API. 7
Let's say that the data that you hold behind your API is a resource, right? 8
Let's view it as money because after all, in our current day and age, data is extremely valuable. 9
In that case, let's imagine that we have our data locked up in a vault like a bank does, and our API 10
is the front desk where we can take and handle requests from customers and clients. 11
So let's say somebody bad comes along and says, "Well, I'd like to get Â£100, please" using the API, 12
and they try to get hold of some resource. 13
Now so far this works with everything that we've seen. 14
Our API would say, Well, here you go, here's the money that you requested and off he goes. 15
What we want instead is in certain scenarios we want to be able to protect the resources behind our 16
API by using authentication. 17
So how does that work? 18
Well, in that case, we need to know who are you when you're making these requests? 19
And depending on whether if you have the authentication or not, then we might say, "Oh 401 unauthorized. 20
Sorry, you can't do that." 21
In this lesson, we're going to be learning exactly how we can authenticate the user or the client that 22
is making the API request and depending on whether or not they are authorized to make that request, 23
we can send them the data or tell them no, sorry, that's not allowed. 24
In terms of authentication, I like to think of it as four tiers. 25
There is the Zero Authentication, so none at all, 26
and that's what we've been working with so far. 27
There is Basic Authentication, API Key-based Authorization and also Token-based Authentication. 28
Now I'm going to tell you a little bit later on what's the difference between authentication and authorization. 29
Let's first go in order of security and let's start with the first type, No Authentication. 30
Now we've already seen APIs with no authentication. 31
For example, when we worked with the bored API, none of the endpoints in the API required any sort 32
of authentication. 33
So what can an API do to prevent abuse of the API? 34
Let's say somebody makes way too many requests and there's no way to check who they are or where they're 35
coming from, 36
then the way the API providers might add a safety check is to put in a Rate Limit. 37
As you saw in the bored APIs instance, we had a rate limit of 100 requests per 15 minutes and I put 38
in that rate limit so that under most cases as a student, that should be enough for you to work with 39
the API and get hold of the data and try out the things you want to try without hitting it up too much 40
and then ending up making the API go down for everyone. 41
So this is one way. 42
So you can check each IP address, how many requests they're making per minute and based on some sort 43
of arbitrary decision that you make, you can say, "Well, I'm going to limit it to this amount." 44
So that's something that you commonly see with public APIs that have no authentication and no authentication 45
is great because it means it's super inclusive. 46
Anyone can use it. 47
It's super easy to get started and usually if you don't have changing data that you're protecting or 48
data that needs to be assigned to a particular user, you very often see no authentication APIs. 49
If you go back to the Bored API Documentation, you'll see that all of the endpoints don't require any 50
sort of authentication and you can simply just make the request as anyone and you'll be able to get 51
the data back. 52
But the API requests are in fact rate limited and that means that we do have some safety measures, 53
although it is not a measure to authenticate or authorize any sort of API user. 54
Let's move on to the next level of security, Basic Authentication. 55
And as the name suggests, it is pretty basic. 56
So how does it work? 57
Well, you provide a username and password when you make your API request. 58
What that means 59
is you are authenticating yourself to the API provider. 60
You have an account with the API provider, 61
by providing these two pieces of information, you are proving your identity. 62
Usually, the way that Basic Authentication is done is by passing over a Base64 encoded string in the 63
header of the request. 64
Now what is Base64 encoding? 65
Well, it's basically taking text which is ASCII, 66
so anything that you can type on your keyboard and that can be converted into bits. 67
So zeros and ones to represent that particular character. 68
And then we can take the bits and then encode it into another character. 69
Now usually when we do Base64 encoding, there is a little bit of expansion, 70
so for example, by starting with the word man, M-A-N, the end result that we get once we've done our 71
Base64 encoding is TWFU and you can see we've got one more character than previously. 72
And depending on whether if you have spacing in your line of source encoding, then you might see extra 73
characters as well. 74
Each character is represented in binary, and I've seen some people who can actually read binary, which 75
I think is a crazy skill, but probably not that useful because computers can do it faster. 76
After all, this is basically computer language, right? 77
When we first started out with computers, we had a button for on and we had a button for off. 78
And by switching things on and off, on and off, we could represent to the computer what it is that 79
we wanted to type out or what we wanted it to number crunch and do all of the computations and all of 80
the things that computers do through these zeros and ones or these on and offs. 81
As you can see, each character that you can think of is represented in binary. 82
And then by taking that binary and passing it through a special encoding method, we end up with Base64. 83
And then we simply format it in this format, 84
so the username: password, 85
and we convert all of this into Base64. 86
So you'll end up with some sort of long string full of characters that represents this data 87
but in Base64. 88
And then what you can do is you can add this to an Authorization header and you can pass this data along 89
when you make your requests. 90
Let's see how this works in practice by trialing it through Postman. 91
The API that we're going to be using is another one of our own APIs and it's called the Secrets API. 92
So this API is all about putting your confessions into a database and for people to be able to share 93
and view each other's secrets anonymously. 94
The API has different endpoints with different levels of authentication. 95
What we can do with this API is we can register a new user by passing over a username and password in 96
the body of the POST request. 97
And once we've registered ourselves on the service then we can use that username and password to perform 98
a request using Basic authentication. 99
The way that our endpoints on this REST API works is if you wanted to get a random secret from the database 100
of secrets, then you don't need to authenticate yourself because we're sending over a small piece of 101
data, 102
people are probably not going to hit up this route too often, but if you want something a little bit 103
more involved, a little bit larger in terms of size of the response and also a little bit more precious 104
in terms of our resources, then we have a gate. 105
So we use basic authentication to make sure that at least you are a registered user, 106
and if down the line, we want to make sure that we check which users are making lots of requests, 107
say you want to have a paid tier for your API, all of that kind of stuff is possible. 108
So let's make a request to this endpoint using Basic authentication and Postman. 109
So I've got Postman up here on the right and I'm making an HTTP GET request and the URL that I'm going 110
to hit up is this particular URL. 111
This is the base URL for our API, secrets-api.appbrewery.com and I encourage you to read through the docs as 112
always before you make any sort of request to an API. 113
And what this API has is it has a Query Parameter called "page," because when you get hold of all pieces 114
of data, say all the secrets on the database, it's going to be a lot of data and we don't want to 115
send massive amounts of data over the Internet when people are making API requests. 116
So normally what people do, these API providers is they can paginate the response, so they'll give 117
you 10 at a time or 20 at a time and you can request which page you want, maybe you'll request 118
Page 1, 119
and then once you've dealt with the data there, you can request Page 2 and so on and so forth. 120
This is simply one of the parameters that we can add into the query parameter to determine the type 121
of response we get back. 122
The important thing now is authorization or authentication. 123
And the type that we want to use is the Basic Authentication. 124
We have to type in a username and a password in order for this to work. 125
What I want you to do is to go ahead and use this endpoint POST/register to register yourself 126
a username and password, and then once that's done, go ahead and use that username and password to hit 127
up the /all route. 128
Pause the video here and give that a go. 129
All right. 130
So let's run through this. 131
The first step is to make a POST request to the register route. 132
Let's go ahead and hit up the correct endpoint and then we're going to pass over some Body parameters 133
in the format of form-urlencoded. 134
And we have two KMeys, a username and a password. 135
And I'm just going to put in a random user, let's say our jackbauer user. 136
Let's say Jack Bauer wants to use our API and he wants to confess to some of his deepest, darkest secrets. 137
So I'm going to type a password and then I'm going to go ahead and hit Send to make this request. 138
And hopefully you'll see down here in the responses that we get a status: 200, which means everything 139
went okay and that I am now successfully registered. 140
Keep a hold of your username and password because we're going to need it in our Basic authentication 141
to try and request all of the secrets. We've got, our type of authorization selected as, Basic Auth, 142
and then I'm going to type in my username and password. 143
Once I've got both of those pieces of data, hit Send and you'll be able to see that we've got our secrets 144
coming back, ten per page. 145
Now I wanted to mention that when we're using Basic Authentication using Postman, it's actually doing 146
some magical stuff behind the scenes 147
for us. What it's doing is it's generating the authorization header automatically based on the username 148
and password that you've provided here. 149
So you can see this if you go over to the Headers tab and you can see they've automatically generated 150
this header with a key of authorization and a value of Basic with the B capitalized space and then a 151
string that represents your username and password. 152
Now I can prove this to you if you go ahead and copy your own string that you have in Postman that's 153
generated here and go to a website called base64decode.org and paste that string into the top box, 154
hit Decode and you can see it automatically decoded it to the original format, which is username : 155
password. 156
And that is basically what's happening behind the scenes here. 157
So when you're making server-side requests that need basic authentication or authorization, you can 158
also do this yourself. 159
Create the headers, use this as a string, convert your username and password, add in the word Basic 160
and add this as a header. 161
But in most cases, if you're using a library like Axios, it'll be able to generate all of that for 162
you by providing your username and password. 163
All right. 164
So did you manage to get this to work? 165
Did you manage to use Basic Authentication to authenticate yourself with the API provider and get hold 166
of some secrets? 167
Like I talked to my pet fish and imagine they're responding to me with witty comebacks. 168
"Uh, we've all been there." 169
We've now seen No authentication and Basic authentication in action when it comes to APIs. 170
Now let's go ahead and take a look at API Key Authorization. 171
One thing you'll notice is that this term authorization, if you're in the US, that's spelled with 172
a Z, but I'm in the UK, so it's spelt with an S, authorization versus authentication. 173
What is the difference? 174
Because you hear it a lot and you're often wondering, well, am I using authorization or am I using 175
authentication? 176
So the difference between these two forms is if you have a user, they can authenticate themselves with 177
your service. 178
That means you are logging in or you are registering. 179
But authorization is simply a client who is allowed to use your service with an API key that might be 180
associated with a user, in which case they are authenticating themselves and then getting an API key 181
to authorize themselves to use your API. 182
But it could just be you don't even need to register with the API provider and you can simply get hold 183
of an API key and authorize yourself with the API provider. 184
That is the difference. 185
Authorization is something that allows you to use an API. 186
Authentication is something that allows you to be identified as a user to the API provider. 187
You'll see that a lot of public APIs use API keys and it's really useful because you can then track 188
the usage per API key. 189
So for example, if you signed up for the Google Maps API, you can use all sorts of different APIs 190
that they provide, for example, the Places API to find all the different things that show up on Google 191
Maps, 192
or you can use the Distance Matrix to calculate the distance between two points in time, again, using 193
Google's APIs. 194
And every single time when you make a request, you need to use this key before you can get back a response, 195
then they can log, well, how many requests are you making with that key? 196
So you can see in this case they're using the places API 200,000 times per day. 197
So you're making 200,000 requests per day. 198
And as with most public APIs, they have to stand up their own infrastructure, their own servers, 199
they have to maintain these server computers, etcetera. 200
There's a lot of costs involved, so it's often that they will charge you for using their APIs. 201
For example, in this case, this person is racking up $2,000 worth of API usage and by looking at how 202
often you're needing to make requests through your API key, they can determine how much they should 203
charge you. 204
This is useful to know both as an API user as well as an API provider and in future lessons we'll see 205
how we can create our own APIs and we'll look at the other side of the coin. 206
But for now let's focus on the client side. 207
The easiest side for now, if you go back to our Secrets API documentation, you can see that we have 208
some endpoints that require an API to authorize your usage and in order to get hold of an API, there 209
is the generate API key endpoint, which for now we've kept it pretty simple. 210
Just allows you to hit up this route, make a GET request and get your own API key to use. 211
And once you've generated the API key you can scroll down to the filter endpoint. 212
This endpoint allows you to return some secrets with a particular embarrassment score, so you'll see 213
that each of the secrets are associated with embarrassment scores or the emScore. 214
And this is just a way for the user to provide a piece of metadata about; 215
on a scale of 1 to 10, how embarrassing is your secret? 216
And by using this filter endpoint, we can provide this score as a query parameter and then we can provide 217
a number to say what is the minimum embarrassment score to filter for? 218
But most importantly, in order for this request to pass, we also need to pass the API key as a query 219
parameter. 220
And this is the key that we generated previously from this step, generate-api-key. 221
So I want you to pause the video and give this a go using the 222
documentation from secrets-api.appbrewery.com. I want you to use Postman to get hold of all the embarrassing 223
secrets that have an embarrassment score of seven or more. 224
So pause the video. 225
Give this a go. 226
All right. 227
So the first step we need to do is we need to generate an API key. 228
So we would go on to the website. 229
Maybe we would give our card details, maybe we would need to sign up and log in, 230
but either way, at some point we will hit up this endpoint and get the API to give us an access key. 231
Once we've gotten hold of the access key, then we can go and hit up the routes that require it. In the 232
Secrets API, 233
that is the filter endpoint, 234
we can make our requests to this endpoint. 235
/filter and we can add the parameter which is called score that tells the API what is the 236
minimum score 237
we want to filter by and I'm setting that to 7. 238
Coming into Authorization, we can provide our API key here where we say what is the Key and what is 239
the Value. 240
The key here is apiKey, spelt with a capital K, as you can see in the docs and our value, I'm just 241
going to paste in from the point where we got it from and we're going to add it to the Query Parameters. 242
With API keys, 243
sometimes the API requires you to add it to the Header of the request and other times it requires you 244
to add it to the Query Parameter. 245
It depends on the API and you should always read through their docs to figure out what you need to do. 246
So now we're ready to go ahead and hit Send. 247
And once you've done that, hopefully you've got a correct key, then you should get back some secrets 248
that are all filtered by the emScore. 249
So let's see, what are some of these embarrassing secrets? 250
"I have a secret collection of embarrassing childhood photos that I use to blackmail my siblings." 251
Pretty useful, sibling blackmailer. 252
All right, so now let's look at the final form of authentication that we want to cover, which is Token 253
Based Authentication. 254
Why is it that we're increasing in levels of security? 255
Well, no authentication is obvious, but Basic Authentication uses a username and password that's passed 256
over as a Base64 encoded string in the header. 257
As you saw, I was quite easily able to use the Base64 decoder to get back in clear text the username 258
and password. 259
Now that means it's equally possible for somebody on the internet to intercept your API requests and 260
to be able to do the same. 261
So why do we still use it? 262
Well, most API providers that use Basic Authentication will have HTTPS on their domain, which means 263
that we're using cryptography to securely encode all the data that being passed back and forth. 264
And even if somebody intercepts the packets, they won't be viewing the string as what we saw, 265
instead, it will be mumbo jumbo that they cannot decode. 266
But nonetheless it is still passing username and password, 267
and if it's a less secure website or there is something that goes wrong, then there is a risk there. 268
Now API Key Authorization is a little bit more secure because nowhere do we actually type in our username 269
and password, 270
instead we have this API key which can be deleted and regenerated. 271
It can have caps on it, so you can rate limit it. 272
You can say, "I'm generating this key, but I only want to make say a thousand requests a month, so I'm 273
only paying for that amount." 274
So even if somebody intercepts this API key, they won't be able to get hold of the username and password. 275
They won't have any of your payment details. 276
It is just a reusable code that you're using to access an API. 277
Finally, the Token-Based Authorization or authentication is even more secure because essentially we're 278
getting the user to use a username and password to log in and then once they've logged in, we generate 279
a token to be used with the API so the API doesn't get involved with the username and password and instead 280
it's the token that's constantly being used to interact with the API. 281
Normally you'll see Token Based Authentication as OAuth and OAuth 2.0 is probably the industry standard 282
for doing token-based authentication. 283
And this is kind of what happens behind the scenes. 284
You have a user for a service and you want to be able to act on their behalf, so you get them to sign 285
in with their username and password on the API provider's website and then 286
the API provider generates a token off the back of that. 287
And then this token can be passed back to you as the third party and you can use this token to interact 288
with the API. 289
So let's see this as a real life example. 290
So let's say that you are building a third party app, say it's a weather app, but you have a special 291
twist on the app where you are going to get hold of a user's events in their Google calendar. 292
So you want to see that they have a meeting, for example, on Tuesday and it's happening in Baltimore. 293
So you grab all of these pieces of data and you look at the weather for that location and that date, 294
and maybe you would be able to send the user an alert to tell them to bring an umbrella to that particular 295
event. 296
That's the idea behind interacting with the Google Calendar APIs for the user to be able to grant you 297
access to this data. 298
Well, what you have to do if you weren't using token-based authentication, then you would have to 299
give us, this third party, the username and password, so that we can use this to interact with the 300
Google calendar API. 301
Instead, what we're able to do is we can use token-based authentication or OAuth to get the user to 302
sign in with Google, and this generates a token for us to get hold of and then we can use this token 303
to interact with the Google Calendar API. And then we can get hold of the user's events, their meetings, 304
we can even post data or delete data, 305
we can basically interact with Google calendar as this user without ever needing to get hold of their 306
username and password. 307
And instead all of that security stuff is handled by Google. 308
So this is a way more secure way of doing API authentication. 309
And every time you've seen this screen where it's asking you to authorize a particular app on the behalf 310
of your Google account, then you have performed this process. 311
But let's see it more concretely using our API. 312
If you take a look inside the Secrets API, you'll see that there is a path that allows us to get hold 313
of secrets based on the ID of the secret. 314
This path is protected by Bearer Token Authentication and Bearer Token Authentication uses a user's 315
username and password to authenticate themselves on our server, and then our server generates a token 316
that will be used as a proxy for anybody else to interact with the API as that user. We can use the 317
get-auth-token path by posting a request with a body of username and password. 318
Once the server has successfully authenticated that user, then they will pass back a token and we can 319
use that token then to interact with the rest of the API. 320
And you'll see this very commonly when you want to say post something on behalf of a user or change 321
something or delete something on behalf of a user, you're basically interacting with a service as if 322
you were the user, 323
but because we're using token-based authentication, you never need to get hold of their username and 324
password and we can keep all of that secure. 325
Let's give this a go. 326
Open up Postman and see if you can figure out how to get hold of the secrets using this endpoint and 327
get hold of the secret with an ID of 2. 328
Pause the video. 329
Give this a go. 330
All right. 331
So first we need to use this get-auth-token path in order to get an authentication token and we're going 332
to make a POST request to this path. 333
So let's change that. 334
And we want to add in into the Body some form-url encoded data and we want to pass it over our username 335
and also our password. 336
I'm just using the username and password that I got Ahold of earlier when I registered myself and I'm 337
going to pass in the values. 338
And then I'm going to go ahead and hit Send. 339
If you're doing this for the first time, you'll see your token being generated. 340
If you're doing this for the second time, you're still getting the same token. 341
But it's telling you that you have already been issued a token and it's just reminding you of what it 342
is. 343
Both options could happen, but once we've gotten hold of our token, then we can use it to get hold 344
of a secret with a particular ID. 345
Let's go ahead and copy the endpoint and I'm going to change this url parameter to get hold of the secret 346
with an ID of 2. 347
So now, before I can send it, I need to change the authorization to a Bearer Token Authorization and 348
I'm going to paste in the token that I got back from the previous step in here. 349
And just like what it did with basic authentication, Postman is generating an authorization header 350
behind the scenes 351
automatically based on the token that you put in here. 352
And you can see this by going to the Headers, you can see that it's generated a Header with key of 353
authorization and value of Bearer, and then the token that you have added in here. 354
If you're doing this by yourself using just code, then this would be the full value of that header 355
that you're sending over with your request. 356
So now let's go ahead and hit Send and hopefully if everything worked, we'll get back the secret with 357
an ID of 2. 358
Now, it's time to try an exercise and do everything that we did just now, exploring the different ways 359
of authenticating yourself or authorizing yourself with an API, 360
but instead, this time we're going to do it with code. 361
Go ahead and download the starting files 5.4 API Auth.zip extract the zip and open it up inside VS Code. 362
Once you're here, the first thing I want you to do is to cd over to the API Authentication folder and 363
then I want you to do your usual thing where you use "npm i" to install all the required node modules. 364
And then I want you to go to solution.js without scrolling down, without looking at the solution. 365
I want you to update all of these constants using yourUsername, yourPassword, yourAPIKey, 366
yourBearerToken that you generated earlier when we were going through each of the steps in Postman. 367
And once you've done that, then I want you to use Nodemon to run the solution.js and then we can 368
head over to localhost:3000 and you'll see this basic website. 369
Now, what we're able to do here is we can hit on each of these different authentication buttons. 370
No Authentication gives us a random secret. Basic Authentication 371
will hit up the GET/all path. 372
The API Key Authentication will get us the filtered endpoint and Bearer Token Authentication will get 373
us a secret with a particular ID. So you can see we're using all of the same endpoints that we did using 374
Postman, but this time we're actually hitting it up from our server, so we're doing server side requests 375
using Axios, but we're also making sure that we learn how to do that using all of the different types 376
of authentication. 377
Take a look inside the Index.js and I have a bunch of TODO's for you to be able to work through this 378
and you might need to remind yourself of how to make requests using Axios and you might need to use 379
some of the hints that are available in each of the steps, 380
but essentially, you should be able to complete this server-side code so that it works the same as the 381
solution.js 382
Pause 383
the video now and give this a go. 384
All right. 385
So how did you get on with that? 386
Let's go through the solution code and see if you managed to get it to work. 387
The first step is to fill in all the values that you had from the three different types of auth, 388
and once you've done that, we're going to use each of these constants in the different types of authentication. 389
So the first one we're going to do is actually the route that has no authentication. 390
So we're using a "try, catch" block and we're using Axios to make a GET request to our API URL at the random 391
endpoint. 392
This is pretty simple. 393
And then once we get back the data, we pass it over to the Index.ejs and we use JSON Stringify to pass 394
it over just as a simple string instead of a JavaScript object. 395
This content is then caught in the index.ejs and displayed in this box right here. 396
This is just to whet our appetite and get us started, 397
the next one uses Basic Authentication and if you got stuck on how to do this, as always, there is 398
Google out there as your friend. 399
But even better than Google is me as your friend because I've actually provided this hint to show you 400
how you could have searched to find this particular StackOverflow question, which is, "How do you send 401
Basic Authentication with Axios?" 402
That's pretty much what we want to do here. 403
Right? 404
And it tells us that there is an auth parameter that we can add to our requests by adding in a username 405
and password. 406
What we're able to do is we can provide this auth after we've provided the endpoint and we can add in 407
our username or password under this parameter name of auth and it will do all of that Base64 encoding 408
for us and then we can send over this request and we should be able to get back our data, which again 409
we turn into a string and send over to the front-end. 410
Now the next one uses the API key. 411
And remember, in our case, the API key is also sent over as a parameter. 412
With Axios, we can send parameters like this. 413
Alternatively, we can simply add them onto the end of our URL. 414
Both ways are correct. 415
It really depends on which one you want to use. 416
And if you've searched around or you looked at the Axios docs, you might see something like this, 417
but you might also see other people add it straight into the endpoint. 418
It doesn't really matter whichever way you did as long as it worked. 419
We had to provide a parameter in the form of a score. 420
The embarrassment score that we want to filter on, and also our API key. 421
And once we get back the data again, we pass it over to the front-end. 422
Now the final one we have requires a Bearer Token. 423
So in this case we're hitting up the secrets endpoint and we're providing the ID of 2 to get hold 424
of that particular secret. 425
Now I'm passing in the config so that I can provide a parameter for the headers parameter. 426
And in here I'm putting in the Authorization as the key and the value as the word Bearer with a capital 427
B, a space, and then the Bearer Token that we generated earlier on. 428
And again, I added a hint to maybe how you can figure this out, but essentially this is the config 429
and you can either add this object straight into here, as we did with our parameters or with our authentication, 430
or you can separate it out whichever way you prefer. 431
Then we make the GET request, we get back the data and we send it over to the frontend. 432
If you got stuck or something didn't work, make sure you review the solution.js code and fix your code 433
so that you get it to work. 434
You can also take the code and figure out where you went wrong and understand what it is you have to 435
do in order to get it to work. 436
But hopefully you managed to try out all of the different forms of authentication using code and using 437
Postman. 438
In the next lesson, we're going to be using some of that authentication, but we're also going to be 439
exploring some of the other parts of this REST API. 440
So for all of that and more, I'll see you there.