You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+7-2Lines changed: 7 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,9 +27,14 @@ A token represents the outcome of an authentication operation with some artifact
27
27
28
28
With Azure Active Directory taking the full responsibility of verifying user's raw credentials, the token receiver's responsibility shifts from verifying raw credentials to verifying that their caller did indeed go through your identity provider of choice and successfully authenticated. The identity provider represents successful authentication operations by issuing a token, hence the job now becomes to validate that token.
29
29
30
+
### What to validate
31
+
While you should always validate tokens issued to the resources (audience) that you are developineg, your application will also obtain access tokens for other resources from AAD. AAD will provide an access token in whatever token format that is appropriate to that resource.
32
+
This access token itself should be treated like an opaque blob by your application, as your app isn’t the access token’s intended audience and thus your app should not bother itself with looking into the contents of this access token.
33
+
Your app should just pass it in the call to the resource. It's the called resource's responsibility to validate this access token token.
34
+
30
35
### Validating the claims
31
36
32
-
When an application receives an ID token upon user sign-in, it should also perform a few checks against the claims in the ID token. These verifications include but are not limited to:
37
+
When an application receives an access token upon user sign-in, it should also perform a few checks against the claims in the access token. These verifications include but are not limited to:
33
38
34
39
-**audience** claim, to verify that the ID token was intended to be given to your application
35
40
-**not before** and "expiration time" claims, to verify that the ID token has not expired
@@ -95,7 +100,7 @@ of the Azure Active Directory window respectively as *Name* and *Directory ID*
95
100
#### Register the TodoListClient client app
96
101
97
102
1. Click on **App registrations** and choose **New application registration**.
98
-
1. Enter a friendly name for the application, for example 'TodoListClient-DotNet' and select 'Native' as the Application Type. For the redirect URI, enter `https://TodoListClient`. Please note that the Redirect URI will not be used in this sample, but it needs to be defined nonetheless. Click on **Create** to create the application.
103
+
1. Enter a friendly name for the application, for example 'TodoListClient-ManualJwt' and select 'Native' as the Application Type. For the redirect URI, enter `https://TodoListClient`. Please note that the Redirect URI will not be used in this sample, but it needs to be defined nonetheless. Click on **Create** to create the application.
99
104
1. In the succeeding page, Find the **Application ID** value and copy it to the clipboard.
100
105
1. Then click on **Settings** and choose **Properties**.
101
106
1. Configure Permissions for your application - in the Settings menu, choose the **Required permissions** section, click on **Add**, then **Select an API**, and type 'TodoListService' in the textbox and hit enter. Select 'TodoListService-ManualJwt' from the results and click the 'Select' button. Then, click on **Select Permissions** and select 'Access TodoListService-ManualJwt'. Click the 'Select' button again to close this screen. Click on **Done** to finish adding the permission.
CertificateValidator=X509CertificateValidator.None// Certificate validation does not make sense since AAD's metadata document is signed with a self-signed certificate.
0 commit comments