Not an issue - Potential problem solver for microsoft authorization error "Usage of the /common endpoint is not supported"

[ArthurBorsboom]

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.

[pdobsan]

This is not an issue with oama, but an addition to a potential (future) problem solver for common errors.

Tangentially related: every field in the services section of the output of the oama printenv command can be changed in the config file.

[swaeberle]

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]

~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]

I set the tenant field but it still gives me the same error.

  microsoft:
    tenant: <some tenant>

[waleedabdeen]

Same here, the tenant field seems to be partially implemented. When navigating to the localwebserver, oama seems to identify the correct tenant and navigate accordingly. However, in the error message it still shows in the rawPathInfo: /common/login also the same in printenv where the common endpoint is used.

[vatai]

As per @pdobsan 's comment, everything you see in printenv you can also modify including auth_endpoint: and token_endpoint:.

Strangely, after setting those values to

    auth_endpoint: https://login.microsoftonline.com/<MY_TENANT_ID>/oauth2/v2.0/authorize
    token_endpoint: https://login.microsoftonline.com/<MY_TENANT_ID>oauth2/v2.0/token

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]

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:

defaultServiceAPI :: ServiceAPI
defaultServiceAPI =
  ServiceAPI
    { endpoint_prefix = Nothing
    , endpoint_auth_suffix = Nothing
    , endpoint_token_suffix = Nothing
    , token_endpoint = Nothing
    , tenant = Nothing
    ...

Then we can have the default config be like:

      ( "microsoft"
      , defaultServiceAPI
          { endpoint_prefix = Just "https://login.microsoftonline.com"
          , endpoint_auth_suffix = Just "oauth2/v2.0/authorize"
          , endpoint_token_suffix = Just "oauth2/v2.0/token"
          , tenant = Just "common"

and construct the link as endpoint_prefix/tenant/endpoint_{auth,token}_suffix in code later.

The {auth,token}_endpoint keys can still be provided for compat by setting them to null by default.

[pdobsan]

@siddhpant , Hmm, a bit too much microsoft specific to my taste.

How about setting both tenant and the {auth,token}_endpoint as @vatai did it. Although in this case also setting the tenant field 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]

@pdobsan Yeah you are right.

Another solution for least surprises can be that we can just s/common/$tenant in 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]

Another solution for least surprises can be that we can just s/common/$tenant in the endpoint link if it's the default

Okay, I have implemented this. Could some of you with various microsoft accounts test it before I make a new release?

[siddhpant]

Works after the following changes:

• Reverting 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.
• Changing cabal version in oama.cabal back to 3.8, on Debian testing (and on default ghc) it isn't 3.12.

Testing: msmtp -d <office365 email> <<< test

Thanks!

[pdobsan]

On Fri, Oct 11, 2024 at 08:17:05AM -0700, Siddh Raman Pant wrote:

Works after the following changes:

Great, thanks. Would you mind to post the output of the printenv command and some explanation what kind of account, id/secret you are using.

[siddhpant]

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.