Dynamics 365 API using AAD v2 - azure-active-directory

I am trying to access the Dynamics 365 Online API via a SPA. But I want to use the v2 authorization endpoint. I register my app in AAD and assign permissions for Dynamics CRM (I'm using the preview registration blade which allows me to specify Dynamics). It does not say that Admin consent is required for Dynamics but when I specify the scope in my SPA, I get an error at the consent screen indicating that I need admin consent.
I have successfully used the v1 authorization endpoint in the past so I suspect it is an issue with how I am specifying the scope when I retrieve my access token.
Is there something special needed for this API? Is it not fully implemented yet?
In my scope parameter when I request my access_token, I have tried:
<service guid>/<scope guid>
<service guid>/user_impersonation
https://<tenant>.crm.dynamics.com/user_impersonation
https://crm.dynamics.com/user_impersonation
https://dynamics.com/user_impersonation
The last four indicate admin consent is required. I've tried a few other formats but they error out indicating the format is incorrect or the resource doesn't exist - which I get. But I am confused about the admin consent pieces.
Any guidance appreciated!

You need to use a scope of:
https://{organization}.crm.dynamics.com//user_impersonation.
Note the double slash.

Not sure if this helps anyone, but I stumbled onto this thread looking for answers to the correct scope to use to access the Dynamics 365 rest api using MSAL in a client application.
I didn't need user_impersonation as I just wanted to access it as the application user. The scope that worked for me is:
"https://{organization}.api.crm3.dynamics.com//.default"
Source: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#client-credentials-grant-flow-and-default

Related

azp Claim Missing from Azure AD JWT

I have registered an app with Azure AD and can get JWT's but I am receiving claims associated to V1 JWT's according to this whilst I am expecting claims associated to V2 JWT's.
More specifically, I would like to add the azp claim which is only available under V2.
I've followed these instructions to add azp but it is not available to add as an optional claim. I am under the impression that I'm using a version 2 app since the endpoints end with /V2 and I also have the ability to add the ipaddr which is only available for V2 apps as far as I understand.
Can anyone point me to what I am missing?
The version of the access token has nothing to do with the endpoint you use to request the token, but is related to the resource you requested. The default version of ms graph api is the token of version 1.0. If you want to obtain the 2.0 version of the token, you should request your custom api.
First, you need to create an application that represents the api, and then expose the api protected by Azure.
Next,under 'API permissions', give your front-end application access to your backend api:
Under 'API permissions' click on 'Add permission', then click on the
'My APIs' tab.
Find your backend application and select the appropriate scope.
Click 'Add permissions'.
Grant admin consent for your APIs.
Next, go to the manifest of the front-end application and set the accessTokenAcceptedVersion attribute to: 2.
Next, you need to use the auth code flow to obtain an access token,which requires you to log in to the user and obtain the authorization code, and then use the authorization code to redeem the access token.
Parse the token, it will display azp claim and v2.0 version.

Permissions for listing virtual machines with Graph API

I am trying to use the request:
GET https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Compute/virtualMachines/{vmName}?api-version=2020-12-01
From microsoft graph API:https://learn.microsoft.com/en-us/rest/api/compute/virtualmachines/get#code-try-0.
I created an app registration within the an AD subscription. When I try to use the oauth2 credentials associated with the app registration I receive a 401. I believe this is due to a permissions error. I tried using https://developer.microsoft.com/en-us/graph/graph-explorer, but I am unable to assume the app registration to simulate the request. Any insight as to why this might be happening or how to debug the issue would be very helpful
Unlike the accepted answer, I had to set the scope to access this url...
https://management.azure.com/subscriptions/{SubscriptionID}/providers/Microsoft.Compute/virtualMachines?api-version=2020-12-01
to:
https://management.azure.com/.default
Your error is not a lack of permissions but the use of the wrong scope.
The error is actually very simple, you need to grant Azure Service Management api permissions instead of MS graph permissions, and then you need to set the scope to: https://management.azure.com/user_impersonation.
Next, use the auth code flow to obtain an access token.
Request an authorization code in the browser.
https://login.microsoftonline.com/{tenant id}/oauth2/v2.0/authorize?
client_id={client id}
&response_type=code
&redirect_uri={redirect_uri}
&response_mode=query
&scope=https://management.azure.com/user_impersonation
&state=12345
Redeem token.
Call api:
Please note that do not use graph-explorer test, because you are not calling MS graph api, you can use postman.

Multitenant API - Admin consent ERROR https://login.microsoftonline.com/organizations/v2.0/adminconsent AADSTS90009

Using the following endpoint acting as the Admin on the tenantB I want to register a multitenant API App defined in another tenantA:
https://login.microsoftonline.com/{tenantB}/v2.0/adminconsent?
client_id={GUIDAppIDInTenantA}
&redirect_uri=http://localhost:8080/myredirecturi
&scope=api://{GUIDAppIDInTenantA}/.default
I am getting this error:
AADSTS90009 Application is requesting a token for itself. This
scenario is supported only if resource is specified using the
GUID based App Identifier
I am using the GUID based App Identifier from TenantA. I get the login page and after signing in, I am immediately redirected to the redirect_uri with the error above.
The post
OAuth 2.0 and Azure Active Directory - error AADSTS90009 uses a different endpoint and mentions using the GUIDs that I am already using
Replace
&scope=api://{GUIDAppIDInTenantA}/.default
with
&scope={GUIDAppIDInTenantA}/.default
First add the ‘openid profile’ scope like this
https://login.microsoftonline.com/secondTenandID/v2.0/adminconsent?client_id={APP_IP}&redirect_uri={redirect_URI}&scope=openid+profile
This will register the APP (and trust the main Tenant)
Second, submit another request with the actual Multitenant API scope using this format
https://login.microsoftonline.com/secondTenandID/v2.0/adminconsent?client_id={APP_IP}&redirect_uri={redirect_URI}&scope={APP ID}/.default
this way the APP will be registered with the whole scope of permissions from the main tenant in the secondary tenant.
All you need is &scope=.default
https://login.microsoftonline.com/{ConsentingTid}/v2.0/adminconsent?client_id={WebOrSpaAppId}&redirect_uri={RedirectUri}&scope=.default
No need to spell out the app id twice.
If all you are doing is getting consent for you API, you will only need to consent once.
Also, in your MSAL2 client code:
interactionType: InteractionType.Redirect,
authRequest: {
scopes: [
'.default'
]
}

Microsoft Graph API - new delegated permission removing application permissions

I'm using the v1 Azure AD auth URLs (/common/oauth2/authorize) for a multi-tenant app that requires admin_consent.
I've attempted to add a new scope Directory.AccessAsUser.All. It is the first 'delegated' permission I'm requesting when all my other scopes are 'application' level permissions.
When I added that new delegated scope and prompted the admin to re-consent, the other scopes disappeared from the returned AccessToken and the responses scope parameter. Only Directory.AccessAsUser.All is present in the access_token scp field.
Is there any reason this behavior would occur? I'm positive that we are promoting for admin_consent and that an admin is the one consenting.
The scopes specified in the scp will depend on which OAUTH flow you used to obtain the token. You cannot have a single access_token with both Delegated and Application scopes.
Application scopes are applied when using the Client Credentials flow (client_credentials).
Delegated scopes are applied when using either Authorization Code or Implicit flows (authorization_code or implicit).
Update: I've written a more in-depth post about this topic that might help folks facing similar issues: Application vs Delegated Scopes.

Trying to access a v2 endpoint hosted webapi but no luck, true if only graph api works on v2 now?

Had a webapi running on v2 endpoint, the intent was to get access through a single call to both graph and the custom webapi, was using the v2 auth code grant flow, the url using as below,
https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id=14e9111f3e1-d220-415d-9bf4-d089f0b5feff&response_type=code&redirect_uri=https%3A%2F%2Flocalhost%3A8081%2Fartifactory%2Fwebapp%2Fsaml%2FloginResponse&response_mode=query&scope=api%3A%2F%2F14e9f3e1-d220-415d-9bf4-d089f0b5feff%2Faccess_as_user%20https%3A%2F%2Fgraph.windows.net%2Fuser.read%20openid%20offline_access&state=12345
with the scope as
api://14e9f3e1-d220-415d-9bf4-d089f0b5feff/access_as_user https://graph.windows.net/user.read openid offline_access
However, keep failing with a invalid scope error. If I take out the custom webapi from the resource, everything went through wonderfully.
Reading further, there is a limitation for webpi that
Web API can receive tokens only from an application that has the same Application ID. You cannot access a Web API from a client that has a different Application ID.
So I am confused, how to archieve the goal to use v2 endpoint to authenticate and get access to both graph and webapi????
--edit
the error message is 'AADSTS65005: The application 'blah' asked for scope 'user.read' that doesn't exist on the resource. Contact the app vendor.'
Today the v2 endpoint cannot issue an access token for a custom API. The feature is in active development, but there's no ETA to share.
Also note: even when the feature will be available, you will not be able to reuse the same access token across multiple resources; you'll be able to consent for multiple resources at once, so that your user is only promoted once, but you will need to request access tokens for each resources separately.

Resources