Google Mail IMAP response with padding makes auth parse error

[Abdillah]

Google responded to XOAUTH2 authentication with this base64 string with padding format (==),

S: + eyJzdGF0dXMiOiI0MDAiLCJzY2hlbWVzIjoiQmVhcmVyIiwic2NvcGUiOiJodHRwczovL21haWwuZ29vZ2xlLmNvbS8ifQ==

When I use online base64 tool, it reveals this text:

{"status":"400","schemes":"Bearer","scope":"https://mail.google.com/"}

The library unfortunately using base64::engine::general_purpose::STANDARD_NO_PAD that unable to parse the response and surfaced the error as error authenticating: Unable to parse authentication response.

[jonhoo]

Oh interesting — @soywod do you have more insight into this one? Should we switch which base64 engine configuration we use?

[Abdillah]

The response above specifically when failing the authentication. I haven't encounter any other encoded string.

The padding also exists (albeit in client request) in an official documentation:
https://developers.google.com/gmail/imap/xoauth2-protocol

[soywod]

Oh interesting — @soywod do you have more insight into this one? Should we switch which base64 engine configuration we use?

I can only say that imap-codec uses the STANDARD engine, and that I have no issue at app level to decode XOAUTH2 error. For which reasons imap uses the STANDARD_NO_PAD engine?

[juul-vandevelde]

I encountered the same issue while trying to authenticate using Microsoft's IMAP with OAuth2. Here’s a bit of context:

Initially, I was using imap v2.4.1 (stable release) and everything worked fine. However, I received a warning about imap-proto v0.10.2 being deprecated, as discussed in #297. This led me to update my code to use imap = "3.0.0-alpha.14".

After refactoring my code to work with the alpha version, I encountered the following error when trying to authenticate: AUTHENTICATE failed

This was strange because the exact same code was working fine with version 2.4.1.

After reading through the discussion in this issue, I decided to test removing the == padding at the end of the OAuth2 token. To my surprise, this solved the problem, and I was able to authenticate again without any issues.

It seems that Microsoft's OAuth2 token also includes the padding (==), which causes the authentication to fail ...

Hope this helps!

[jonhoo]

Huh, interesting, I genuinely couldn't tell you why I landed on NO_PAD. Not for any good reason I don't think. Fixing in #305, thanks for digging!

[jonhoo]

Released in alpha.15 !