Secure APIs with FastAPI and the Microsoft Identity Platform Transcripts
Chapter: Web and headless clients
Lecture: Application types
0:00 Welcome back everyone with our secure API. In place. It's now time to create applications.
0:07 I can call it and get some data back. When it comes to working with applications there are generally two types from an identity perspective.
0:15 Interactive and non interactive apps. Interactive apps.
0:19 Again from an authentication perspective our applications where a user is present enable to well you
0:26 know interact with the UI. In this case the authentication falls on the user.
0:30 They have to provide their user name and password to authenticate and consent to an application using their data. Their information.
0:38 The non interactive apps however, are usually automation programs,
0:41 Headless applications or Daemon that have to use a different flow to authenticate and acquire tokens to call other API's. Or resources.
0:49 Think of a console application that needs to pull some data from a secure back end
0:53 perform some data transformation or queries and then upload the data back to a different
0:58 system or even create a report sounds like a business of line application. Right? But another very common scenario is when you have an
1:05 API. That needs to call another API. So your front end calls an API. And then that middle tier API has to call one or multiple API's.
1:14 To get some data. And in that instance that API. Is acting as a headless application,
1:20 there's no user interaction. These are some common scenarios where non interactive authentication needs to
1:26 take place with these differences in mind there are a couple of considerations.
1:31 Interactive authentication is obviously more secure since we need a user present,
1:35 the user owns their credentials and the application is only there to receive a token once the authentication is successful. However,
1:43 in non interactive authentication scenarios, the application itself has to know the credentials in order to sign in with the identity provider.
1:51 The credentials are usually in the form of a client ID and client secret in effect, a user name and password or in the forum of a client ID.
1:59 And certificate, which has to be configured both on the running system and
2:04 the identity provider. Now the recommended way and best practices to use a certificate as
2:09 it is much harder to steal and businesses usually have better processes for managing and renewing
2:15 certificates. However, for the purpose of this course, we're only going to use client iD's.
2:21 and client secrets to authenticate our non interactive applications because that keeps things
2:26 simple. And another consideration is how scopes or API permissions are passed into the token
2:34 with delegated permissions I where the application gets an access token for the user. The API permissions are passed as scopes in the token claims.
2:43 Depending on the identity provider, the scope claim can appear as SCP or scope and
2:50 the value of the claim is a space delimited string that's part of the RFC. With the application permissions on the other hand,
2:57 the application requests an access token for itself and the API permissions are passed in the
3:03 token as role claims. They're all claims will be an array, like collisions. Access tokens are turns into the client code and need to be passed
3:12 directly to the API resource that we need to call. It's the resources responsibility to accurately pass and validate the token.
3:19 Next, we will create a console application using Python to call our fast API get some weather data back. Let's do this.