If in Azure portal, I set Enterprise applications > Properties > User assignment required? to No, then authentication works as expected. However, if I turned it on, users get error Application needs permission to access resources in your organization that only an admin can grant. I understand that I need to add an API permission to my app, but what is it?
Interestingly, if a user has signed in into the app before, then they are not affected when turning the option on. Only users who have never use it are affected
Edit: To clarify, I already have App roles created. Users without app roles can't sign in, as expected. Users WITH app roles who sign in for the first time after the the option turned to Yes get the above error
Finally, I reproduce your issue with the request URL below, the scope also could be another one, e.g. https://storage.azure.com/.default, which has been added in the API permissions of the AD App.
https://login.microsoftonline.com/<tenant0id>/oauth2/v2.0/authorize?
client_id=xxxxxxx
&response_type=code
&redirect_uri=http://localhost
&response_mode=query
&scope=https://management.azure.com/.default
&state=12345
If the User assignment required is set to Yes, I notice it will not promote the user to consent the permissions. (e.g. user_impersonation in the Azure Service Management API.)
To fix the issue, we need the admin consent to the App, just navigate to the API permissions, click the Grant the admin consent for xxx button, then it will work fine.
Related
I'm currently testing SWIA implementations, and found some interesting behavior related to scope in the authorization flow.
Situation that I'm facing right now is:
User signs in with his/her Apple Id through the mobile app's or website's SWIA feature for the vert first time without email scope.
User will be granted JWT without email claim as expected.
Later, we changed to add email scope for the authorization process.
User (from #1) signs in again, and goes through SWIA with email scope
User will be granted JWT without email claim
Unless otherwise user manually de-authorize the app from their Apple ID portal (or in the mobile app), updated scope will not be reflected
It also happens in the opposite way (i.e. having email scope for the very first request, and then later remove email scope. This will still grant JWT with email claim)
Is this something expected from Apple's OIDC server? or am I doing something wrong? I've tested it with both native iOS SWIA and on the web client as well, and both produce the same result.
Not quite sure if this is as per OIDC specification.
Any insight or help would be greatly appreciated.
I know its a late reply, Sign in with Apple does not provide incremental changes to the user scopes. If some user authorized with initial scope won't get until he revoke our application as described here https://support.apple.com/en-us/HT210426.That mean the newly added scope, only affects newly authorized users, and would include the email claim in their identity token (and in the initial user body of the authorization response).
Additionally the above steps don't show the option to revoke the app until at least one of the app login happens and the app should be in production not sandbox or testing.
apps not showing as there is no app requested for email/name
it will appear if login success from production app
we have a multi-tenant graph app and we are experiencing some unexpected behavior.
When a first user (non-admin and from another tenant) want to connect to the (enterprise) app, he logs in and gets the message 'Need admin approval'. This is normal, as the required permissions demand this.
Let's say the user knows the administrator login/pass, he clicks on 'Have an admin account, Sign in with that account', he logs in as administrator and approves the consent.
But then a code is generated for that administrator account and is posted back to my initial application(website). Resulting in the user having an access token for an administrator (which does not have SPO in our situation thus failing our application).
My very simple question: how can i just consent the app with an administrator account but without the flow posting back a code for that administrator to the redirect-url.
Is this possible?
Thank you
Ok, i think my problem is solved. Upon activating the app in our settings, we can direct the admin to following url:
https://login.microsoftonline.com/(tenantid)/v2.0/adminconsent?client_id=(clientid)&state=12345&redirect_uri=(redirecturl)&scope=(permissions)
We get redirected then like we receive a token, but having the state that also comes in the redirect url we might use it to display another message to the user.
I'm trying to implement IdentityServer4. We need to functionality to login as another user, when we're administrators.
I've already setup the login functionality for regular users, but I'd like a specific endpoint where an administrator can enter the username/id of a regular user.
How would one go about implementing this in IdentityServer4, as well as regular oauth2?
This is outside the scope of OIDC/OAuth2 interactions but there are some conventions for how to respresent such a scenario in the result token/claims. Have a read of https://www.rfc-editor.org/rfc/rfc8693 (in particular the act claim bits) for some inspiration.
We did this via the sign in UI flow but the model was that users could grant other users impersonation permissions explicitly. If when signing in you had valid impersonation grants then you'd be prompted as part of the sign in flow to choose a different account or continue as yourself. In your case you can identify admin users and give them the option to impersonate anyone you like.
If the user choses an impersonatee then it would change the current session to respresent that user but also store claims relating to the original user/session in the actor claim (act) and also add an amr claim of imp. We then made these claims available to clients so that they'd be aware of the fact impersonation was used and could then for example add that info to audit logs etc. We also notify the impersonated user via email and restrict access to account settings - i.e. impersonators can only sign into clients as other users, they cannot change their account settings.
I want my application to access my users OneDrive for Business files (both read and write access). It should work as an alternative browsing client, so the user just has to login and then browse his files.
With personal OneDrive using the v2 Endpoint, it works flawlessly.
When I try to login my OneDrive for Business account I get an error stating that my application requires some privileges that only Admins can grant.
But.. From the app panel ( https://apps.dev.microsoft.com ) my application requires only permission that non-admin users can request (under delegate authorization). The Application authorization list empty.
I also tried to remove ALL the permission required, save, wait some minutes and retry.. and even without any permission required i still get the same error.
I tried making new application, checking all the permission, refreshing the app's key.. but i always get the same error. If i try to login the same account from other commercial application it works.
I also don't have access to any admin account to see a list of authorization required by my app.
I'm really out of ideas, what i can try?
So I'm trying to connect an mvc app to AAD B2C, and retrieve the current users groups, so I can add them to their roles. Unfortunately, I am unable to successfully query the graph.
Insufficient privileges error when trying to access Azure Graph APIs
The link above is essentially the situation I'm in, save that I'm connecting to a B2C directory. As near as I can tell, I don't have a way to specify privileges as that questions answer suggested. There is a section for 'Keys' but the keys it generates are really quite different than the keys that regular AD apps generate.
When I do try to use the key, I just get the insufficient privileges error.
I also tried locating my app in the main, regular AD, and adding keys and ALL permissions, but I also got the same error (and there doesn't appear to be any way that I can see to determine if I even got closer)
To add to the confusion, there are different ways to get to the registered "applications" in the Azure portal. I can go in through the B2C settings, or through the regular AD settings. In the B2C side of things, I can generate keys (but as I said, they're quite different from the keys generated on the AD side), but I cannot do annything with Privileges... no option exists. on the AD side, I actually see two apps for my 1 B2C app... it looks like there's one which has the same ID as the B2C app (but using that key and privileges does nothing), and theres another, which also doesn't appear to have any useful qualities that I've figured out.
I'm out of ideas. What else can I try?
edit
I've done some more experimenting, and found that if I use an incorrect ID or Secret, I get appropriate error messages. So, by this I assume that I am "Authenticating" correctly. The problem seems to be that, as the error message indicates, my Key does not have sufficient permissions.
To that end, I've added every single available permission under both "Windows Azure Active Directory" and "Microsoft Graph" ... No improvement, I still fail to have the required privileges. I guess I'll add ALL the available permissions, and see if that seems to help any.
-- Nope, there are NO remmaining privileges to add, but I still get the insufficient Privileges error message.
Additionally, making the login-user an AD administrator, doesn't make any difference.
You're likely missing a so called admin consent in your flow. Basically, its not enough to grant permissions (those which are marked "Requires admin") using the portal, but also a user with admin rights should consent that grant. The tricky thing is that this consent isn't shown automatically when an admin user signs in (like it happens with regular user consent). You have to add a prompt=admin_consent parameter to the url of the page where you enter credentials, press enter, and then login. In this case you will see the admin consent, asking if you want to grant the permissions.
You can read more about admin consent here: https://learn.microsoft.com/en-us/azure/active-directory/active-directory-devhowto-multi-tenant-overview#understanding-user-and-admin-consent.
I also discuss this problem here: https://github.com/Azure-Samples/active-directory-dotnet-graphapi-console/issues/38#issuecomment-264664883