500 error when connecting google oauth

Infos:

  • Used Zammad version: 4.0.0-13
  • Used Zammad installation source: docker-compose
  • Operating system: Ubuntu 20.04.2 LTS VM on proxmox
  • Browser + version: Vivaldi 3.7.2218.52 (Stable channel) (64-bits)

Expected behavior:

  • After completing the oauth process as described in the docs, adding the resulting keys to Zammad as described in step 5 and authenticating with Google, Zammad shows me my account so that I can add the gsuite inbox.

Actual behavior:

  • After authenticating with Google, Zammad gives me the message 500: We're sorry, but something went wrong.

Steps to reproduce the behavior:

  • Create OAuth consent
  • Create OAuth credentials
  • Connect new Google app in Zammad
  • Authenticate with Google
  • Receive 500 error

I also found Google Auth issue - "Message from google_oauth2: csrf_detected" which seems similar.
My installation is also NAT’ed and works through an external Nginx reverse proxy, though websockets and so on are turned on. It might not have anything to do with that though.

Any and all help to point me in the right direction would be much appreciated!

Same here and time of all my docker are correct :confused:

* today at 11:33:28 I, [2021-04-11T11:33:28.801644 #1-47459536396200] INFO -- : (google_oauth2) Callback phase initiated.
* today at 11:33:28 F, [2021-04-11T11:33:28.962953 #1-47459536396200] FATAL -- :
* today at 11:33:28 F, [2021-04-11T11:33:28.963087 #1-47459536396200] FATAL -- : JWT::InvalidIatError (Invalid iat):
* today at 11:33:28 F, [2021-04-11T11:33:28.963137 #1-47459536396200] FATAL -- :
* today at 11:33:28 F, [2021-04-11T11:33:28.963228 #1-47459536396200] FATAL -- : jwt (2.2.2) lib/jwt/verify.rb:48:in `verify_iat'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] jwt (2.2.2) lib/jwt/verify.rb:15:in `block (2 levels) in singleton class'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] jwt (2.2.2) lib/jwt/verify.rb:22:in `block in verify_claims'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] jwt (2.2.2) lib/jwt/verify.rb:20:in `each'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] jwt (2.2.2) lib/jwt/verify.rb:20:in `verify_claims'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] omniauth-google-oauth2 (0.6.1) lib/omniauth/strategies/google_oauth2.rb:68:in `block in <class:GoogleOauth2>'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] omniauth (1.9.1) lib/omniauth/strategy.rb:109:in `instance_eval'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] omniauth (1.9.1) lib/omniauth/strategy.rb:109:in `block in compile_stack'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] omniauth (1.9.1) lib/omniauth/strategy.rb:108:in `each'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] omniauth (1.9.1) lib/omniauth/strategy.rb:108:in `inject'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] omniauth (1.9.1) lib/omniauth/strategy.rb:108:in `compile_stack'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] omniauth (1.9.1) lib/omniauth/strategy.rb:102:in `extra_stack'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] omniauth (1.9.1) lib/omniauth/strategy.rb:344:in `extra'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] omniauth (1.9.1) lib/omniauth/strategy.rb:351:in `auth_hash'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] omniauth (1.9.1) lib/omniauth/strategy.rb:372:in `callback_phase'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] omniauth-oauth2 (1.7.0) lib/omniauth/strategies/oauth2.rb:93:in `callback_phase'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] omniauth (1.9.1) lib/omniauth/strategy.rb:238:in `callback_call'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] omniauth (1.9.1) lib/omniauth/strategy.rb:189:in `call!'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] omniauth (1.9.1) lib/omniauth/strategy.rb:169:in `call'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] omniauth (1.9.1) lib/omniauth/strategy.rb:192:in `call!'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] omniauth (1.9.1) lib/omniauth/strategy.rb:169:in `call'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] omniauth (1.9.1) lib/omniauth/strategy.rb:192:in `call!'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] omniauth (1.9.1) lib/omniauth/strategy.rb:169:in `call'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] omniauth (1.9.1) lib/omniauth/strategy.rb:192:in `call!'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] omniauth (1.9.1) lib/omniauth/strategy.rb:169:in `call'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] omniauth (1.9.1) lib/omniauth/builder.rb:45:in `call'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] rack (2.2.3) lib/rack/tempfile_reaper.rb:15:in `call'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] rack (2.2.3) lib/rack/etag.rb:27:in `call'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] rack (2.2.3) lib/rack/conditional_get.rb:27:in `call'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] rack (2.2.3) lib/rack/head.rb:12:in `call'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] actionpack (5.2.4.5) lib/action_dispatch/http/content_security_policy.rb:18:in `call'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] rack (2.2.3) lib/rack/session/abstract/id.rb:266:in `context'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] rack (2.2.3) lib/rack/session/abstract/id.rb:260:in `call'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] actionpack (5.2.4.5) lib/action_dispatch/middleware/cookies.rb:670:in `call'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] actionpack (5.2.4.5) lib/action_dispatch/middleware/callbacks.rb:28:in `block in call'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] activesupport (5.2.4.5) lib/active_support/callbacks.rb:98:in `run_callbacks'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] actionpack (5.2.4.5) lib/action_dispatch/middleware/callbacks.rb:26:in `call'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] actionpack (5.2.4.5) lib/action_dispatch/middleware/debug_exceptions.rb:61:in `call'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] actionpack (5.2.4.5) lib/action_dispatch/middleware/show_exceptions.rb:33:in `call'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] railties (5.2.4.5) lib/rails/rack/logger.rb:38:in `call_app'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] railties (5.2.4.5) lib/rails/rack/logger.rb:26:in `block in call'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] activesupport (5.2.4.5) lib/active_support/tagged_logging.rb:71:in `block in tagged'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] activesupport (5.2.4.5) lib/active_support/tagged_logging.rb:28:in `tagged'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] activesupport (5.2.4.5) lib/active_support/tagged_logging.rb:71:in `tagged'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] railties (5.2.4.5) lib/rails/rack/logger.rb:26:in `call'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] actionpack (5.2.4.5) lib/action_dispatch/middleware/remote_ip.rb:81:in `call'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] actionpack (5.2.4.5) lib/action_dispatch/middleware/request_id.rb:27:in `call'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] rack (2.2.3) lib/rack/method_override.rb:24:in `call'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] rack (2.2.3) lib/rack/runtime.rb:22:in `call'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] activesupport (5.2.4.5) lib/active_support/cache/strategy/local_cache_middleware.rb:29:in `call'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] actionpack (5.2.4.5) lib/action_dispatch/middleware/executor.rb:14:in `call'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] rack (2.2.3) lib/rack/sendfile.rb:110:in `call'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] railties (5.2.4.5) lib/rails/engine.rb:524:in `call'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] puma (3.12.6) lib/puma/configuration.rb:227:in `call'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] puma (3.12.6) lib/puma/server.rb:706:in `handle_request'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] puma (3.12.6) lib/puma/server.rb:476:in `process_client'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] puma (3.12.6) lib/puma/server.rb:334:in `block in run'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] puma (3.12.6) lib/puma/thread_pool.rb:135:in `block in spawn_thread'
* today at 11:33:28 [72837da0-1873-49bd-a051-ead5b459a616] logging (2.2.2) lib/logging/diagnostic_context.rb:474:in `block in create_with_logging_context'

Hello @sid thanks for your addition. Because we needed to move forward, I ended up using the ‘insecure access’ method to connect through IMAP/SMTP. But of course, it would be better to go back and move to oauth if we can figure out what is wrong.

My docker containers are also time-correct.

actually… shame on me ! My host was ~1 min late.
this error seems to be related to time only :confused:

We managed to fix this, but I am not entirely sure how. These were the steps:

  • We updated to VERSION=-4.0.0-20 using the .env
  • We did docker-compose pull before docker-compose down && docker-compose up -d to minimize downtime
  • We tried to add google again; it worked straight away! :astonished:

And a nice surprise: The SMTP channel was automatically migrated to the Google channel, that’s a really thoughtful and helpful detail.

So it was either the update to 4.0.0-20 or it was something in the docker-compose setup for the previous version.

But either way it works now :tada:

Sadly, we just ran into the exact same problem again.

We had to change the existing Google Account, so the exact same installation.
However, when adding the new google account, we again see the 500 error.
Of course, we tried the steps that did work before, but they are not helping this time :frowning_face:

This also means that whatever is causing it, is not fixed for us sadly.

Does anyone have an idea what might be wrong?

again same here… i worked from 2 days and not anymore.
Any idea ?

We set up this account again using the ‘less secure app’ option.
Sadly, we have been unable to get oauth working like before.
This is not a solution, but a workaround.

Strongly sounds like you’re running a test app there.
This is not working because credentials are reset regulary and thus the google channel no longer is working.

Please note that the documentation you provided is about the google channel, not google authentication and thus is about 2 different things. I’m mentioning this, because log files mention google_oauth2 which is not part of the google channel but the authentication.

You may talka bout different things because @Floris actually is mentioning the “less secure app” setting which is a workaround for using google email accounts with password.

Please be careful with wording other wise we may run into dead ends.

Thanks for your assistance.
On my side, we are talking about third-party google which allow us to authenticate users via Google.
https://admin-docs.zammad.org/en/latest/settings/security/third-party/google.html

On this base, can you please confirm this feature works well ?
Could you please explain “This is not working because credentials are reset regulary and thus the google channel no longer is working.” ?

hello @MrGeneration thank you for your reply.
Indeed, as I wrote in my original post, we simply want to get mail from a gsuite inbox into zammad as tickets.

A short recap:

  • We were unable to add a gsuite inbox into Zammad, continually hitting the 500 error.
  • Then, adding the google channel somehow did work after updating to 4.0.0-20 though nothing else had changed.
  • However, some days later we had to change the connected channel, which lead to the same problem we had initially.
  • As a work around, we again set the less secure app setting so that we could pull mail into zammad, but we view that as a temporary setup.

Your point about a public test oauth app is understood, we also tried a different google cloud platform account (different domain) to create an external public test app and the oauth setup displayed a warning that it is not a persistent setup or something along those lines.

That only serves to confirm that the connection need to be made from either a verified external (public) oauth app (the process for wich we could go through if it really helps) or an internal oath app.

Unfortunately, neither the internal oauth nor the external testing oauth worked for us getting a gsuite mail account connected through the Google Channel.

Zammad does not require an authenticated app to function with the google channel at all.
Following the documentation should be good enough to reach the goal - during documentation and verification process I didn’t do anything different, pinky promise:
https://admin-docs.zammad.org/en/latest/channels/google/accounts/register-app.html


@sid sorry I’m getting confused and have issues to follow two topics in the same thread.
Floris is having issues with the google channel, you’re with the authentication. That’s two different parts. If you still struggle, I think it would be best to create a new thread for better overview.

I’m currently not aware of any issues with either google channel or google authentication.

Appreciate your feedback !
Indeed i have an issue with authentication… " 500: We’re sorry, but something went wrong." and "JWT::InvalidIatError "
I will open a new thread ! Thanks.

Note: Google Channel works fine for me ^^

1 Like

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.