When "User Assignment Required" is turned on for the application in Azure AD and the user is not directly assigned on in the group that is assigned, the logon process gets stuck at an Azure AD error message and won't return to the Angular code.
Is there any setting in MSAL that will allow for handling this error and displaying a "not logged on" type of screen that can provide instructions for how to get access?
This is the know issue.
This AADSTS50105 error means the user is not assigned to a role for the application when trying to sign into a SAML-based single sign-on configured app that has been integrated with Azure Active Directory.
When the silent signin sent to the login.microsoftonline.com endpoints, then AAD cookies is not being detected. And the cookies determined if the user is loggedin or not
Possible resolution: Some of the third parties disabled the cookies from which user can face this issue. You need to whitelist the login.microsoftonline.com endpoints in the browser extension.
Possible resolution: You can catch the error in callback and ask the user to login again and if the error occur you will ask the user to login again.
Related
I have a web app which sends emails (gmail) in name of my users
When a user registers, she supplies gmail account and password. Also she has to enable access for Less Secure Apps (I recommend to create a new account for this)
Then I can open a gmail session
session = Session.getInstance(props, new javax.mail.Authenticator() {
protected PasswordAuthentication getPasswordAuthentication() {
return new PasswordAuthentication(user.getEmail(), user.getPassword());
}
});
and send emails on her behalf.
Unfortunately this is going to stop working next 30th May, when Google will allow only OAUTH2 access
I have followed Java Quickstart for Gmail API and I have code up and running for sending emails with OAUTH2: enable gmail api, create an application on google cloud platform, grant send permission, oauth2 client id credential created...
The problem I have is I can't see a way to automatize this task because when creating an authorized credential, a consent screen displays on browser and you have to select the account to be granted manually (maybe because my app in google cloud platform is still pending to be reviewed)
Is there a way to infer the gmail account you want to access from the credentials file (client_secret.json)? Is there a way to automatize this?
No, or yes. It depends.
The whole point of OAuth2 is to improve security by working with authorization tokens rather than asking for user credentials. To do this the user has to consent to the app's access request, and thus the OAuth consent screen cannot be bypassed. This is
explained in Google's documentation. It's not related to your app's review status but rather it's the way OAuth works.
You can still work in a similar way, though . Instead of asking for username and password upon the user's registration you can redirect them to the OAuth consent screen so they can authorize your app. Make sure that your app is requesting offline access type and then you can retrieve an access_token and a refresh_token. These will essentially work as your credentials and you can use the refresh token to generate new access tokens when needed without having the user go through the consent screen each time.
The refresh token doesn't have a "natural" expiration so you can keep using it indefinitely, but there are a few scenarios where it will become invalid, such as it not being used for six months, the user changing passwords (if using Gmail scopes), the user manually revoking access, etc. In these cases you will need to direct them to the consent screen again to reauthorize your app.
In this sense, your app can still work automatically without user input except the initial setup, which you already had to deal with when they supplied you with their credentials. The refresh token expiration can even be compared to what you had to do when the users changed their passwords in your current workflow.
One exception to this are service accounts. If you and your users are part of a Google Workspace domain you can delegate domain-wide access to it, then the service account will be able to access user data without any manual input. Of course, this is because as the domain administrator you pretty much own all the accounts under it. But if you're working with a publicly available application you will have to deal with the limitations I mentioned above.
Sources:
Google's auth overview
Using OAuth 2.0 to access Google APIs
OAuth 2.0 for web applications
The OAuth consent screen
I've implemented the OAuth flow in a Teams bot similar to the sample, and I'm able to get a user token and make calls against the graph, but I'm running into an issue with changing permissions. Here's what I did:
Created a bot and gave it mail.read
Add the bot for a user and trigger the OAuth dialog. User is prompted for consent, and signed in.
Successfully read mail
In AAD, added the Mail.ReadWrite and Mail.Send permissions to the app
Next time the OAuthPrompt was triggered, token was returned immediately. No prompt for consent.
Got an access denied exception when trying to write or send mail
So the issue is that changing permissions on the app does not automatically trigger the consent flow again in the OAuthPrompt. I also tried these troubleshooting steps:
I manually signed the user out (botAdapter.SignOutUserAsync) and signed back in, but was not prompted for consent again.
Same as above, but signed out of Teams as well. Launched the web client in a new incognito window, and still no prompt for consent.
Uninstalled and re-installed the bot on the user's account. No change.
Tried the above after waiting a few hours, but still no change.
The only way I found to trigger the consent flow again was to have the user go to https://account.activedirectory.windowsazure.com/r#/applications and delete the consent from there. Even then I had to call botAdapter.SignOutUserAsync (since the bot service still returned a token with the old permissions). Once I did that, and triggered the OAuth prompt again, I was able to get the consent flow with the new permissions to trigger.
So my question is, is there a better way to handle this? If a new version of the bot requires new permissions, shouldn't the OAuthPrompt from Microsoft.Bot.Builder.Dialogs and the bot service handle re-prompting for consent?
Short answer
Bot Framework's auth provider for AAD v1 isn't flexible enough to support adding scopes.
You can switch to the AAD v2 provider and specify your new scopes in the OAuth Connection Settings. Then, if you force the user to sign in again (after SignOutUserAsync), you will get a consent screen including the new scopes. To set up the AAD v2 provider, see the Bot Framework docs on adding authentication to a bot, which has steps for both the AAD v1 and AAD v2 providers.
Long answer
The key to this behavior is how the AAD v1 and AAD v2 endpoints handle permissions and consent differently.
The problem with v1
In v1, the permissions (such as Mail.Send) are pre-registered in the AAD app registration. During sign-in, AAD checks if the user has already consented to any scopes for the app.
If yes, AAD skips the consent screen and eventually provides an access token for the scopes that had already been consented.
If no, AAD shows the consent screen for all registered scopes and eventually provides an access token for all of those scopes.
This explains the behavior you're seeing. After you tell Bot Framework to forget the current access token (via SignOutUserAsync) and force the user to login again, AAD sees that the user has consented previously, so it skips the consent screen and gives you a new token with the old scopes.
Then how do you add permissions for users who have already consented, without forcing the user to delete consent for the app? AAD's login endpoint has an optional prompt parameter that you can set to prompt=consent. This will force AAD to show the consent screen as if the user had not previously consented, and it will contain all registered permissions. So if you try to use an access token and get a 403 Forbidden error (or an equivalent exception), you can take the user through the login flow using prompt=consent.
Unfortunately, with Azure Bot Service's AAD v1 provider, you don't have enough control over the login URL to dynamically set the prompt parameter, so there isn't an easy way to achieve this.
Enter v2
But there's hope! The AAD v2 endpoints have a much more flexible way of adding scopes incrementally. In v2, for delegated permissions, the permissions do not have to be pre-registered in the AAD app registration. Instead, you specify the scopes in the scope parameter of the login URL. During sign-in, AAD checks if the user has consented to the scopes you specified in the URL.
If yes, AAD skips the consent screen and eventually provides an access token for the scopes you specified.
If no, AAD shows the consent screen for all the scopes you specified and eventually provides an access token for all of those scopes.
Either way, you end up with an access token containing all the scopes you specified in the URL.
Bot Framework sets the scope parameter using the scopes you specify in the OAuth Connection Settings. So if you add a new scope there, then the next time the user signs in, they will get a consent screen with the new permissions, and you will get an access token with the new scopes. (Note: To re-trigger the sign-in, you will still have to sign the user out using SignOutUserAsync. Otherwise, Bot Framework will continue giving you the access token it already has, instead of performing a new sign-in flow with AAD.)
I received this error when trying to authorize my app with my own account:
Your project is trying to access scopes that need to go through the verification process.
{invalid=https://www.googleapis.com/auth/contacts}
If you need to use one of these scopes, submit a verification request. Learn More
When I use a different account, the error message is different:
This app hasn’t been verified to access:
{invalid=https://www.googleapis.com/auth/contacts}
Are you the developer? If this project needs these scopes, sign in to an account with access to edit your project and try again.
If not, contact the developer for help.
As per the announcement on May 11, 2017, publicly available applications with access to certain user data must pass review. If you see an access error for your app, submit a request using our OAuth Developer Verification form.
For personal-use apps and those you are testing, join the Google group Risky Access Permissions By Unreviewed Apps, which allows you to approve data access for personal and testing accounts. See the Google API Services User Data Policy for more information.
UPDATE: Corrected broken link to form.
I am trying to run the active-directory-dotnet-webapi-onbehalfof sample in single tenant mode. I've registered the web app service and the native app client as global admin for the tenant. When I run the sample, as a user in the tenant, I can get a token in the client only after consent pops up (first-time for user), and then call makes it to the service, but there it fails with below. Why is that? Documentation says that when a tenant admin registers the application no further consent is needed? I don't think it is possible to give consent when a remote webapi tries to get OBO token. Something seems buggy... AAD team, please clarify how the OBO feature should be used.
AADSTS65001: The user or administrator has not consented to use the application with ID 'b824502e-fe8a-4770-bd98-8d65a07efcc3'. Send an interactive authorization request for this user and resource.
Trace ID: ad7843d0-be4e-4098-8f7c-43c8e5505cfc
Correlation ID: 140466a4-7250-429f-8843-dbd4f63dc60e
Timestamp: 2016-11-25 21:46:13Z
When you register an application using the Azure Management Portal (manage.windowsazure.com) as a tenant administrator, then yes you should not get consent, as long as subsequent tokens are being retrieved in that same tenant.
Because you are seeing consent for the native client app, and then getting that error message, we must assume that something is not being satisfied which would suppress consent for your app.
To resolve this issue, my recommendation is to simply initiate an interactive authorization request just like the error message implies. You can do this by generating a log-in url for your application, with a specific query string that will force prompt tenant wide consent (prompt=admin_consent).
Here is the skeleton for the URL you need to complete:
https://login.microsoftonline.com/<TenantID>/oauth2/authorize?client_id=<AppID>&response_type=code&redirect_uri=<RedirectURI>&resource=<ResourceURI>&prompt=admin_consent
You can do this for all the applications you registered, and you should not run into consent issues (assuming you are indeed signing in as a tenant admin).
I hope this resolves your issue.
I am creating a windows plugin which would access Yammer data like groups user follows etc, for this i created a client application and accessed yammer rest api using client id and access token i get after user allows my app to access his data in a consent page. I am able to successfully do all this when people of my network are trying to login but this does not work when the plugin is being used by people of other networks, I am able to receive the access token after the user gives his consent in user consent page, but when i try to access his data like fetching groups using rest uRL i get an error saying "{"response":{"stat":"fail","code":17,"message":"Attempt to access a protected resource failed."}}"
please be noted the client app i created is not yet deployed into Global App directory, I really doubt if this is the actual cause of the issue, because i think if this was an issue it should not have recognized the client id itself and would not have shown the external network users the consent page too. may be if i am wrong please correct me
To access users on other networks' data, your app must be globalized (even if you don't want it to be listed in the Global App Directory). Without the user's consent, your app is not allowed to attempt to login on behalf of the user, thus they see the popup for authentication, and then the auth process fails because the app is not globalized.