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.
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
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.
I am writing a Reddit client that uses OAuth to authenticate the user. One of the features I would like to implement is the ability to use multiple accounts simultaneously. This requires the user to authorize my client on each account they want to use. The problem I'm running into is that if the user is already logged into Reddit in their browser, when I pop a browser to perform the auth, it will have them authenticate my client against their currently logged in user.
Is there a way to force the user to re-enter their credentials? I would rather not have to put some kind of disclaimer on my Add Account screen that says "Please log out of Reddit in any open browser windows".
I tried opening the Reddit login page in a WebView so the request is sandboxed, and while that worked, it gives the user access to the entire login page (including all the links that navigate to elsewhere on the site). I don't mind that experience when I'm popping an external browser, but in an embedded WebView I really just want to present a username and password box along with the OAuth validation prompt.
Note: I do kind of prefer the embedded experience because it doesn't interfere with the users existing browser cookies, I just don't like how cluttered the login page is this way and I'm not sure how to prevent the user from navigating away from login. Also, for completeness, this is a UWP app, though this problem is largely technology independent.
The problem I'm running into is that if the user is already logged into Reddit in their browser, when I pop a browser to perform the auth, it will have them authenticate my client against their currently logged in user.
It may be caused by the authorization server. If so, we can not do anything in our client app.
But if it is not the server issue, in UWP, there is a WebAuthenticationBroker class witch can help you to authorize your app to access the user info from Resource server by getting a token. You can try to use the class to implement OAuth authorization. You don't need to use the in a WebView so that you can authorize your app with multiple users if you can manage all the user with the token properly in your code logic.
See the Web authentication broker topic and the sample to learn more details.
I was told by one of the engineers at Microsoft that in order to display the jobtitle field, using users method in REST, I need an admin permission. I would appreciate if someone can answer exactly what steps the domain administrator needs to take in order to give user.read.all permission to all users in the domain that will run the graph query. I would appreciate if anyone can provide detailed step by step instruction.
For user.read.all, you will need to get administrative consent from the organization before a regular user can sign-in to your application.
To do this, you'll first need to have them go through the “Admin Consent” workflow. This workflow requires an administrator but once complete any users of your application will have “admin consent” to the restricted scope.
For example, you would normally you would then authenticate users by redirecting them to
https://login.microsoftonline.com/common/oauth2/authorize?<your params>.
Since this scope requires an Admin however, you fist need to obtain consent by first having an Admin authenticate by redirecting them to
https://login.microsoftonline.com/common/adminconsent?<yours params>.
Once an Admin grants consent, normal users will be able to use OAUTH to authenticate.
Dan's link took care of the problem.
In the link the below sample link was the answer. Instead of the word "common", I have replaced it with the tenant ID as shown below:
https://login.microsoftonline.com/{tenant id from azure ad}/adminconsent?
client_id={application client id}
&state={can be anything. I used the same as the redirect url}
&redirect_uri={URL that exactly appears in the app application portal}
I am unable to revoke application access by a user via either a password reset or by explicitly clearing app keys in user management. The latter method gives a reply indicating that access has been revoked, but when the user hits the tool, they are not re-prompted to approve access to their information.
There are number of possibilities here:
It's possible that there is latency between the declared revocation of keys and the cleanup task that goes through the database and actually cleans them up; I believe that at one point, such a latency existed, was identified, and fixed through service packs and subsequent releases. Accordingly, you may address this issue by ensuring that your back-end service is up-to-date with its available service packs.
It's possible that what's being revoked is the keys, and the necessity to authenticate to rebuild keys, but not the confirmation step that would appear to the user asking for access permission (assuming the user once authenticated, and checked the "don't prompt me to ask for permission again") dialog.
Can you confirm if the request for user tokens by the client application actually does get back tokens? Or is it just that the authentication step happens with no notice of client confirmation to access?
Note that the re-authentication might appear to happen silently; if the client application's request for user tokens happens through a user's browser context where the back-end service can determine that the user is already logged in to the LMS, then the request for tokens could succeed automatically:
The user is assumed to have already authenticated in order to have an active web session, so there's no need to re-gather a username/password (or whatever user auth step the LMS uses) to re-confirm identity.
The user may already have confirmed access for the application and dismissed the confirmation step with "don't ask me again". If the user has confirmed access with "don't ask me again" this choice will get remembered, even if the user tokens get expired due to password change or access revocation by an admin.
If you explicitly log a user out of their LMS session, and then test the client app, this should indicate to you visibly whether the re-authentication step is actually taking place (the user's browser will then get directed to the login process for the back-end service).
Note that, although a user password change or access revocation by an admin can remove the recorded user Id/Key pair associated with an application, it does not remove the record of the confirmation form having been dismissed with "don't ask again". Currently our system does not expose a way to reset that confirmation state.
If after considering these points you feel you still have an issue, I would encourage you to open a support incident through your organization's approved support contact, or your account or partner manager. Desire2Learn takes security related reports quite seriously, and if you've uncovered an issue that hasn't yet been addressed, I would encourage you to report it as a defect.