Resource Owner Password Flow

[sflamm]

@simonrob @jryans

Can the proxy implement the ROPC flow?

For a class of legacy applications (like CRMs) that already store user profiles (email address/password) and send email for their users using basic auth SMTP/POP/IMAP the Resource Owner Password Flow is ideal. There would very little to configure...

The POP/IMAP requests contain the user email/password... wouldn't this be a straightforward way to use OAuth POP/IMAP/SMTP?

details here:

https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth-ropc

Please let me know if you can implement this in the proxy.

[sflamm]

https://learn.microsoft.com/en-us/azure/active-directory-b2c/add-ropc-policy?tabs=app-reg-ga&pivots=b2c-user-flow

[sflamm]

There is a sample python application using the MSAL library to obtain a token

https://github.com/Azure-Samples/ms-identity-python-desktop

[sflamm]

MSAL for Python supports ROPC flow:

https://github.com/AzureAD/microsoft-authentication-library-for-python/blob/ffc659091de0192754bd05d379acb8d1b4056eb8/sample/username_password_sample.py

[sflamm]

https://msal-python.readthedocs.io/en/latest/

[simonrob]

I'm reluctant to add any additional dependencies to the proxy, particularly on libraries such as MSAL that only apply to O365. MSAL is not a requirement for this particular OAuth flow, however.

Regarding ROPC itself, it does seem like it could address the common desire for no user interaction at the same time as SMTP support. Please note, however, Microsoft has clearly stated that they have no intention to remove basic auth for SMTP, so using the O365 server directly for SMTP and the client credentials grant flow for IMAP/POP seems to me to achieve the same outcome here?

[sflamm]

Understand the desire not to add a dependency on MSAL. Your code already obtains the Token without it so it is not needed ...
The reason I mentioned it - it demonstrates MSFT is supporting the Resource Owner Password Flow (works)

With the functionality you already have - it would seem straight forward to implement the Resource Owner Password Flow and it would be extremely helpful to everyone (as you mention this configuration is a common goal of many).

Even though MSFT claims it will not turn off basic auth on SMTP... it would future proof us against any change of direction from them... and it is a simpler setup to just configure our end applications (like CRMs) to just use an Email profile that sends all traffic through the proxy. It is also a very simple setup on the AD Application registration side...

Can you please add this?

[simonrob]

Ok – I can see why this might be useful. Adding the ROPC flow is not as straightforward as it first appears because it will require a new way to specify the flow type in an account configuration entry, which until now has not been required (and is not needed for any other provider). I want to be careful not to over-complicate the proxy, and am pretty over-committed right now, but will think about this in the longer term.

[sflamm]

@simonrob

understood. Can I suggest you add a "proxy-mode" to the [Server setup]? With the use of an explicit mode which fields to use and when will be very easy to understand... (even for the current flow support it would make things much clearer and avoid mistakes)

Probably instead of "proxy-mode" it should be named "OAuth flow type"... (essentially an Enum of the flow type the server supports)

[sflamm]

Even though MSFT claims it will not turn off basic auth on SMTP... it would future proof us against any change of direction from them... and it is a simpler setup to just configure our end applications (like CRMs) to just use an Email profile that sends all traffic through the proxy. It is also a very simple setup on the AD Application registration side...

Can you please add this?

This also eliminates the need to have a principal with permissions on any end user mailboxes (no permission maintenance).. as the end-user is authenticating themselves