pdobsan / oama

OAuth credential Manager
Other
138 stars 10 forks source link

Microsoft login revisited #18

Closed ferdinandyb closed 1 year ago

ferdinandyb commented 2 years ago

Recently, my university (or MS) turned off password login for outlook, so I had to revisit my login issue I had earlier.

In the end - since I still can't authenticate with mailctl I ended up using the mutt_oauth.py script. I noticed today, that you actually list that as an inspiration, so I thought maybe if you took a look at my (working) config for the mutt_oauth script and at the non-working mailctl we could figure out why mailctl is not working?

Here's my mutt_oath config and here for mailctl. One difference I found was the redirect URI, but changing that to the same on as in the mutt script made MS complain that the redirect uri is not the same as is configured for the client.

Another very obvious difference is that in the mutt script I can tell it which sasl method to use, that is oauthbearer for gmail and xoauth2 for outlook. Indeed of mailctl only supports oauthbearer that might explain the whole issue.

pdobsan commented 2 years ago

On Tue, Nov 29, 2022 at 02:21:50PM -0800, Bence Ferdinandy wrote:

One difference I found was the redirect URI, but changing that to the same on as in the mutt script made MS complain that the redirect uri is not the same as is configured for the client.

The scope parameters differ too: "office365.com" vs "office.com" Also, see below.

Another very obvious difference is that in the mutt script I can tell it which sasl method to use, that is oauthbearer for gmail and xoauth2 for outlook. Indeed of mailctl only supports oauthbearer that might explain the whole issue.

No, this sasl_method parameter is not used either in the process of authorization or of renewal. That is not part of the API mailctl using. It is in the mutt_oauth2.py only for testing a (not expired) access token with smtp, imap etc. protocols.

However, there is an extra parameter passed to the API in the case of microsoft: 'tenant': 'eltehu'

That might be the real culprit for mailctl does not deal with this possible parameter at all.

I'll look into this ...

ferdinandyb commented 2 years ago

On Wed Nov 30, 2022 at 22:33, Peter Dobsan wrote:

However, there is an extra parameter passed to the API in the case of microsoft: 'tenant': 'eltehu'

That might be the real culprit for mailctl does not deal with this possible parameter at all. You are probably quite right, now that I think about it :)

I'll look into this ... Thanks! Would be nice to be able to handle everything with mailctl.

ferdinandyb commented 2 years ago

Wow, github mobile absolutely butchers comments posted via email, even though they look ok on the desktop ... Anyway, let me know if I can help anything. I poked a bit around the codebase, but I don't know any haskell so I didn't really find my way unfortunately.

ferdinandyb commented 2 years ago

On another note: I'm planning to write a guide about setting up terminal based email sometime this month. It would be much more concise if I could leave out the mutt script altogether and just have mailctl in it for oauth authorization. So this is just an absolute no pressure question of whether you think you have the time to tackle this this year or not. If you think it's possible soonish, I'd be happy to wait for it. Setting up email is already pretty involved, so cutting some noise would be great :)

pdobsan commented 2 years ago

On Mon, Dec 05, 2022 at 01:11:51PM -0800, Bence Ferdinandy wrote:

mailctl in it for oauth authorization. So this is just an absolute no pressure question of whether you think you have the time to tackle

I just love such "no pressure" questions.

this this year or not. If you think it's possible soonish, I'd be happy to wait for it. Setting up email is already pretty involved, so cutting some noise would be great :)

Tell you what, while you are waiting why don't you follow up on what you mentioned in another (now closed) issue's thread: https://github.com/pdobsan/mailctl/issues/17#issuecomment-1331398198

ferdinandyb commented 2 years ago

I just love such "no pressure" questions.

:D I really meant no pressure, I think it would be perfectly reasonable if this would not be your preferred end-of-year activity :) So I was really just interested in it if you plan to do it or not and then plan accordingly.

Tell you what, while you are waiting why don't you follow up on what you mentioned in another (now closed) issue's thread: #17 (comment)

It's on my todo list for soonish, although I will probably have to wait at least a week after setting it up to see if it expires or not.

pdobsan commented 2 years ago

On Mon, Dec 05, 2022 at 02:01:26PM -0800, Bence Ferdinandy wrote:

:D I really meant no pressure, I think it would be perfectly reasonable if this would not be your preferred end-of-year activity :) So I was really just interested in it if you plan to do it or not and then plan accordingly.

Already doing it, but can only get there gradually. As a first step I implemented your fake email address trick. I don't want to release it yet since I have no company/institution email account for testing However, you could download the prebuilt binary from https://patchouli.sr.ht/builds.sr.ht/artifacts/~petrus/898933/a2284936a34cbd09/mailctl

Would you mind to test it?

mailctl authorize --help

explains the details.

ferdinandyb commented 1 year ago

Already doing it, but can only get there gradually.

Great! Thanks!

As a first step I implemented your fake email address trick. I don't want to release it yet since I have no company/institution email account for testing However, you could download the prebuilt binary from https://patchouli.sr.ht/builds.sr.ht/artifacts/~petrus/898933/a2284936a34cbd09/mailctl

Would you mind to test it?

mailctl authorize --help

explains the details.

I tested with both gmail and MS. It works great for gmail. It's hard to tell with MS since I can't actually get to the end, but it seems that MS actually does NOT need a workaround like this, but will force you to click a "can't find account" link and then navigate to the institutional login.

pdobsan commented 1 year ago

On Tue, Dec 06, 2022 at 12:23:17AM -0800, Bence Ferdinandy wrote:

I tested with both gmail and MS. It works great for gmail. It's hard to tell with MS since I can't actually get to the end, but it seems that MS actually

Here is the next iteration:

https://patchouli.sr.ht/builds.sr.ht/artifacts/~petrus/900053/e23ec1bbe42db49f/mailctl

This should send the tenant field during authorization in the case of microsoft. You need to include tenant: eltehu for microsoft in services.yaml. Try both redirect URI-s, the localhost one and what the python script uses. I don't really understand the latter one.

ferdinandyb commented 1 year ago

Here is the next iteration:

https://patchouli.sr.ht/builds.sr.ht/artifacts/~petrus/900053/e23ec1bbe42db49f/mailctl

Thanks!

This should send the tenant field during authorization in the case of microsoft. You need to include tenant: eltehu for microsoft in services.yaml. Try both redirect URI-s, the localhost one and what the python script uses. I don't really understand the latter one.

Using the redirect from the mutt script will try to start the process with that link + start appended, so I don't think that's supposed to work. Manually editing the URL just gives a blank page, but I guess that really shouldn't do anything.

Using localhost I get the following error: localWebServer: fetchAuthRecord: Error in $: Failed reading: not a valid json value CallStack (from HasCallStack): error, called at lib/MailCtl/Authorization.hs:312:21 in mailctl-0.8.0-a035a5d33e44961bf73809265601f89af0a027a194bd4c896a2256e87cbea692:MailCtl.Authorization

And here's mailctl's STDOUT: https://0x0.st/odbv.html

Note, that I needed to navigate several pages from start: signin-option -> sign in to org -> give org domain -> and finally actually logging in.

lahwaacz commented 1 year ago

What's the status of this? I used @ferdinandyb's client_id and client_secret with mailctl-bin-0.8.4-1 from AUR, but I'm getting this error from Microsoft:

AADSTS165000: Invalid Request: The request tokens do not match the user context. Do not copy the user context values (cookies; form fields; headers) between different requests or user sessions; always maintain the ALL of the supplied values across a complete single user flow. Failure Reasons:[Token values do not match;]

pdobsan commented 1 year ago

Followups at mailctl mailing list