search

tarickb / sasl-xoauth2

SASL plugin for XOAUTH2
Other
72 stars 20 forks source link

Support Outlook.com Client Credentials Flow #76

Open hannibal218bc opened 9 months ago

hannibal218bc commented 9 months ago

Hi,

I'd like to use this project to authenticate as an application to a Microsoft365 tenant, but it seems that's not supported?

There is client_id, client_secret and token_endpoint (https://login.microsoftonline.com/<TENANT>/oauth2/v2.0/token) provided in /etc/sasl-xoauth2.conf. When attempting to send mail, postfix logs:

sasl-xoauth2: auth failed: 2023-10-11 00:26:59: TokenStore::Read: failed to open file /etc/tokens/<SENDER>: No such file or directory

So I used Postman on the credentials to retrieve a token, and pasted that into the SENDER token file. That takes me one step further:

sasl-xoauth2: auth failed: 2023-10-11 00:18:22: TokenStore::Read: missing refresh_token

And indeed, there's only token_type, expires_in, ext_expires_in and access_token present in the token file. However, the client credentials flow should directly use the access_token as long as it is valid... ?

The credentials belong to an "app registration" and already has all necessary rights and consents, hence I don't want to go through any additional consent dialog (as the --use-device-flow flow would suggest).

Did I miss something? Thank you very much!

tarickb commented 9 months ago

Yes, authenticating with Microsoft 365 is supported. Please follow the instructions in the README, including the use of sasl-xoauth2-tool. I'm not familiar with Postman or with what specific use case you have but sasl-xoauth2 will not work without a refresh token (how else would it obtain an access token when the access token expires?).

hannibal218bc commented 9 months ago

Yes, that's the point: with the "client credentials" flow, there really is no refresh token. You use the credentials to directly obtain an access token, which is then valid for a certain time. After that, you fetch a new access token (again providing client_id and client_secret).

The README.md describes only setups where you must, at some point during setup, log in to Microsoft as a user and grant the application access on your behalf. The resulting tokens allow the application to act as this user .

In the flow I need to use, the application acts on its own. All necessary rights have been granted directly by the tenant administrator, there is no further user interaction or consent necessary.

We are successfully using these credentials with MSAL, so I'm quite sure that the setup process documented in README.md do not apply to this kind of token/flow... ? Thanks again...

tarickb commented 9 months ago

Ah I see -- I wasn't aware Microsoft 365 had that as an option. sasl-xoauth2 doesn't support that sort of authentication at the moment but I'll leave this open as a feature request.