Repository navigation
Not an issue - Potential problem solver for microsoft authorization error "Usage of the /common endpoint is not supported" #52
Description
This is not an issue with oama, but an addition to a potential (future) problem solver for common errors.
For anyone running into an authorization error with a Microsoft account Usage of the /common endpoint is not supported a potential solution is provided in the error message: Use a tenant-specific endpoint or configure the application to be multi-tenant.
In my case it helped to change the multi-tenant setting in the Microsoft Azure portal.
[Azure] > [App registration] > [Authentication] > [Supported account types] > [Accounts in any organizational directory (Any Microsoft Entra ID tenant - Multitenant)]
Full error message:
Authorization started ...
{"error":"invalid_request","error_description":"AADSTS50194: Application 'xxxxxxxxxxxxxxx'(xxx: xxx, xxx, xxx) is not configured as a multi-tenant application. Usage of the /common endpoint is not supported for such applications created after '10/15/2018'. Use a tenant-specific endpoint or configure the application to be multi-tenant. Trace ID: xxxxxxxxxxxxxxx Correlation ID: xxxxxxxxxxxxxxx Timestamp: 2024-05-23 07:46:01Z","error_codes":[50194],"timestamp":"2024-05-23 07:46:01Z","trace_id":"xxxxxxxxxxxxxxx","correlation_id":"xxxxxxxxxxxxxxx"}
Authorization failed.
Activity
pdobsan commentedon May 23, 2024
swaeberle commentedon Jun 27, 2024
Maybe its better to keep the application single-tenant and use
https://login.microsoftonline.com/organizations/as base URL for the endpoints.At least that's working in my case.
siddhpant commentedon Jul 8, 2024
Not everyone can change the application. How is it that mailctl is working? Is this a recent error? But the date mentioned in error is 2018.EDIT: Nvm, tenant is baked in the link in mailctl.
siddhpant commentedon Aug 14, 2024
I set the tenant field but it still gives me the same error.
waleedabdeen commentedon Sep 24, 2024
Same here, the tenant field seems to be partially implemented. When navigating to the localwebserver,
oamaseems to identify the correct tenant and navigate accordingly. However, in the error message it still shows in therawPathInfo: /common/loginalso the same in printenv where thecommonendpoint is used.vatai commentedon Oct 3, 2024
As per @pdobsan 's comment, everything you see in
printenvyou can also modify includingauth_endpoint:andtoken_endpoint:.Strangely, after setting those values to
the option for "Organization login" disappears (only the github option remains). I might have to do with the fact that my organisation uses Okta for authentication?!
siddhpant commentedon Oct 7, 2024
Yeah, the tenant actually isn't substituted in the link in the code, it blanket uses the hardcoded common endpoint.
I think the endpoint can be split into multiple variable, something like:
Then we can have the default config be like:
and construct the link as
endpoint_prefix/tenant/endpoint_{auth,token}_suffixin code later.The
{auth,token}_endpointkeys can still be provided for compat by setting them to null by default.pdobsan commentedon Oct 8, 2024
@siddhpant , Hmm, a bit too much microsoft specific to my taste.
How about setting both
tenantand the{auth,token}_endpointas @vatai did it. Although in this case also setting thetenantfield might have been forgotten and that caused the problem.The fact is that despite of tenant being part of the endpoint URL-s it is also required to be sent in the query string as I understand.
siddhpant commentedon Oct 9, 2024
@pdobsan Yeah you are right.
Another solution for least surprises can be that we can just
s/common/$tenantin the endpoint link if it's the default (edit: nvm that makes it more ms specific than the above).We can add simply add a text in README mentioning this.
pdobsan commentedon Oct 10, 2024
Okay, I have implemented this. Could some of you with various microsoft accounts test it before I make a new release?
siddhpant commentedon Oct 11, 2024
Works after the following changes:
set a corrected scope for microsoft, it adds more scope and so leads to a page to request admin for access, and asking for justification.oama.cabalback to3.8, on Debian testing (and on default ghc) it isn't 3.12.Testing:
msmtp -d <office365 email> <<< testThanks!
pdobsan commentedon Oct 11, 2024
siddhpant commentedon Oct 11, 2024
It's an internal client/secret pair, nothing else is changed from default except tenant.
I just tried main without the POP permissions and it works.
I'll let others try. If it's an issue for others too, then maybe we can add a flag for POP support, or just mention in the README that one can override the setting for disabling/enabling POP.
I don't think POP is common among outlook/o365 users, especially those requiring OAuth, but I could be wrong.