AquaMail Forum
English - Android => Development builds => Topic started by: Kostya Vasilyev on January 16, 2018, 07:57:02 pm
-
https://www.aqua-mail.com/download/AquaMail-market-1.14.0-747-dev-22e5464249df.apk
https://www.aqua-mail.com/download/AquaMail-market-1.14.0-750-dev-95ece5523b20.apk
---
+ Fixed issue with Gmail OAUTH2, sometimes not able to add account which is not present in phone Settings
+ Build 750: OAUTH2 sign-in for Office 365 now working, including two-factor (MFA, code over SMS). Big thanks to @swreg.
---
+ Исправление для Gmail OAUTH2, иногда не получалось добавить учётку которой нет в Настройках телефона
+ Сборка 750: OAUTH2 авторизация для Office 365 заработала, в том числе двух-факторная (SMS коды). С благодарностью @swreg.
-
Hello,
I have installed this dev version (also Pro enabled) to try the Office 365 OAUTH2 authentication because I need MFA support. I have tried it against two different Office 365 tenants (one with and one without MFA required), but both fail after putting in e-mail address and password to the Microsoft generated "new experience" login web pages. In both cases the error page returned says:
User account 'myname@company.com' from identity provider https : // sts.windows.net/GUID_of_my_company_AAD_tenant/ does not exist in tenant 'Aqua Mail' and cannot access the application 906be9aa-2843-47e6-a01d-ab9361ca7009 in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account.
I guess it probably works for you since you have Aqua Mail as a registered app in your 'Aqua Mail' tenant/AAD portal.
I searched in the AAD enterprise app gallery for Aqua Mail to add it as an authorized app in my tenant, but did not find a match.
Am I missing some piece of the puzzle? Of course I understand you emphasized it was "mostly" working and has not been formally released yet.
Just excited to see MFA with Office 365 is near.
Regards,
swregs
-
Aaaargh. MS never makes anything easy :)
Yes you're right, I was testing with an account that's owned by same "tenant".
1 - I will ask our QA to try logging in from a different tenant (they have a separate subscription).
2 - Found this:
https://blog.mastykarz.nl/configuring-multi-tenant-authentication-azure-app-service-authentication-options/
It's obvious that you know more about "Azure Directories" and "tenants" and all that than me -- could you possibly take a look at that link and tell me if it makes sense?
-
LOL - I went to portal.azure.com to see that "allow multi-tenant" setting - and Aqua Mail app registration isn't even showing!
It was a few days ago. The rest of the portal seems to be operational as usual.
-
@swregs
Could you please try this build?
https://www.aqua-mail.com/download/AquaMail-market-1.14.0-749-dev-3ee56a3afaa9.apk
The app's registration was already "multi-tenant", I added "prompt=consent" on the approval URL per the article I linked above. Let's see if this resolves the issue.
-
I believe we will have to learn on this together.
I am using this URL to get to the app registration blade for my tenant.
https : //portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps
Of course I do not see Aqua Mail since it is an app you registered in your tenant.
For my tenant, in the Office 365 Admin Center under the Services and add-ins settings I have "Integrated Apps" turned on, which supposedly allows end-user accounts in my tenant to give 3rd party apps access to their data. This may only apply to website based services with SSO.
https : //support.office.com/en-us/article/turning-integrated-apps-on-or-off-7e453a40-66df-44ab-92a1-96786cb7fb34
The link you posted seems oriented to the web app side, not mobile client side. If I understand Aqua Mail properly, it interacts directly with the Outlook/Exchange Online REST APIs without using an intermediate web app.
According to this https : //docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-dev-glossary#multi-tenant-application
if indeed you created your app registration as a "native" type app (not "web app / API"), then it should have defaulted to multi-tenant enabled. I believe "native" is the correct type to use for installed mobile apps. I just created a AquaTest "native" app registration and the properties don't even give a multi-tenant choice. (Picture attached) If I look at some of my existing "web app / API" app registrations, they do have a selection to switch the tenancy mode. It looks like you would have to delete an existing registration to remake it as "native" type registration where you add in the requested permissions to the Office 365 Exchange Online APIs and then use the new Application ID (client_id) and Redirect URI in the app build.
Supposedly upon first login from the app, it will authenticate and then do the one-time consent prompting if I allow the app to use the permissions it needs to interact with Exchange Online APIs using my account.
It also seems confusing because it appears there are two different portals where apps can be registered. The older way is in Azure portal which only does app auth against AAD tenants. They seem to be pushing to use the newer "Microsoft Application Registration portal" https : //apps.dev.microsoft.com as place to register apps which are able use either Microsoft account or AAD accounts as well as converged Graph APIs to most all MS services.
Was typing this as you replied. Will try that new build in a few minutes and report back.
Thanks,
swregs
-
@swregs
Appreciate it, since in "MS land" I'm a stranger :)
- Aqua Mail is not cloud based, so there is no "intermediate web app"
It's only the app on the device connecting directly to a mail server.
- It is registered on Azure Portal as a "native" app...
... which are always "multi-tenant enabled" and this cannot be changed
- As a test, I also created a web based app...
... and there was a switch for multi-tenant on/off (sanity check)
- The new 2.0 APIs they're pushing do not support EWS (Exchange Web Services) or IMAP.
There is an all new, REST / JSON based, Microsoft-specific, Mail / Calendar / Contacts API that can be used to access Office 365 or Hotmail (Outlook.com) accounts the same way (just like EWS, ironically).
---
And so I believe the only thing we were missing was the addition of "prompt=consent" on the approval URL. I added that in build 749 above.
---
I have "Integrated Apps" turned on, which supposedly allows end-user accounts in my tenant to give 3rd party apps access to their data.
Is this (assuming it's relevant) enabled by default, do you happen to know?
I'm wondering if new users would be able to sign into their Office 365 accounts without having to ask their admins to enable this setting first... If you happen to know...
-
Unfortunately, no change. In AquaMail, I tried upgrading an existing account to OAUTH2 login and also tried adding a new account directly as Office 365 type. In both cases, after username and password sequence I get the same failed response saying my account is not in the 'Aqua Mail' tenant and thus cannot access the application id 906be9aa......
I am fairly sure the "Integrated Apps" is on by default.
My understanding of OAUTH2 flows is thin. Are you using one of the MS provided Android SDKs like ADAL or MSAL?
I read that you have to use a multi-tenant aware auth endpoint instead of tenant specific endpoint.
It says https : //login.microsoftonline.com/common instead of https : //login.microsoftonline.com/tenant_domain towards the end of this section in the docs https : //docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-authentication-scenarios#basics-of-registering-an-application-in-azure-ad
If using ADAL, the authority endpoint seems to get specified when making an AuthenticationContext.
http : //simonjaeger.com/get-started-with-adal-for-android/
-
@swregs
No we don't use any SDK's - I wrote our OAUTH2 code originally for Gmail in 2014 and we've been building on top of that ever since.
But that's not the issue - we currently support OAUTH2 for Gmail, Hotmail, Yahoo, Yandex and they're all fine.
OAUTH2 is a pretty basic and low-level thing and every company does it a little differently.
In this case MS has some logic on top. "Tenant" and "Azure Directory" are not even OAUTH2 concepts, they're MS concepts, so that's what we're dealing with here, this "MS specific stuff on top of OAUTH2".
---
Long story short:
I now replaced tenant_id with "common" in the approval and token URLs (and kept the "prompt=consent" change from 749 which I believe is also required).
This still works for my account (so it's not completely broken by the "common" change :) ) - let's see if it makes any difference for your account:
https://www.aqua-mail.com/download/AquaMail-market-1.14.0-750-dev-95ece5523b20.apk
-
Ok, so far so good. I tried 3 different accounts in three different directories/tenants. One was an in-place upgrade to OAUTH2, one was adding new account, and one was in-place upgrade to OAUTH2 of account that required me to MFA as part of the process. All three are working.
It looks like mail, calendar, and contacts all sync given the "mailbox" access consent I allowed to "Aqua Mail" app when logging into each account. I guess you get access to all needed data via EWS since those are really just folders in the mailbox.
Thanks for the efforts!
-
All three are working.
Wonderful!
It looks like mail, calendar, and contacts all sync given the "mailbox" access consent I allowed to "Aqua Mail" app when logging into each account. I guess you get access to all needed data via EWS since those are really just folders in the mailbox.
The permission is called "Access mailboxes as the signed-in user via Exchange Web Services" -
- which covers all off the EWS protocol (which is what we use).
There is a similar "inclusive" permission for ActiveSync.
( by contrast, the "new" APIs that you'd mentioned earlier use finer grained permissions )
Thanks for all the help (I remember seeing "common" in the docs , but was't 100% sure if it was required).
-
Was curious for myself to read more about low-level OAUTH2 flows, which got me to this docs page, which I am sure you have already seen.
https : //docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-code
In the "Request an authorization code" section, looking at the parameters table, the "prompt=" value choices are listed. If the documentation is to be believed (which seems to often be wrong or stale compared to pace of feature updates and changes in Azure) and depending on your implementation, I wonder if using "prompt=consent" will always require a re-consent, instead of just the first time a user connects it to their account. For example, my MFA enabled tenant requires re-login after 14 days or sometimes more frequently if it detects the same account is accessing resources from different or new locations. With most apps, the AAD login page gets the password again and redoes MFA verification (Microsoft Authenticator app in my case), but does not re-do the consent step again.
I'll watch out to see what happens when my next re-login happens to be triggered.
-
I wonder if using "prompt=consent" will always require a re-consent, instead of just the first time a user connects it to their account.
...
I'll watch out to see what happens when my next re-login happens to be triggered.
According to this:
https://blog.mastykarz.nl/configuring-multi-tenant-authentication-azure-app-service-authentication-options/
prompt=consent is required for the initial login:
...the first time you try to authenticate to a multi-tenant application it isn't registered with your organization's AAD. To fix this issue you have to trigger the consent flow which will allow the user to login with their organizational account and grant the application the necessary permissions. The consent flow can be triggered by adding &prompt=consent to the Azure login URL.
...although I'm unable to find direct evidence of this in official docs.
So, sure, please keep me posted about the "14 day password expiration" case - we could try to omit "prompt=consent" on repeat authorizations. On the other hand, once the user has entered the password (and possibly dealt with MFA) - approving the permissions again is just a single tap :)
-
Yesterday I hit the "14 day password expiration" case. I was able to re-auth with MFA without issues, although it takes a few steps. This surfaced as a notification indicating "Incoming server login error". Going to the account list screen the same message is shown for the account. Clicking into the account enters the account setup screen where you have to hit "NEXT" to trigger the re-auth, enter password, possible MFA, and then re-prompt/accept for permissions, to be at end of setup stage where you have to hit "SAVE" to get back into e-mail.
I suspect I am sensitive to the number of steps since most end-users already complain about the interruption of having to re-login on a regular occasion or due to conditional access invalidating tokens.
Thanks, wanted to report back that it was working during re-auth scenario.
-
Alright, let's take this "in reverse order":
- The uses has to re-auth because that's your server's policy
- To indicate this to the user, we show a login error on the app's main screen
- But the app may not be running (started, visible on the screen) at all, so we show a status bar notification
Do you have suggestions on improving this "flow"?
-
Currently AquaMail is helpful that the main screen identifies which one or more accounts are having an issue. And I believe the login error notification identifies the account to which it applies. I have used/seen some mail apps that flag login error and you can't tell which account is having the problem until it hands-off to OAuth flow and you see the branding (if configured) for the tenant (and if you have more than one account at that same tenant then good luck).
Currently, also I think the AquaMail main screen shows transient errors like connectivity issues as I have seen misc occasions one or more of my Office 365 accounts flag warning. Those fix themselves on their own or if I click the account to force immediate refresh.
One possibility for the re-auth "flow":
- instead of generic login error, in the main window account list for the account entry or the account specific notification indicate something like "Re-authentication is requested."
- user clicks on account from main window list or clicks the notification
- immediately goes to server provided OAuth flow (enter password and possible MFA)
- if completed successfully, drop into message list for the account so I can see what I may have missed while access was disrupted (although I can imagine some might prefer when the notification was used to satisfy re-auth that the app just returns to the background)
Other observations:
-For me, getting a re-prompt for permissions during OAuth flow tends to make me go down the path of "why have the permissions changed since I originally allowed the app access"
-If a re-auth was requested by the server, but not resolved/ignored in AquaMail, a persons conditional access situation may have changed before they do the re-auth (like they got back to their office that is whitelisted to not require MFA); in this case I'm not sure if an interactive re-auth is still needed
- Does the error code / response code from the auth server allow ability to distinguish if the need is a requested re-auth vs permanent auth failure (aka will require intervention of IT, like to re-enable account, re-attest authenticity of device, etc)
-
Well there are apps that don't report login errors at all :)
I just tried revoking Aqua Mail's permission from my account and when the app tried to refresh the token the next time, it go this:
{
"error":"invalid_grant",
"error_description":"AADSTS65001: The user or administrator has not consented to use the application with ID '906be9aa-2843-47e6-a01d-ab9361ca7009' named 'Aqua Mail'. Send an interactive authorization request for this user and resource."
}
... which does match what I did, but I'm not sure if the error would be different in your case (password expiration).
The "error" is the only thing we can count on (machine readable).
The "error_description" key is optional and then it would be a bad idea to try to parse that.
Re: instead of generic login error, in the main window account list for the account entry or the account specific notification indicate something like "Re-authentication is requested."
I'll try to make it be our already existing "please grant permission" message instead of the current "http 401".
But then again I don't know what exactly happens (what errors at what point) in your case.
Re: user clicks on account from main window list ... immediately goes to server provided OAuth
Click on account seems questionable (what if the user needs to read an already received message).
Clicking the error does run the account setup screen already.
---
On other observations:
If the password having expired causes the OAUTH refresh token to also expire - we'll need to get a new one, and this is done by running the login flow (the "login.microsoftonline.com..." in a window).
If that login flow does not require MFA specifically when the device is connected to the corporate network - sure, great, but that's "inside" that login flow and isn't controlled by our code.
We could try to remove the "consent" parameter to try to avoid the repeat permissions request - but I don't have enough info to know that this would work (and not prevent logins at all) with any degree of confidence.
---
Summary:
The only change I'm going to make right now is a special case for http 401 when there is OAUTH in use, and assume that the user needs to grant permission (our current error message for OAUTH errors).
-
In addition, I filed a task for "tap login error notification -> go directly to account setup screen" to reduce the number of taps it takes to re-approve an OAUTH account.
-
The change for better error message ("please grant permission" instead of the generic "http 401") is included in this build:
https://www.aqua-mail.com/forum/index.php?topic=6392.0