SMTP Oauth authentication error (Azure)

[gabrielgbs97]

Code of Conduct

• I agree to follow this project's Code of Conduct

Is there an existing issue for this?

• I have searched the existing issues

Version

10.0.15

Bug description

TL;DR: smtp username might not be the same as email, and SMTP XOAUTH2 flow will fail. GLPI would autodisolver this using UPN, or populated by user in frontend, like it is done with SMTP Auth (BASIC)

https://forum.glpi-project.org/viewtopic.php?id=291362

GLPI 10.0.15, On-prem AD, and Entra ID Synchronized

Our support account’s username and primary SMTP address are not the same. I logged in successfully via browser, but then test SMTP fails.

I tested the equivalent configuration (SMTP+OAUTH) with my individual company user account, which has identical UPN and email, and it worked successfully. This corner case is handled correctly by GLPI SMTP AUTH (Basic), where you can specify login and email information separately. However, it seems that SMTP OAUTH might be using the email as the username (i.e. UPN), which would be incorrect.

If this is reproduced, it will be an issue for a lot of users when migrating to SMTP OAUTH this fall. If this is a no-fix, docs will have to be updated to require UPN and email to hold the same value.

For example: https://github.com/glpi-project/glpi/blob/main/front/smtp_oauth2_callback.php

            if ($is_email_valid && $is_token_valid) {
                Config::setConfigurationValues(
                    'core',
                    [
                        'smtp_username'            => $email, # smtp_username may mismatch email!
                        'smtp_oauth_refresh_token' => $refresh_token,
                    ]
                );
            }

From the code above, the refresh_token will be correct, but smtp_username may not, as in our case. Here’s an example of a message exchange between a client and an SMTP server using OAuth 2.0 for authentication. In this scenario, the UPN is [email protected], the email address is [email protected], and the OAuth access token is AAAA:

C: AUTH XOAUTH2 dXNlcj1zdXBwb3J0Lml0QGNvbnRvc28uY29tAWF1dGg9QmVhcmVyIEFBQUEBAQ==

The base64-encoded string is:

[email protected]^A
auth=Bearer AAAA^A^A

Here user needs to be the id (UPN in Azure) and not email. Another openid field that may work is preferrred_username, still don't know if it contains org '@contoso.com'.

Relevant log output

Page URL

No response

Steps To reproduce

You may try to set up SMTP+OAUTH mail with an Azure account like:

user (UPN): [email protected]
primary email: [email protected]
(we still had [email protected], UPN, as secondary email/alias)

Your GLPI setup information

No response

Anything else?

No response

[cedric-anne]

Hello,

I think this FAQ article might help you configure your alias with SMTP + OAuth :
https://faq.teclib.com/02_FAQ/Notifications_and_receivers/#is-it-possible-to-use-a-different-account-for-the-sender-of-the-message-and-oauth-smtp-authentication-with-google-or-entra

[gabrielgbs97]

From FAQ:

Is it possible to use a different account for the sender of the message and OAuth SMTP authentication with Google or Entra?"#
No. The account used for OAuth authentication must also be the sender of the message. Sending the email will fail if the accounts are not identical.
Alias
There is, however, a nuance for aliases with OAuth + SMTP. Sending mail with an alias is possible with the following configuration:
indicate the main user in Setup > Notifications > Email followups configuration
then enter the alias in Email sender (in the and e-mail notifications mail server insert)

Account is the same, there is only one, BUT id (for auth) and email are not the same string. I am not trying to send email with an alias, it is the main email (it differs from user id). Wording may be improved, maybe in a separate issue. Anyways, the assumption that email and user id is the same, is plainly wrong. What we have now is little confusing (according to my asumptions and code review):

• UX asks for 'Sender email' (and other fields), Oauth flow is initiated when save button is pressed.
• GLPI backend still retrieves 'email' from OpenID (access_token?), it will store and use this field for SMTP XOAUTH2 flow. (I think, that's the main flaw in this history). Note: If I put actual user id as 'Sender email' in UX it still fails, that's because GLPI uses 'email' from OATH token statically.
• IF auth succeeds, GLPI will use 'Sender email' field to send the message in SMTP.

Asking both 'smtp_auth_id' and 'smtp_email' (field names are for ilustration purposes) like SMTP Basic integration alreadydoes, issue would be fixed 'easily'. A compatible fix with current implementation:

1. Ask smtp_email ('Sender email'), this is done already.
2. Ask for smtp_auth_id, this will be used as user id in SMTP XOAUTH2 flow. This field will be optional, if left blank/null backend will extract 'email' from access_token as it currently does.

Today just checked Microsoft Entra ID docs/guidance, and it matches my recommendation:

https://learn.microsoft.com/en-us/entra/identity-platform/id-token-claims-reference

Claim	Format	Description
email	String	Present by default for guest accounts that have an email address. Your app can request the email claim for managed users (from the same tenant as the resource) using the email optional claim. This value isn't guaranteed to be correct and is mutable over time. Never use it for authorization or to save data for a user. If you require an addressable email address in your app, request this data from the user directly by using this claim as a suggestion or prefill in your UX. On the v2.0 endpoint, your app can also request the email OpenID Connect scope - you don't need to request both the optional claim and the scope to get the claim.

Still, if the decision is a 'no fix' I would:

• Improve wording in FAQ. Can help there, but I think it is not a community-enabled doc.
• Warn about this case in GLPI SMTP Oauth (Entra) doc. (https://faq.teclib.com/03_knowledgebase/notifications/OAuth_smtp_entra/#adding-claims). This is protocol specific and it is more useful here.
• Cases like mine that are working with SMTP Auth (Basic) will be impossible to migrate smoothly when Basic auth shuts down as stated by EntraID roadmap. Another mail account will be needed or modifying the current one with a certain risk.