RotherOSS / MailAccount-OAuth2

Enables receiving emails (IMAP and POP3) via OAuth 2.0 authorization (RFC 6749).
0 stars 4 forks source link

OAuth2 with Google Workspace: Missing required parameter: redirect_uri #1

Open micha2021 opened 2 years ago

micha2021 commented 2 years ago

Hi,

I tried to setup OAuth2 for Google Workspace.

I've installed in OTOBO 10.1.2 the package MailAccount-OAuth2 and customized the system settings.

During the configuration of the mail account (profile IMAOOAuth2) the connection to Google is successful but the API reports an errror:

https://accounts.google.com/signin/oauth/error?authError=...
Error 400: invalid_request
Missing required parameter: redirect_uri

It seems that Google requires the redirect_uri in the API call (https://developers.google.com/identity/protocols/oauth2/web-server) but OTOBO doesn´t submit it.

Cheers, Michael

svenoe commented 2 years ago

Hey Michael,

this plugin was originally developed and tested for Microsoft Azure, where it works. Google was added as an example to the config in the hope that it works out of the box, but if it doesn't we will definitely have a look at it. I cannot promise any date though, as at the moment we are quite busy with customer requests. In any case it doesn't look like a big change to me. I will bring it up.

Best regards, Sven

fred-cardoso commented 1 year ago

Hi,

This specific issue can be bypassed by passing the parameter on the Auth URL field. For example:

image

But after completing the authentication and being redirected back to the callback URL it prompts the login screen again and never really creates the account. I took a quick look at the code and it seems we never reach this point: https://github.com/RotherOSS/MailAccount-OAuth2/blob/master/Custom/Kernel/Modules/AdminMailAccount.pm#L348

im-alfa commented 7 months ago

Hi @svenoe!

I've been browsing OTOBO forum and it seems that the problem is common and no one has had any solution.

The issue is a bit old and I may have missed something, but do you have an update on this?

Thanks!

svenoe commented 6 months ago

Hi @im-alfa,

no, sorry, the situation is unchanged here, unfortunately. We are persistently packed with development requests of paying customers currently, and this has not been one of them, yet. (Generally this is an example where we are in a bit of a tricky situation, because the package was also a request, but specifically for Azure. When that is done we feel that it is nice to release those things publicly, even though they might not be totally generalized.)

We are aware that this feature is requested from time to time, so it is on the list of things to do.

Best regards, Sven

im-alfa commented 3 months ago

Hi @svenoe,

After a while I've decided to take up this topic again and I've managed to get it working. I tried to create a PR to help you, but my knowledge of the OTOBO/OTRS framework is very simple and I don't have time to get familiar with it :/

However, I thought it might be useful for you to know how I solved it so you can implement the solution faster:

Missing arguments in the auth URL

The authorization screen request is missing some parameters that are required by Google:

  1. redirect_uri=https://[FQDN]/otobo/index.pl?Action=AdminMailAccount
  2. access_type=offline
  3. prompt=consent

* 2 and 3 are needed for Google to return a refresh_token once it calls the /token endpoint.

Missing parameters in the body of the authentication token (subroutine _RequestAccessToken).

Google requires to include a redirect_uri in the payload, and this must exactly match where it comes from (in our case from https://[FQDN]/otobo/index.pl?Action=AdminMailAccount)

Fix the way the refresh_token is stored.

I have also used a patch that was implemented by Punamu already (#5)

Change the OAuth URLs to the current ones.

Again, I'm very sorry I couldn't create a PR. I started to do something, but I felt I was doing something very cursed and that is not the way OTOBO plugins should be coded. 😅

Remove the logic for refreshing the refresh_token

Google doesn't seem to return the refresh_token on the /token endpoint, so the logic in OAuth2.pm (see image below) is not needed and was blocking the fetching of a new access token.

image

Edit 1: I just realised that in the screenshot I have crossed out the ‘Insert new data’ section, be careful, do not delete this section as it will prevent the token from being inserted in the initial registration of the account.

Best,