We have created a converged application for a public community(AD & live users can login) using Microsoft Graph and the scopes openid, email, profile and user.readBasic.all.
Every thing works fine for live users but some of AD users are not able to login. When they try to login they get the message as
"App needs permission to access resources in your organization that
only an admin can grant. Please ask an admin to grant permission to
this app before you can use it."
as per Microsoft document we have prepared admin consent url as
https://login.microsoftonline.com/<TenantID>/oauth2/authorize?client_id=<AppID>&response_type=code&redirect_uri=<RedirectURI>&prompt=admin_consent
After admin consent also users are not able to login to the app. Please help us what we are missing here.
Your URL is for the v1 Endpoint, not the v2 Endpoint (aka converged endpoint).
It should look like this (line break for readability):
https://login.microsoftonline.com/common/adminconsent?
client_id=[APPLICATION ID]&redirect_uri=[REDIRECT URI]
Note that is it /adminconsent rather than /authorize and there isn't a prompt query parameter. Also keep in mind that you'll need to ensure your registration includes the scopes you want the consent for.
I've written an article that walks you through the entire process that should prove helpful here: v2 Endpoint and Admin Consent
Related
I have a Azure Active Directory application and I have provided some of the user delegated permissions for accessing Graph APIs. For example 'user.read' and 'user.read.all' etc.
To provide User Consent for the Graph APIs which have Delegated permission. I need to login using my credentials to the test application (I developed) and then there will be a Popup displayed on the Web UI with title "Permissions requested" to grand the consent. I need to select Accept button to grand the consent.
My questions:
Is there a way we can preauthorize the user consent without following Web UI flow?
Just like the admin consent in Active Directory, is there a way to grant user consent?
Yes, it is possible through MS Graph API.
When you grant user consent, an OAuth2PermissionGrant object is created.
Admin consent also creates one but in that one the principal is set to be "all users".
You can also create these programmatically.
You can see the docs for the API endpoint here.
It is created under the service principal of your app and you specify consentType as "Principal" and principalId as the user's objectId.
I think you may try to hit this url and signed in with the admin account, then you may consent on behalf of your organization. This url is used to get auth code for using auth code flow(generate access token)
https://login.microsoftonline.com/hanxia.onmicrosoft.com/oauth2/v2.0/authorize?
client_id=your_azure_ad_app_clientid
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost:8080%2F
&response_mode=query
&scope=user.read
&state=12345
My AD tenant has user consent disabled, i.e., all permissions added to AD app registration need an admin consent.
For an application using static permissions/scopes (v1.0 OAuth/OpenId endpoint), is it possible to add new permissions such that until the admin consent is granted, users can continue using features which require only the existing consented scopes?
Microsoft docs say: "The app needs to know all of the resources it would ever access ahead of time. It was difficult to create apps that could access an arbitrary number of resources." Does it mean that for my scenario, all users need to wait for admin consent before they can access the app?
I receive the below error when a user tries logging in to the app using the Open ID Connect flow. For reference, my login URL is similar to https://login.microsoftonline.com/{tenant}/oauth2/authorize?response_type=id_token&client_id=b8ad6a99-cd23-40a6-a1b4-1184af990aa2&redirect_uri=https%3A%2F%2Flocalhost%2F&state=13ccfb84-cfd1-4cb0-bfe3-bb2c227e19f7&client-request-id=4d76947a-0000-48af-aeff-7bc2d5e40000&x-client-SKU=Js&x-client-Ver=1.0.17&nonce=ef1caa16-d3fe-4523-a9c9-000000000000
is it possible to add new permissions such that until the admin consent is granted, users can continue using features which require only the existing consented scopes?
Yes, you can.
When the admin consent the API permission of an AD App(App registration), the permissions essentially will be given to the service principal(Enterprise application) in your AAD tenant. Actually if you use the AD App in your tenant, the permissions are essentially from the service principal.
You could refer to the screenshot below, there are four permissions, the two permission has been granted.
Navigate to the Overview, click the option Manage application in local directory.
Then in the Permissions, you will find the two permissions which have been consent.
When you add the new scopes, the app will keep working, but it will only be able to access the old scopes until the admin consents to the new scopes.
Thanks!
Alex Simons
When registering a native application on the Azure AD 1.0 endpoint, and assigning Graph API permissions, it seems like consented permissions are 'cached' somewhere and can't be managed properly.
Example scenario:
Application registered and permission scopes (incl. ones requiring admin consent) assigned.
Administrator consents to the permission scopes
Simple user can use the app with consented permissions.
Permission scopes change (adding a new one for example)
Same admin doesn't get the consent form anymore
Simple user is stuck with "consent required, have an admin account?"
Another global admin must use the app for the first time to trigger the consent page.
Note that #7 doesn't always work; even if the other admin provides consent, simple users can't get through sometimes.
This is a multi-tenant application, yet when start using it in another tenant, I can not see its consented permissions in the AAD portal under enterprise applications.
Shouldn't permissions that have been consented to be listed in other tenants so that the admin can at least see what has been consented to?
Also, when I register an app on the V1.0 endpoint in my own tenant, I have an option to 'grant permissions' centrally, from the Azure AD portal for my tenant.
This option isn't available if I'm looking at an application that was registered in another tenant.
Am I overlooking something? Any help much appreciated.
When you change permissions, it does not automatically re-consent (for user or admin). You can find a detailed overview of this at Understanding user and admin consent.
You'll first need kick off the Admin Consent workflow. For a multi-tenant app this is done by adding prompt=admin_consent to your OAUTH URL and having an Admin authenticate.
Once that is done you can also force existing users to re-consent as well by adding prompt=consent to your Auth URL.
We have a webapplication that uses openid connect, with azure as the identityprovider, to sign in users. So users, when signing in is sent to a URL like:
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?response_type=id_token+token&client_id=3{clientId}&response_mode=form_post&redirect_uri=http://localhost:8765/ms/oidc/signon/response&scope=openid+profile+https://graph.microsoft.com/user.read&state=1234&nonce={nonce}
this works fine, but requires users to consent to our apps permission scopes the first time they use it.
We'd like to offer office365 administrators the ability to consent on behalf of their entire tenant, so we send them to an endpoint like:
https://login.microsoftonline.com/common/adminconsent?client_id={clientId}&state=12345&redirect_uri=http://localhost:8765
this also seems to work fine, and the admin i informed that they will consent on behalf of all users in their tenant. However, the user is still presented with the consent prompt on first login.
This does make sense, since the app is only registered with the user.read permission, so if we instead sent the user to
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?response_type=token&client_id={clientId}&response_mode=form_post&redirect_uri=http://localhost:8765/ms/oidc/signon/response&scope=https://graph.microsoft.com/user.read&state={state}&nonce={nonce}
without the dynamic permission request, and response type only set to token, the admin consent works, and users are not presented with the consent prompt.
So, I guess I have 2 questions:
1) is this how it's supposed to work, or is there some way to grant admin consent to the profile and openid scopes?
2) Am I actually missing anything by not requesting these(openid+profile) permissions? I don't receive and id_token in the response, but is seems the authentication_token already contains even more information than the id_token does anyway
1) is this how it's supposed to work, or is there some way to grant admin consent to the profile and openid scopes?
It seems a bug in azure ad v2.0 consent framework , well-known scopes(openid,profile) should be granted by default when you do admin permissions. Please refer to this link .
2) Am I actually missing anything by not requesting these(openid+profile) permissions? I don't receive and id_token in the response, but is seems the authentication_token already contains even more information than the id_token does anyway
You don't use OpenID connect since you haven't added the openid scope ,so id_token is not returned . But since you have the user.read permission of microsoft graph api , you could use microsoft graph api to read the user's basic information . Id_token and access token are different ,the id_token is used to identify the authenticated user. The access_token is used to prove access rights to protected resources . Please click here for more details.
I am building a SaaS app that will be authenticating users using Azure AD.
Let's say I am asking for just 1 delegated permission from user during consent prompt and user accepts it.
Later on my app evolves and need to get more delegated permissions. In that case how do I re-prompt the user with the consent page? I would like do this only once when the permissions are changing.
Do I need to track in my app what permissions each user has consented to and then determine to add the prompt=admin_consent query parameter while redirecting to the auth page?
The prompt=admin_consent is used when an administrator needs to provide consent for their organization. If you just require the users’s consent, you use prompt=consent.
Another way is that you can redirect to the login page to add the prompt parameter to re-consent when the app get the exception because the lack of permission to call the new API.
You could also consider use the V2.0 endpoint which support the incremental and dynamic consent.
Here is the document about Azure AD V2.0 endpoint for your reference.