Intro to Authentication - User and API Auth — Transcript

Full transcript

1. 0:00Hey, what's going on? In this lesson,
2. 0:01we're going to start our discussion on
3. 0:03authentication for user authentication
4. 0:06and API authentication. We'll talk about
5. 0:08some of the differences there. Before we
6. 0:09get started, I did want to mention that
7. 0:10this is part of a larger series, so you
8. 0:13can check out the description for the
9. 0:14playlist link, as well as a link to get
10. 0:16the notes for this lesson and all of my
11. 0:19other videos here. So, if you want to
12. 0:22follow along both video and notes, then
13. 0:24I would highly recommend you check that
14. 0:26link out. And finally, I wanted to
15. 0:28mention that I did complete my
16. 0:29fundamentals course. So, if you want to
17. 0:31get software engineering fundamentals
18. 0:32for beginner, intermediate, and advanced
19. 0:34topics, I will have that link down
20. 0:36below, as well. Check out my software
21. 0:38engineering fundamentals course if
22. 0:39you're looking to build a solid
23. 0:41foundation for building software. This
24. 0:43course will take you from the very
25. 0:44beginning all the way through
26. 0:46intermediate and advanced topics with a
27. 0:48focus on core computer science concepts
28. 0:50and applied software engineering
29. 0:52principles that make you a better
30. 0:53software engineer. Follow the link to
31. 0:55get the first section free. So, let's
32. 0:58talk about authentication.
33. 1:04And I will also talk about
34. 1:05authorization. So, very similar topic,
35. 1:07but slightly different in concept. So,
36. 1:09let's just talk about that first. So,
37. 1:11authentication and authorization.
38. 1:17So, let's say we have some web page or
39. 1:19some resource, but this isn't available
40. 1:21for just everybody. We want to know, do
41. 1:23you have the permissions to view this
42. 1:25content? So, what does authentication
43. 1:27have to do with this? Authentication is
44. 1:29you proving you are who you say you are.
45. 1:32So, for example, you go to the website,
46. 1:35it says, "Yo, dog, you can't visit this
47. 1:37page." And it kicks you back to a login
48. 1:39page. So, you log in.
49. 1:42And if you successfully log in, then you
50. 1:45are authenticated.
51. 1:50But just because you've proved you are
52. 1:52who you say you are, it doesn't
53. 1:53necessarily mean you can view this.
54. 1:56So, then it comes down to authorization.
55. 2:04Are you authorized?
56. 2:07So, we'll look at both of these
57. 2:09throughout these lessons. The main thing
58. 2:11you need to understand is that
59. 2:12difference. Authentication is basically
60. 2:14saying, "Hey, it's me. Here's proof." In
61. 2:16this case, it's proof because I have the
62. 2:18username and password for my account.
63. 2:20Then authorization is what you are
64. 2:22allowed to do. Do I have access to this
65. 2:24page? Are there certain features I have
66. 2:26access to and other ones I do not have
67. 2:28access to? That's all related to
68. 2:30authorization. Now, there are two major
69. 2:32classifications for authentication that
70. 2:33I'm going to talk about. We have user
71. 2:36authentication
72. 2:41and then we will also have API
73. 2:44authentication, or you can think
74. 2:46authentication for services.
75. 2:49So, let's first take a very quick look
76. 2:52at user authentication, and then we'll
77. 2:54take a very quick look at API
78. 2:56authentication. Then we'll go into more
79. 2:58details, but I want you to have an
80. 2:59understanding of these categories from
81. 3:00the beginning. So, for user
82. 3:02authentication, that is if you were a
83. 3:03user of a webpage
84. 3:06or some app, and you log in, and this
85. 3:08allows you to access all of the hidden
86. 3:11data. This is basically how login works
87. 3:14for webpages. It's basically a way to
88. 3:16identify the user,
89. 3:19which would make sense from the name.
90. 3:21One of the most common structures for
91. 3:23this would be using JSON Web Tokens, and
92. 3:25we'll talk about what that looks like.
93. 3:26API authentication is a little bit
94. 3:28different. So, let's say we're building
95. 3:29an app, and we need to connect to some
96. 3:32other service,
97. 3:34and this service exposes an API, but
98. 3:36it's not a public API. In order to use
99. 3:38it, you have to use an API key.
100. 3:45>> [snorts]
101. 3:45>> So, this API key kind of acts like a
102. 3:47password to make an API request. So,
103. 3:50you're not going to be able to get that
104. 3:51data back unless you provide the
105. 3:53appropriate API key. And then what is
106. 3:56this over here?
107. 3:57Most likely this is going to be some
108. 3:59back end of an app.
109. 4:02And then this API is likely some
110. 4:03third-party thing you're using. So maybe
111. 4:05that's for maps or maybe it is for some
112. 4:09AI LLM integration or really any other
113. 4:12app out there that exposes an API you
114. 4:15could put there. Now in many situations
115. 4:17you're going to be on this side of
116. 4:19things. You're going to be building
117. 4:20services that use APIs, but there are
118. 4:23situations when you're going to be
119. 4:25building this side as well. So let's say
120. 4:27you built some social network.
121. 4:33And then you release an API and then
122. 4:35other apps can consume your API.
123. 4:40You will need to have a strong
124. 4:41understanding on API authentication
125. 4:43because you're going to want to make
126. 4:44sure that these other services are
127. 4:48authenticated and they're able to use
128. 4:50your API. Otherwise you're just going to
129. 4:52have a public API which you can do, but
130. 4:55in many situations you don't want to do
131. 4:56that. You actually want to scope things
132. 4:58to just authenticated API users. It's
133. 5:01also step one for controlling what they
134. 5:03can and cannot access and things like
135. 5:05rate limiting by user. So if you're
136. 5:07wanting to make an API service layer,
137. 5:09this is going to be very very important.
138. 5:11And in that situation you're going to be
139. 5:12on this side of the communication.
140. 5:15You'll want to be familiar with both of
141. 5:16those sides though. So consuming APIs
142. 5:18using an API key and building APIs where
143. 5:22users use an API key. This one is
144. 5:24definitely more simple because you're
145. 5:26most likely just going to be working
146. 5:27with a front end
147. 5:31that makes a request to some back end.
148. 5:35And we need to understand how that front
149. 5:37end back end flow works. So now that we
150. 5:40understand these two categories, let's
151. 5:41take a deeper look at user
152. 5:43authentication.
153. 5:47And let's say we have some resource that
154. 5:49we can delete.
155. 5:52So, we'll say delete is the method for
156. 5:54the request.
157. 5:56And then this will be something like
158. 5:58{slash} comments.
159. 6:02So, we have the full list of comments
160. 6:04and the user wants to delete one of
161. 6:06them. This is something where we are
162. 6:08still working with an API and this is a
163. 6:10very important clarification I want to
164. 6:12show.
165. 6:14Just because we're using the user
166. 6:15authentication and not API
167. 6:16authentication doesn't mean we're not
168. 6:19going to be working with an API. It's
169. 6:21just that the purpose of the user
170. 6:23authentication is to authenticate user
171. 6:26actions. So, this is basically how the
172. 6:28flow is going to look. We'll have an end
173. 6:30user.
174. 6:32He's really happy because our app is so
175. 6:35good.
176. 6:37He's going to interact with the app from
177. 6:39maybe his mobile phone.
178. 6:43And on there there is a delete button.
179. 6:46When you hit that delete button, it's
180. 6:47going to make a request to the back end.
181. 6:50So, that's the back end, this is the
182. 6:52front end. We need to make sure that
183. 6:54that request is valid based off of the
184. 6:56token they provide. And if it is, the
185. 6:59back end can then issue a delete to the
186. 7:03database.
187. 7:05But we only want to be able to do this
188. 7:08if this user is logged in.
189. 7:14And
190. 7:16they are authorized to do that action.
191. 7:18So, that's the overall flow. [snorts]
192. 7:20It's dealing with what the user can do.
193. 7:24And in code, basically what this is
194. 7:26going to look like
195. 7:30is going to be a protected route.
196. 7:38So, some function that handles the
197. 7:40request, but it's protected, requiring a
198. 7:43correct token saying that they are able
199. 7:46to do this action. So, that's the flow.
200. 7:48Let's talk about what that actually
201. 7:50looks like. First, the user comes to the
202. 7:52page, they log in.
203. 7:55That will give them a token.
204. 7:59And then this token
205. 8:01will then be used with any of the future
206. 8:04requests, such as a delete, anything
207. 8:06that requires the token.
208. 8:09So, anything protected, that token will
209. 8:11then say, "Hey, I'm allowed to do this
210. 8:13action, so you should now do that for
211. 8:15me." So, what happens if the user tries
212. 8:17to do something and they haven't logged
213. 8:19in? So, let's say we try to delete
214. 8:21something.
215. 8:23We can program this to redirect
216. 8:26because the back end will give some form
217. 8:29of off error, basically saying, "Hey,
218. 8:31you need to log in." So, this will allow
219. 8:34us to redirect on the front end
220. 8:37to a login page.
221. 8:42So, the user is now on the login page.
222. 8:45They put in their username and password.
223. 8:47This will check the back end to make
224. 8:49sure that the username and password is
225. 8:52correct and exists in the database.
226. 8:55And in exchange, it will give back a
227. 8:57token.
228. 8:59And I'm going to write JWT here. We
229. 9:01haven't talked about the JWT structure
230. 9:03yet, but it's just a token that this
231. 9:06user will keep.
232. 9:09And the token basically says, "Hey, I
233. 9:12logged in at some point,
234. 9:18so we know that it's a valid user." And
235. 9:21inside that token, we can also have any
236. 9:23kind of permissions
237. 9:25or authorization stuff.
238. 9:30Once they have that token, they can then
239. 9:32go back and retry
240. 9:36that initial thing that they were not
241. 9:38allowed to do. So, this is exactly what
242. 9:40happens when you go to a webpage, maybe
243. 9:42you step away for a couple of hours and
244. 9:44you come back, the webpage is still
245. 9:46loaded there. So, you do something that
246. 9:49would require you to be logged in, maybe
247. 9:51you delete something, but your login has
248. 9:54expired, so it redirects you to a login
249. 9:56page, you log in, and then it may
250. 9:59re-execute that action or ask you again
251. 10:01to do that action. That's the exact flow
252. 10:03of what's going on behind the scenes.
253. 10:05Also, that says login. I was like
254. 10:08looked like a B. I couldn't figure out
255. 10:10what it said. So, here's how a token
256. 10:11works.
257. 10:15So, I mentioned we go through a login
258. 10:17page, and if we get the credentials
259. 10:19correct, the server will issue a token.
260. 10:22So, here we have the backend server, and
261. 10:25this backend will
262. 10:27sign
263. 10:30the token.
264. 10:32And this gets a bit into
265. 10:36cryptography, but basically this digital
266. 10:38signature here is what will allow us to
267. 10:40verify the token in the future.
268. 10:42So, when [snorts] we send the token back
269. 10:45to the user,
270. 10:46and then the user makes future requests,
271. 10:54this gets sent to the backend, and the
272. 10:56backend can verify
273. 11:00the token authenticity.
274. 11:07If the client were to tamper with the
275. 11:09token, try to adjust their permissions
276. 11:12or anything like that, it's going to
277. 11:14invalidate the token because the client
278. 11:16is not able to sign because to sign, you
279. 11:21have to have a signing key.
280. 11:25And this signing key is a secret value
281. 11:27that only the server has. So, when you
282. 11:29get into user auth, you often have that
283. 11:32secret key. That's very important to
284. 11:34protect because it is used for signing
285. 11:36these tokens. The signing is important
286. 11:38because it allows the backend to later
287. 11:40verify the tokens that are sent from the
288. 11:43client. If the client were to modify the
289. 11:46token,
290. 11:48this would produce a different signature
291. 11:52because the client does not have the
292. 11:55signing key. It never leaves the server.
293. 11:57So, the server would be able to identify
294. 11:59that this is a phony token. So, what is
295. 12:01a token and what does it actually look
296. 12:03like?
297. 12:06Well, if you look at a token, it's just
298. 12:07going to look like a random sequence of
299. 12:09characters and numbers. So, behind that
300. 12:12is encoded information. So, let's take a
301. 12:14look at it in more detail. So, let's
302. 12:17take a look at JWTs or JSON web tokens.
303. 12:20I'm going to do a dedicated video on
304. 12:22JSON web tokens. So, this is a very
305. 12:24light intro, but it's basically just
306. 12:25going to look like random numbers and
307. 12:28letters
308. 12:31separated by dots. And they're going to
309. 12:34be a lot more. I just don't have much
310. 12:35space. So, maybe I'll put like
311. 12:38three dots here.
312. 12:42And then a dot, and then another section
313. 12:44of characters.
314. 12:47And then another dot, and then another
315. 12:49section of characters.
316. 12:51So, we basically have three sections
317. 12:52here. I wrote that pretty bad, but
318. 12:54that's okay. This one is called the
319. 12:57header.
320. 12:59This one is the payload.
321. 13:03And this is the signature.
322. 13:07The way you can imagine the signature
323. 13:09being made is something like this, where
324. 13:11we
325. 13:12invoke the signing,
326. 13:16but we use the existing information.
327. 13:22And then we use the signing key
328. 13:25that only the server has. So, the fact
329. 13:27that we are embedding this information
330. 13:29into the signature, changing this
331. 13:31information will change the actual
332. 13:35signature value here.
333. 13:37That's an important component if you
334. 13:38want to understand how JWTs work because
335. 13:40that's what allows the prevention of
336. 13:42tinkering with these values on the
337. 13:44client. The client shouldn't be able to
338. 13:46touch these and get the server to trust
339. 13:49that token. It is not going to be
340. 13:51possible because if they mess with this
341. 13:54data, that is part of the signature
342. 13:56which requires the signing key. So, we
343. 13:58don't have that signing key, we would
344. 13:59have to use a different key and the
345. 14:01token would be invalid. Now, because the
346. 14:02server is the one creating these tokens
347. 14:05and validating them, the server can put
348. 14:06whatever it wants in this payload.
349. 14:09And that could be even something like if
350. 14:11that user is an admin or what
351. 14:13authorization things they have. So, this
352. 14:15payload maybe contains their user ID
353. 14:20which we could then use to look up that
354. 14:23user in a database.
355. 14:26But, we could also just embed any other
356. 14:29information that could be useful in the
357. 14:31payload such as if this user is an admin
358. 14:34or any other kinds of privilege
359. 14:36attributes. So, in this situation, all
360. 14:39of the authorization is self-contained
361. 14:43in this token and we don't even have to
362. 14:45make a database request. And the way
363. 14:47this works is if this was changed,
364. 14:51let's say the user wanted to tinker with
365. 14:54this token, they changed admin to true,
366. 15:04well, this would force the token to be
367. 15:06invalid.
368. 15:10Again, just going back to the fact that
369. 15:13the client does not have the signing
370. 15:15key, so
371. 15:17we're not able to make any changes to
372. 15:19the token that the server would then
373. 15:21accept. So, those permissions are pretty
374. 15:23much baked into the token. It's the full
375. 15:26access pass. You don't want that token
376. 15:28to be taken by a malicious user because
377. 15:31they could act on behalf of another
378. 15:34user. Whatever token they have, it's
379. 15:37full access. It's as if the user logged
380. 15:39in themselves. And it's self-contained,
381. 15:41so this is stateless.
382. 15:45So, that means if we had an API
383. 15:47endpoint,
384. 15:48we can think of that API endpoint in
385. 15:50isolation. It doesn't need to access a
386. 15:52database or do any extra stuff. All it
387. 15:54needs is the request and a token.
388. 15:59And that's enough to give permissions to
389. 16:01do things.
390. 16:02Now, let's take a look at API keys.
391. 16:06Similar ideas, but there are some key
392. 16:08differences. So, an API key will allow
393. 16:12the user in the situation, which is most
394. 16:14likely going to be some other service.
395. 16:17So, it will allow the service to do
396. 16:20things, but most of the times it's not
397. 16:23stateless.
398. 16:30So, it's a different structure than a
399. 16:32JWT.
400. 16:34And you can think of it sort of just
401. 16:35like a password. You make an API
402. 16:37request, you include the API key, the
403. 16:40backend will take the key,
404. 16:44can check against the database to see
405. 16:47any kinds of permissions.
406. 16:51If we're good to go, we can send the
407. 16:53data back to the user.
408. 16:56Or the service in this case. So, what
409. 16:58this could look like is you might sign
410. 16:59up for some
411. 17:01API, and in here you might have multiple
412. 17:04keys.
413. 17:07So, you can imagine logging in to your
414. 17:09account for the platform. You can go to
415. 17:12your API keys, it lists them out. Every
416. 17:14single one of these keys can be seen as
417. 17:19separate logins effectively.
418. 17:23And they might have different
419. 17:25permissions,
420. 17:27separate spend tracking,
421. 17:31or separate rate limiting.
422. 17:33These things could be set by service B,
423. 17:36or you could set them potentially. So,
424. 17:39when you create that API key, you could
425. 17:40say, "Hey, here's the permissions I want
426. 17:42this key to have." And we could
427. 17:43potentially even limit that key so it
428. 17:45doesn't spend more than this many API
429. 17:48credits or make this many requests. So,
430. 17:50in that situation, you could just use a
431. 17:52single one of these API keys
432. 17:54for an application,
433. 17:56and you could use these other ones for
434. 17:58something else.
435. 18:02So, instead of thinking of the API key
436. 18:05as just full access to the API, you're
437. 18:08usually going to be able to limit those
438. 18:10capabilities. Now, what I'm describing
439. 18:11here is a pretty common structure, but
440. 18:14you could see variations. For example,
441. 18:16you could probably make these API keys
442. 18:19be signed and not require database
443. 18:22access, or maybe you get a key per user
444. 18:25instead of a user being able to create
445. 18:27multiple keys. There are a lot of
446. 18:29variations, so what I would recommend is
447. 18:31just taking a look at some of the
448. 18:32different API platforms out there. Maybe
449. 18:35take a look at some popular social media
450. 18:37networks, look at some payment
451. 18:39processors. So, maybe look at Facebook
452. 18:41and Stripe and see how they run their
453. 18:43APIs. Ultimately, both user auth and API
454. 18:47auth are trying to achieve the same
455. 18:49thing,
456. 18:50just slightly different in approach. So,
457. 18:52this is how I decided to group them, but
458. 18:56you might see slight variations or some
459. 18:58crossover in concepts. So, for example,
460. 19:01with JWTs and user auth,
461. 19:07you can still check the database
462. 19:10if you needed to keep track of invalid
463. 19:11keys or any other things related to
464. 19:15specific keys, you can store that all in
465. 19:17a database. So, it's not the case that
466. 19:18if you're using JWTs, you never use a
467. 19:20database. Now, one big difference
468. 19:22between JSON web tokens and other tokens
469. 19:25is that JWTs
470. 19:27can be decoded,
471. 19:31but other keys are typically opaque.
472. 19:36So, what that means is if you have an
473. 19:38API key, it's going to look like a bunch
474. 19:40of random characters. Those characters,
475. 19:42you're not going to be able to interpret
476. 19:44those in some way unless they sometimes
477. 19:47will put something at the beginning. So,
478. 19:49it might have like the service
479. 19:52and then like a hyphen and then all the
480. 19:54random characters. But, the the main
481. 19:56point here is that you're not going to
482. 19:58have information in that token that you
483. 20:01could see. Whereas with a JSON web
484. 20:03token, you can decode this
485. 20:06on the client side even, not just server
486. 20:08side,
487. 20:09and see the payload.
488. 20:13So, you might see something like this.
489. 20:18And obviously, I'm going to be an admin.
490. 20:21This is just encoded, and encoding is
491. 20:24different than encrypted. The
492. 20:26information is still retrievable, it's
493. 20:28just not immediately visible unless you
494. 20:31decode that information. So, if you want
495. 20:33to know more about that, you can read
496. 20:35about base 64 encoding. Whereas API
497. 20:37keys, you're not going to be able to
498. 20:39just decode those and read the
499. 20:40information.
500. 20:42And it's probably more likely that the
501. 20:45API platform will access the database to
502. 20:49get additional information about your
503. 20:51permissions for that API key
504. 20:53or to check if the API key is valid.
505. 20:56Since you're often given the capability
506. 20:58to immediately invalidate tokens, we
507. 21:01basically need a way to know if a token
508. 21:03is valid. And for that, you often have a
509. 21:06database for invalid API keys.
510. 21:10Now, let's talk about how API keys and
511. 21:12JSON Web Tokens are actually passed.
512. 21:15They are typically included in the web
513. 21:17request in an authorization header.
514. 21:22And then the next thing here is the
515. 21:23authorization scheme, which typically is
516. 21:26just going to be bearer.
517. 21:30And then the actual key.
518. 21:33So, let's put some random numbers here.
519. 21:38So, this is what that header would look
520. 21:40like with that request. If you're doing
521. 21:42it from an application,
522. 21:45you can often include headers with your
523. 21:48requests.
524. 21:50So, you'll need to understand the syntax
525. 21:52to include an authorization header,
526. 21:55which should be pretty simple. Just look
527. 21:56it up.
528. 21:57Or if you're doing it from some other
529. 21:59client, such as Postman,
530. 22:02there's probably some way to include any
531. 22:04authorization headers from the menu or
532. 22:07wherever it may be. So, whatever tool
533. 22:08you're using, you know, maybe it's
534. 22:10Incode, maybe it's some tool, or maybe
535. 22:12you're making just like curl requests or
536. 22:14whatever it may be, you need to include
537. 22:16this as a header. Typically, it's going
538. 22:18to be
539. 22:19with the bearer scheme authorization
540. 22:21header.
541. 22:22>> [snorts]
542. 22:23>> But, you might see custom stuff, so you
543. 22:24might see something like X
544. 22:30API key.
545. 22:32This is a custom header. So, the client
546. 22:34can include arbitrary headers, and then
547. 22:36the server would just need to know to
548. 22:37check for that. So, you may see that as
549. 22:39well, but I would say this structure is
550. 22:42the most common. So, that's your
551. 22:43introduction to authentication with JSON
552. 22:46Web Tokens and API keys. We have a lot
553. 22:48more topics for this, so stay tuned.
554. 22:51First thing you should know is a better
555. 22:53understanding of JSON Web Tokens,
556. 22:55because that will deal with access
557. 22:56tokens and refresh tokens, so you'll
558. 22:58want to understand that. You should also
559. 23:00understand social logins and OAuth.
560. 23:02There are topics like throttling and
561. 23:04rate limiting and a variety of other
562. 23:06things dealing with APIs and user
563. 23:09logins. So, stay tuned for the upcoming
564. 23:11content. If you have any questions or
565. 23:13different topics you'd like to see me
566. 23:14cover, leave a comment below. Be sure to
567. 23:16check out the notes, the courses, and
568. 23:18anything else down in the description
569. 23:20and I will see you in the next lesson.
570. 23:22Thank you.