Secure APIs with FastAPI and the Microsoft Identity Platform Transcripts
Chapter: Web and headless clients
Lecture: Application types
Login or
purchase this course
to watch this video and the rest of the course contents.
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 FastAPI get some weather data back. Let's do this.