App Roles are not delivered in access token - azure-active-directory

In an Azure Active Directory, I register an App and define application roles in the manifest as follows:
"appRoles": [
{
"allowedMemberTypes": [
"User"
],
"description": "Normal user access",
"displayName": "User",
"id": "a046aca0-a7c4-4c33-8377-e43c4d7bd89f",
"isEnabled": true,
"value": "User"
},
{
"allowedMemberTypes": [
"User"
],
"description": "Full admin access",
"displayName": "Admin",
"id": "0204f02c-d752-48b5-8b8f-2f8ccb7f83d7",
"isEnabled": true,
"value": "Admin"
}
],
"oauth2AllowIdTokenImplicitFlow": true,
"oauth2AllowImplicitFlow": true,
Whenever a user receives an access token, the roles are also included. Everything works fine.
Now we have created another Azure Active Directory. I registered an app and define app roles, exactly with same procedure as before. However the roles are not included in the access token. Could someone please help me to cope with this problem?

First please check if you have assigned the user to roles, you can refer to this tutorial.
Second, I'm not sure if you mean access token or id token. As far as I know, the role will not show in access token. It will just show in id token. You can use flow like authorization code grant or openID connect to sign a user in. The response will have a id_token.
Here is another post which is similar to this problem for your reference.
By the way, if we use "client_credentials" as grant type, we can see the permission roles(in appliction permissions) which added in API permissions(the access token contains a roles property). But if we use "password" grant type, the access token will not have this roles property. So please pay attention to the grant type which you used.
Hope it helps.

Related

API Permissions - Microsoft Graph API

I'm using Microsoft Graph API to create an application making an HTTP request using the following documentation:
https://learn.microsoft.com/en-us/graph/api/application-post-applications?view=graph-rest-1.0&tabs=http
Example:
POST https://graph.microsoft.com/v1.0/applications
Content-type: application/json
{
"displayName": "MyAppName",
"signInAudience": "AzureADMultipleOrgs"
}
But I need to add some API permissions (Microsoft Graph Application permissions) when creating the applications so I can do other operations like getting the Azure AD groups, modify them, create users, etc. Is there a way to add and grant the permissions programmatically as well without doing it through the portal?
Thank you.
Microsoft Graph object ID
The first thing you'll need is the object ID of Microsoft Graph service principal in your tenant.
00000003-0000-0000-c000-000000000000 is the globally unique application ID for Microsoft Graph, which we can use to get the object ID by making a request like below.
GET https://graph.microsoft.com/v1.0/servicePrincipals?$filter=appid eq '00000003-0000-0000-c000-000000000000'&$select=id,appid,appDisplayName
Example response
The object ID we need is the id in the response
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#servicePrincipals(id,appId,appDisplayName)",
"value": [
{
"id": "bd0a624d-11f8-44ab-a015-d8f276d75ad3",
"appId": "00000003-0000-0000-c000-000000000000",
"appDisplayName": "Microsoft Graph"
}
]
}
References
Application IDs for commonly used Microsoft applications
Adding API Permissions
You can add the API permissions, which is separate from granting admin consent.
PATCH https://graph.microsoft.com/v1.0/applications/{application_id}
Headers
Key
Value
Authorization
Bearer {access token}
Content-Type
application/json
Body
Key
Value
resourceAppId
The API resource to add permissions from, in this case 00000003-0000-0000-c000-000000000000 is for Microsoft Graph
resourceAccess
Array of permissions containing the ID and type
id
Use the globally unique ID of the permission want to add, which you can reference from All permissions and IDs
type
For delegated permissions, use Scope. For application permissions, use Role
Example body
The below permissions are for User.Read (delegated), openid (delegated), and Directory.Read.All (application)
{
"requiredResourceAccess": [
{
"resourceAppId": "00000003-0000-0000-c000-000000000000",
"resourceAccess": [
{
"id": "e1fe6dd8-ba31-4d61-89e7-88639da4683d",
"type": "Scope"
},
{
"id": "37f7f235-527c-4136-accd-4a02d197296e",
"type": "Scope"
},
{
"id": "7ab1d382-f21e-4acd-a863-ba3e13f7da61",
"type": "Role"
}
]
}
]
}
References
Update application API endpoint
requiredResourceAccess resource type
resourceAccess resource type
Granting admin consent
Important to note that you can only grant admin consent with the API for delegated permissions. For application permissions, you'll need to use the Portal and click the button.
POST https://graph.microsoft.com/v1.0/oauth2PermissionGrants
Headers
Key
Value
Authorization
Bearer {access token}
Body
Key
Value
clientId
The Enterprise Application object ID for which you want to grant consent to
consentType
Indicates if authorization is granted for the client application to impersonate all users or only a specific user. AllPrincipals indicates authorization to impersonate all users. Principal indicates authorization to impersonate a specific user. Consent on behalf of all users can be granted by an administrator. Non-admin users may be authorized to consent on behalf of themselves in some cases, for some delegated permissions. Required. Supports $filter (eq only).
resourceId
Use the object ID we obtained earlier for the Microsoft Graph service principal
scope
A space-separated list of the claim values for delegated permissions which you want to grant admin consent to
Example body
{
"clientId": "7f244605-717f-408f-96fb-d369678cea56",
"consentType": "AllPrincipals",
"resourceId": "bd0a624d-11f8-44ab-a015-d8f276d75ad3",
"scope": "openid User.Read"
}
References
Create oAuth2PermissionGrant API endpoint
oAuth2PermissionGrant resource type
Unless you’re creating more then 10 applications, I would just go through the portal.
Creating secrets through the api is not very easy.
The portal has wizards and explanations for most options
Granting permissions and creating applications can be done at the same time, you can also create the application and then have an admin do the admin consent.
Admin consent explained: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow#request-the-permissions-from-a-directory-admin

AD provisioning says that "A required attribute is missing from a response", but it does exist in the response

I'm working on implementing SCIM 2.0, as I need to use to to provision users in my system that are stored in Azure AD. I have set it up and when I try to manually provision a user, I get this error:
The user is successfully provisioned on the client side, as you might guess from the error message - it's not an issue with the request.
I am guessing that the issue is with where the identifier is located, since the Identifier attribute is included in the response that is in the error message.
I've googled this error and I can find general tutorials for AD SCIM implementations, but I haven't been able to find anything about this specific error.
Here's a pretty-printed version of the response:
{
"totalResults": 1,
"startIndex": 0,
"itemsPerPage": 1,
"schemas": [
"urn:ietf:params:scim:api:messages:2.0:ListResponse"
],
"Resources": [
{
"emails": [
{
"type": "work",
"value": "perrin#***.com",
"primary": true
}
],
"Identifier": "1072",
"meta": {
"meta": "/scim/v2/Users/1072",
"resourceType": "User"
},
"schemas": [
"urn:ietf:params:scim:schemas:core:2.0:User"
],
"name": {
"familyName": "Aybara",
"givenName": "Perrin"
},
"active": true,
"id": "1072",
"userName": "perrin#***.com"
}
]
}
• As you are provisioning a user manually through SCIM functionality of Azure AD, the issuer identity, i.e., Azure AD is identified by an iss claim in the token received after successfully provisioning the user from Azure AD. Example of it is as below: -
"iss":https://sts.windows.net/cbb1a5ac-f33b-45fa-9bf5-f37db0fed422/
where ‘https://sts.windows.net’ is the URL of the issuer, i.e., Azure AD and the ‘cbb1a5ac-f33b-45fa-9bf5-f37db0fed422’ is the unique identifier of the Azure AD tenant for which it was issued. This token was issued for the application template ID of the app configured for provisioning in enterprise applications.
• Also, please note that the query to provision an Azure AD user with the ‘create’ action in the client app web service with an ‘externalId’ attribute value that matches the ‘mailNickname’ attribute value of a user doesn't return any users in your case as shown in the image, then AAD requests that the web service provision a user corresponding to the one in AAD. The user provisioned from Azure AD is assigned an identifier value when the provisioning succeeds and returns an instance of the Microsoft.SCIM.Core2EnterpriseUser class with identifier attribute indicating the user provisioned. Thus, since the user identifier value is missing as shown in the image, please run the below command to query whether the user is created successfully or not.
‘ GET ~/scim/Users/54D382A4-2050-4C03-94D1-E769F1D15682 HTTP/1.1
Authorization: Bearer ... ’
In a request to retrieve the current state of the user provisioned, the values of the properties of the object provided as the value of the parameters argument are as follows:
Identifier: "54D382A4-2050-4C03-94D1-E769F1D15682"
SchemaIdentifier: "urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"
• Request you to try again to provision the user and query to request the current state of the user regarding its reference attribute. Also, send a request from Azure AD to the SCIM service to update the user in its datastore. Here is an example of the request sent from Azure AD to the SCIM service: -
‘ PATCH ~/scim/Users/54D382A4-2050-4C03-94D1-E769F1D15682 HTTP/1.1
Authorization: Bearer ...
Content-type: application/scim+json
{
"schemas":
[
"urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations":
[
{
"op":"Add",
"path":"manager",
"value":
[
{
"$ref":"http://.../scim/Users/2819c223-7f76-453a-919d-413861904646",
"value":"2819c223-7f76-453a-919d-413861904646"}]}]} ‘
Please find the detailed steps in the link as below: -
https://learn.microsoft.com/en-us/azure/active-directory/app-provisioning/use-scim-to-provision-users-and-groups#handling-provisioning-and-deprovisioning-of-users
This error generally shows up when there is something invalid with the format of the JSON payload. From looking at this one, I suspect it's your inclusion of "Identifier" as this is not defined in the core SCIM schema docs, and specifically may be causing issues if it overlaps with something else in the provisioning service. "id" is the correct attribute to use.
After playing around with it the issue was not that the resources were missing anything - it was the ListResponse itself that needed an ID. If I include
"id": "urn:ietf:params:scim:api:messages:2.0:ListResponse"
to the top-level object (along with totalResults, etc.) it is processed as expected.

What's the difference between User.Read vs OpenID/Profile/Email Permissions in AzureAD App Registration for an app that will sign in users?

When creating multi-tenant apps that will use Azure AD Authentication to sign users in, various samples on GitHub seem to suggest that the App Registration should include the following permissions clubbed under OpenId.
email View users' email address
offline_access Maintain access to data you have given it access to
openid Sign users in
profile View users' basic profile
(See for example: https://github.com/OfficeDev/microsoft-teams-sample-auth-node Section 12)
While following the samples on the Azure portal itself, the quickstarts create an App registration with just this one permission
User.Read Sign in and read user profile
Is Microsoft's Azure AD User.Read permission a superset of the generic openid's email, openid and profile permissions?
When creating a consent URL in the https://login.microsoftonline.com/common/adminconsent?client_id={client-id} form, only the User.Read seems to appear.
What is the recommended set of permissions that are recommended for a basic app that needs to sign users in?
I just spent quite a while testing this as part of my own learning today, and here's what I found.
tl;dr
The openid scope will get you an id_token, and an access_token that allows you to call the UserInfo endpoint (https://graph.microsoft.com/oidc/userinfo). If you want to call any of the Graph APIs, (other than UserInfo) then you'll want (at least) the User.Read scope.
The Details
I have a test AzureAD tenant in which I created a brand-new client app registration (with a SPA endpoint) and a brand-new user, thus ensuring there was no residual 'consent' anywhere.
I then used the browser to sign-in with a hand-crafted URL to request only the openid scope. With line breaks added and some chars redacted this was:
https://login.microsoftonline.com/a8257b21-...6263/oauth2/v2.0/authorize?
client_id=b3f87624-...e5b&
response_type=code&
redirect_uri=https://localhost&
response_mode=query&
scope=openid&
state=12345&
code_challenge=LrTIpxRwK...
code_challenge_method=S256&
prompt=login
For this I got the below consent prompt:
It's interesting to note that it asked to "View your basic profile" and "Maintain access to data..." when I didn't ask for profile or offline_access scopes.
I extracted the authorization code from the response and sent it to the https://login.microsoftonline.com/{{tenant_id}}/oauth2/v2.0/token endpoint with the necessary fields.
The id_token I got back didn't include claims the profile scope would imply, showing only the below
{
"aud": "b3f87624-...2fb5367e5b",
"iss": "https://login.microsoftonline.com/a8257b21...263/v2.0",
"iat": 1642367777,
"nbf": 1642367777,
"exp": 1642371677,
"rh": "0.AUYAIXs...L7U2fluAAB0.",
"sub": "tcK...WXUvzWqAc",
"tid": "a82...6263",
"uti": "SjLRuw...jlhAA",
"ver": "2.0"
}
However interestingly the access_token it returned is for the Graph audience (00000003-0000-0000-c000-000000000000) did list the scopes as including profile and email, and did include claims related to those, e.g. (with some omitted for clarity)
{
"aud": "00000003-0000-0000-c000-000000000000",
"iss": "https://sts.windows.net/a82...6263/",
"app_displayname": "TestApp",
"appid": "b3f87...67e5b",
"family_name": "Bull",
"given_name": "Pit",
"idtyp": "user",
"ipaddr": "67.183.2.129",
"name": "Pit Bull",
"oid": "08a5...673de",
"scp": "openid profile email",
"sub": "6JrD7...phCH7Y",
"tid": "a825...36263",
"unique_name": "pit#example.dev",
"upn": "pit#example.dev",
"ver": "1.0"
}
(Note: Obviously you shouldn't look in tokens that aren't for your audience, but it's all there in clear text, so?)
I did also get a refresh token back, which I saved for later.
With that access token I could call the UserInfo endpoint and also see the *name claims, which would indicate profile scope (I forget to set the email on my test user, else I'm guessing that would have shown too).
From https://graph.microsoft.com/oidc/userinfo
{
"sub": "tcK6D...UvzWqAc",
"name": "Pit Bull",
"family_name": "Bull",
"given_name": "Pit",
"picture": "https://graph.microsoft.com/v1.0/me/photo/$value"
}
However, with that same access token, if I tried to call any Graph APIs such as https://graph.microsoft.com/v1.0/me or https://graph.microsoft.com/v1.0/organization I was met with the following response.
{
"error": {
"code": "Authorization_RequestDenied",
"message": "Insufficient privileges to complete the operation.",
"innerError": {
"date": "2022-01-16T21:52:18",
"request-id": "e4f58...1611",
"client-request-id": "e4f5...a1611"
}
}
}
By running through the same flow again but this time with the scopes openid profile email, the only difference I could ascertain was that the id_token now included the below claims (and again, probably would have had the email address if I'd configured it on the account)
"name": "Pit Bull",
"oid": "08a5...73de",
"preferred_username": "pit#example.dev",
The access token looked the same, and the UserInfo result was the same (which makes sense if the access_token to auth to it looked the same). I'd also note I didn't get prompted for any additional consent, which would imply profile and email were implicitly added to my initial openid-only scope request.
At this point I took a break to feed the kids, and when I came back a couple hours later decided to try out the refresh token I received (without requesting offline_access scope). It worked fine and I got refreshed tokens, so this seems to be implicitly added also when just requesting openid.
For my next test I sent the same hand-crafted request to authenticate but included the User.Read scope. As expected, I got prompted for the additional consent:
It's interesting to note how it mentions "..and read basic company information". This aligns with the docs at https://learn.microsoft.com/en-us/graph/permissions-reference which state of User.Read: "With the User.Read permission, an app can also read the basic company information of the signed-in user for a work or school account through the organization resource.".
All the tokens I got back from this looked similar to before, but obviously with the addition of the User.Read scp in the access token. Now making requests to certain Graph APIs was met with success. For example:
https://graph.microsoft.com/v1.0/me or https://graph.microsoft.com/v1.0/users/pit#example.dev
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#users/$entity",
"businessPhones": [],
"displayName": "Pit Bull",
"givenName": "Pit",
"jobTitle": null,
"mail": null,
"mobilePhone": null,
"officeLocation": null,
"preferredLanguage": null,
"surname": "Bull",
"userPrincipalName": "pit#example.dev",
"id": "08a53...b673de"
}
https://graph.microsoft.com/v1.0/me/directReports (I didn't have any direct reports configured, but it was a successful query rather than access denied)
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#directoryObjects",
"value": []
}
And https://graph.microsoft.com/v1.0/organization (trimmed for readability - and again, I'd not set up org details for this account, hence the nulls)
{
"#odata.context": "https://graph.microsoft.com/v1.0/$metadata#organization",
"value": [
{
"id": "a8257...736263",
"businessPhones": [],
"city": null,
"country": null,
"postalCode": null,
"preferredLanguage": null,
"state": null,
"tenantType": "AAD",
"directorySizeQuota": {
"used": 39,
"total": 300000
},
"verifiedDomains": [
{
"capabilities": "Email, OfficeCommunicationsOnline",
"isDefault": false,
"isInitial": true,
"name": "example.onmicrosoft.com",
"type": "Managed"
},
{
"capabilities": "None",
"isDefault": true,
"isInitial": false,
"name": "example.dev",
"type": "Managed"
}
]
}
]
}
So there you have it. Add User.Read if you want to query anything from the Graph APIs, else just use openid (and optionally profile email) if you are happy just signing users in and using the id_token for your needs.
As a footnote to this I'd also recommend reading the couple paragraphs at https://learn.microsoft.com/en-us/graph/permissions-reference#remarks-15 . I was only testing with a v2 endpoint, but it does look like User.Read used to be required just to sign-in with the v1 endpoint, so it being included by default may be a residual effect of that. As it states of the V1 endpoint: "To successfully return an ID token, you must also make sure that the User.Read permission is configured when you register your app."
Hence the question if user.read subsumes open_id, email and profile
perms?
No, user.read does not contain them, they are independent permissions.
I have set these required perms but in the consent popup shown to the
Azure AD admin, email and profile and openid permissions do not show
up; only offlne_access and user.read shows.
email offline_access openid profile is usually the permissions of the OIDC protocol. There are some differences between oauth2.0 and openid connect. If you only need to log in as a user, you only need to use openid connect, and it will only return you the id token of the logged in user. Regarding why the email openid profile is not displayed on the admin consent page, I think this is a problem that is still being fixed, but I don’t think you need to worry about these because these permissions themselves are permissions that do not require the administrator’s consent. When you add them in API permissions, you can use them directly.
At this time, the offline_access ("Maintain access to data you have given it access to") and user.read ("Sign you in and read your profile") permissions are automatically included in the initial consent to an application. These permissions are generally required for proper app functionality - offline_access gives the app access to refresh tokens, critical for native and web apps, while user.read gives access to the sub claim, allowing the client or app to correctly identify the user over time and access rudimentary user information. please refer to this document

Outlook Add-In SSO access token missing email claim

I am creating an outlook add-in and am trying to use the SSO access token as authorisation for my backend.
I have the flow working. I trigger my Add-In, get the access token and use the access token to "login" to my backend.
However, the issue I have is that I am not getting the email claim in the token despite a) adding it to the API permissions in the Azure App Registration, b) adding to the WebApplicationInfo. Should I be receiving it?
Azure App Registration Permissions
Web Application Info
<WebApplicationInfo>
<Id>xxx</Id>
<Resource>api://localhost:3000/xxx</Resource>
<Scopes>
<Scope>openid</Scope>
<Scope>User.Read</Scope>
<Scope>profile</Scope>
<Scope>email</Scope>
</Scopes>
</WebApplicationInfo>
Code to receive token
OfficeRuntime.auth.getAccessToken( { allowSignInPrompt: true })
Token received
{
"aud": "api://localhost:3000/xxx",
"iss": "https://sts.windows.net/my_tenant_id/",
"iat": 1605992211,
"nbf": 1605992211,
"exp": 1605999711,
"acr": "1",
"aio": "E2RgYDDdzii4P/xP/cPTbg4lPk7dJ6c8aQnapLU19aiV+Zy400sA",
"amr": [
"pwd"
],
"appid": "xxx",
"appidacr": "0",
"family_name": "Adams",
"given_name": "Iain",
"ipaddr": "51.111.111.111",
"name": "Iain Adams",
"oid": "my_oid",
"pwd_exp": "157262",
"pwd_url": "https://portal.microsoftonline.com/ChangePassword.aspx",
"rh": "0.AAAAmj9NLsNP80SAITLYeWEJg9YOWdOzUgJBrv-q0ikqsBxHANs.",
"scp": "access_as_user",
"sub": "my_sub",
"tid": "my_tenant",
"unique_name": "iain#abc.com",
"upn": "iain#abc.com",
"uti": "1KNbNttkDUCrKXblaK5BAA",
"ver": "1.0"
}
Whilst I know the email address is being returned in the upn and unique_name claims, AND, I know that oid should be used as the unique identifier for this user, however, I need to lookup based on email address (if it exists).
You need to customize the access token configuration and then add the email as an optional claim. Go to azure portal>App registrations>your app>Token configuration.
Parse the token:
You need to pay attention to: For managed users (the users inside the tenant), it must be requested through this optional claim or, on v2.0 only, with the OpenID scope.
See: Document.
The "Email" value is part of optional claims. It's included by default if the user is a guest in the tenant. For managed users (it means, the users inside the tenant), it must be requested through this optional claim or, on v2.0 only, with the OpenID scope. For managed users, the email address must be set in the Office admin portal (https://portal.office.com/adminportal/home#/users).

Role/Group based Authorization using ADAL.js and ASP.NET Web API

What we are planning to achieve is a role-based security for a Front end Angular-2 and back-end ASP.NET Web API application. We are doing the authentication process with the help of ADAL.js and storing the token in the local storage. We have also implemented the approach shown here i.e. to call the Graphi API and get the user groups to stuff them into Claims.
My question is : Is there anyway, we can add role claims from server to the bearerToken which is residing in the local storage. Or is there any better way to approach this issue.
The code sample mentioned assign the role based on the group. If you have the Azure AD basic version, it support to assign the role to the users/groups directly.
My question is : Is there anyway, we can add role claims from server to the bearerToken which is residing in the local storage. Or is there any better way to approach this issue.
Yes, it is possible. To issue the role claims we need to assign the users to assign the roles to users or group first. Then when the user acquire the token, the Azure AD would issue the relative role claims in the token.
You can refer the code sample for using the role claim from here.
And you may also be interest in groups claim developing.
ok i was struggling with this for a while and i have figured it out i believe.
First,
In Azure AD, set up your WebApi app as application type to be Web App / API.
go to Manifest file and add your roles like
[
{
"allowedMemberTypes": [
"User"
],
"displayName": "Reviewer",
"id": "0238c2bb-9857-4d07-b760-a47ec621d57a",
"isEnabled": true,
"description": "Reviewer only have the ability to view tasks and their statuses.",
"value": "reviewer"
},
{
"allowedMemberTypes": [
"User"
],
"displayName": "Approver",
"id": "000018cb-19e3-4f89-bf99-5d7acf30773b",
"isEnabled": true,
"description": "Approvers have the ability to change the status of tasks.",
"value": "approver"
}
]
Then create the the Client app as Application type to be Native app and add required permissions to the service you added above.
In the SPA Angular app add something like this
var endPoints = {
// "https://localhost:44386/" is the API URL
// "xxxxxxxxxxxxxxxxxxxxxxxxxxxxx" is the Service Application ID
"https://localhost:44386/": "xxxxxxxxxxxxxxxxxxxxxxxxxx"
};
adalAuthenticationServiceProvider.init({
instance: "https://login.microsoftonline.com/",
// tenant is your tenant name (something like below)
tenant: "{NAME}.onmicrosoft.com",
// this is the Native app application ID (ClientID) you registered
clientId: "yyyyyyyyyyyyyyyyyyyyyyyyyyyyyy",
extraQueryParameter: "nux=1",
endpoints: endPoints
}, $httpProvider);
}
]);
Then, in your startup.cs you need to set up the Service App like the following:
app.UseWindowsAzureActiveDirectoryBearerAuthentication(
new WindowsAzureActiveDirectoryBearerAuthenticationOptions
{
TokenValidationParameters = new TokenValidationParameters
{
/* "xxxxxxxxxxxxxxxxxxxxxxxxxxxxx" is the Service Application ID. (Same as you registered in the client app above)*/
ValidAudience = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
RoleClaimType = "roles"
},
/*enant is your tenant name (same as you registered in client app above)*/
Tenant = "{NAME}.onmicrosoft.com"
});
Finally you need to go to Azure active directory => Enterprise application => all applications => select your webAPI service => Users and groups => then assign users to the roles.
When this is all done when you log through your client app to authenticate and call the webapi, adal.js and ada-angular.js will put the proper bearer token that contains roles
Good to learn this approach.
Ted, thanks for sharing your solution !
For those who are not familiar with operating Azure AD manifest file. The following is a good resource.
https://thinkthencode.wordpress.com/2016/04/24/azure-ad-using-app-roles-for-authorization/
"appRoles": [
{
"allowedMemberTypes": [
"User"
],
"displayName": "Reviewer",
"id": "0238c2bb-9857-4d07-b760-a47ec621d57a",
"isEnabled": true,
"description": "Reviewer only have the ability to view tasks and their statuses.",
"value": "reviewer"
},
{
"allowedMemberTypes": [
"User"
],
"displayName": "Approver",
"id": "000018cb-19e3-4f89-bf99-5d7acf30773b",
"isEnabled": true,
"description": "Approvers have the ability to change the status of tasks.",
"value": "approver"
}
]

Resources