Secure APIs with FastAPI and the Microsoft Identity Platform Transcripts
Chapter: Introduction to Identity
Lecture: Introduction to the OAuth2 protocol
0:00 Let's take a look at the OAUTH 2 protocol OAUTH 2 current version of OAUTH is an industry standard protocol for authorization.
0:10 An open protocol to allow secure authorization in a simple and standard method from web, mobile
0:18 and desktop applications. This specification and its extensions are being developed within the IETF OAUTH working group. Okay, this doesn't say much.
0:28 So let's look at how we got here and why OAUTH 2 is indispensable when building secure apps. As developers,
0:37 we usually have to build systems that interact with external systems. Think of a scenario where you're building a new email client.
0:45 This client needs to retrieve your users emails from gmail before OAUTH 2 the only way to do this was to ask the user for their gmail credentials.
0:57 We would then use these credentials to sign into gmail as that user and retrieve the emails. If this is raising red flags,
1:06 you're absolutely right as a user, this is an awful experience. You have to entrust your credentials to random up and
1:15 as a developer you now have to think about how to secure the storage and retrieve
1:20 these credentials. This created a lot of opportunity for abuse and security issues and believe
1:25 it or not, it was the norm until OAUTH2 was created. This authorization
1:31 protocol allows developers to build systems that interact with other systems without the need to touch any credentials using the same scenarios above.
1:41 Instead of asking the user to provide their credentials so that our email client can get
1:46 access to their gmail data. The user is instead redirected to gmail to sign in
1:52 and provide the necessary consent to enable the email up power up access keys or
1:59 emails upon successful authentication and authorization Gmail returns an access token back to the.
2:06 email app the email client then uses this token request the necessary data and only the data that the user has consented to
2:14 no calendar data, no photo data, just emails. The nice thing about this approach is that passwords are never passed around
2:23 from server to server. Let's look into what a typical OAUTH2 flow looks like as well as the various components.
2:31 In terms of components we have a client or application and the user.
2:36 The client interacts with an authorization server and there is your server in order to authenticate
2:42 and access the resource state. First the application sends an authorization request to the authorized
2:49 endpoint. The authorizing point returns back an authorization grant a code.
2:55 Then the application is using that authorization grant to go to the token endpoint and request
3:02 an access token. Upon successful completion of that handshake the application gets back and access
3:08 token. This access token allows the application to go to the resource and request access
3:14 on behalf of the user. The resource validates the access token and then it turns back the secure data to the application.
3:24 This is a high level simplified explanation of the OAUTH2 protocol.
3:29 A way for apps to authenticate and communicate with each other without using hard coded user credentials.