OAuth redirection issue when oauth_login_redirect is set and authorization fails after successful authentication

[ksmolder]

In a setup using Roundcube (v 1.5.1) as a frontend to Dovecot (v 2.3.7.3) on Ubuntu 20.04, the follwoing behaviour can be seen when authenticating against Keycloak using OpenId Connect.

• Keycloak is currently set-up so that group memberships result in the inclusion of user attributes in the generated token. For example, when a user is a ember of the mail group, a mail-access attribute is included in the token with the value set to true.
• Dovecot's OAuth configuration is set to use the mail-access attribute as an authorization filter, meaning only users with the attribute included in the token and set to enabled will pass Dovecot's authentication/ authorization flow
• As only OAuth is meant to be used a the authentication mechanism for Roundcube, oauth_login_redirect is set to true.

Two users are created in Keycloak. One of them is a member of the mail group, the other isn't. When we navigate to the Roundcube login page, Roundcube properly redirects to the Keycloak login page as expected. When the mail user logs in, all works fine: the user gets authenticated, Keycloak redirects to Roundcube and Roundcube passes the generated tokens to Dovecot. As the tokens include the mail-access = true attribute/ value pair, Dovecot grants access and Roundcube opens the mail screen.

However, when we login with the Keycloak user who is not a member of the mail group, the following flow is triggered:

1. User opens Roundcube in browser
2. Roundcube redirects to Keycloak login page
3. User authenticates with Keycloak. This is successful as the user has a properly configured Keycloak account. The generated tokens do not include the mail-access = true attribute/ value pair as the user is not a member of the mail group.
4. Keycloak redirects to Rouncube
5. Roundcube passes the token to Dovecot
6. Dovecot validates the tokens but detects the missing mail-access attributes and authorization fails
7. Roundcube receives the S: A0002 NO [AUTHENTICATIONFAILED] Authentication failed. feedback from the server and concludes user authentication failed
8. Roundcube reopens the login page, but as oauth_login_redirect is set to true, Roundcube immediatly redirects the browser to the Keycloak login page
9. As the user is still authenticated in Keycloak, there's no reason for Keycloak to file up the login form. Instead, it reuses the existing session and redirects immediatly to Roundcube again with a valid token (that again, has no reference to the mail-access attribute included)
10. Roundcube forwards the token to Dovecot which again fails the authentication
11. ...

Eventually, this leads to the browser detecting a redirect loop. A not-so-fancy error is displayed stating the page isn't redirecting properly...

It seems that even when oauth_login_redirect is enabled, Roundcube would benefit from showing an intermediate page when IMAP authentication fails. This would break the redirect loop. It also makes it possible to display an error message to the user instead of having the user to figure out why the page isn't redirecting properly (while in fact, it is. It's just stuck in a loop).

When oauth_login_redirect is disabled, the user is guided back to the Roundcube login page and a toaster is displayed stating Authentication failed. When the user would try to login with the OAuth service again, step 9 will reoccur but that's the nature of OAuth and is not subject of this bug report.

[thomascube]

Indeed, the infinite redirect should be avoided and fixed in Roundcube.

However, you're setup might be improved in a way that Keycloak already rejects the login for a user who is not privileged for mail-access. Use the scope parameter in Roundcube's OAuth config to request access tokens with a particular permission required for email access as we already know that Dovecot will deny tokens for users missing a particular attribute.