Add XOAUTH2 Support Across Authentication Layers and Protocols

[xlmnxp]

This MR introduces XOAUTH2 authentication support to enhance security and modernize authentication workflows in Stalwart Mail Server. The implementation spans core directories (OIDC) and protocols (IMAP, POP3, Sieve and maybe others), enabling OAuth 2.0 bearer token authentication for services that require it.

Key Changes:

• Directory Authentication

  • Add XOAUTH2 validation logic to user directories
  • Support AUTH=XOAUTH2 mechanism in SASL authentication
  • Validate tokens against configured OAuth2 providers (OpenID Connect)

• Protocol Support

  • IMAP: Implement AUTHENTICATE XOAUTH2 (RFC 7628)
  • POP3: Add AUTH XOAUTH2 capability
  • Sieve: Enable XOAUTH2 for managesieve protocol
  • Generic framework for extending to other protocols (SMTP submission, etc.)

• Security Enhancements

  • Token validation with proper JWT signature checking
  • Automatic token expiration enforcement
  • Backward-compatible with existing auth mechanisms

• Configuration Notes:

  • Requires OAuth2 provider configuration in auth.toml
  • Supports multiple providers simultaneously
  • Compatible with OpenID Connect discovery

• Benefits:

  • Enables passwordless authentication flows
  • Supports modern email clients using OAuth2
  • Reduces dependency on cleartext passwords
  • Aligns with industry security best practices

[CLAassistant]

All committers have signed the CLA.

[rodrigorodriguez]

This will solve the https://stalw.art/docs/auth/backend/oidc#oauthbearer-sasl :

"Unfortunately, many mainstream mail clients, such as Outlook, Thunderbird, and Apple Mail, do not support this mechanism. As a result, users of these clients cannot directly authenticate using OAuth tokens."

[mdecimus]

This will solve the https://stalw.art/docs/auth/backend/oidc#oauthbearer-sasl :

Unfortunately it won't. Mail clients won't start an OAuth authentication flow with any third party mail server that is not Google or Microsoft.

[xlmnxp]

This will solve the https://stalw.art/docs/auth/backend/oidc#oauthbearer-sasl :

Unfortunately it won't. Mail clients won't start an OAuth authentication flow with any third party mail server that is not Google or Microsoft.

Works well with Jakarta Mai and we can authentic mobile and web clients using it without issue, I make sure to follow RFC and Specs so other clients work with it too

[rodrigorodriguez]

What Can Be Done?
Regulatory Action:

Governments and regulatory bodies could enforce stricter antitrust laws to promote competition in the email and OAuth space.

For example, requiring mail clients to support open standards or mandating interoperability between services.

Open Standards:

Encouraging the adoption of open standards for OAuth and email protocols could level the playing field for third-party providers.

Initiatives like OpenID Connect and OAuth 2.0 are steps in this direction, but broader adoption is needed.

User Advocacy:

Users can demand better support for third-party email services from mail client developers.

Supporting privacy-focused email providers (e.g., ProtonMail, Tutanota) can help create a more competitive market.

Decentralized Solutions:

Decentralized email protocols (e.g., based on blockchain or peer-to-peer technology) could reduce reliance on centralized providers like Google and Microsoft