21. 12. 2023
Development, DevOps
23. 05. 2022
Mirko Morandini
Cloud, Service Management
Office365/Google Mail Users: Migrate Your EriZone/OTRS Mail Accounts to OAuth2 Authentication NOW!
Both Microsoft and Google will terminate within summer/autumn 2022 the possibility of accessing POP and IMAP mailboxes using usernames and passwords!
In the course of the year 2022 Microsoft and Google will terminate support for Basic Auth (the authentication with username and password) for some web services and pass to a more secure method, often called “Modern Authentication”, which implements the OAuth 2.0 protocol. Specifically, they will disable basic authentication for the POP and IMAP protocols (to receive mail), while the mail sending protocol SMTP will still keep supporting “traditional” authorization.
The announcements:
Microsoft
In their latest communication on 31/03/2022 they remark that “In September 2021, we announced that effective October 1, 2022, we will begin disabling Basic authentication for Outlook, EWS, RPS, POP, IMAP, and EAS protocols in Exchange Online”: https://techcommunity.microsoft.com/t5/exchange-team-blog/basic-authentication-and-exchange-online-september-2021-update/ba-p/2772210
If you’re using Google Workplace, you may have gotten an email last month, saying “To help keep your account secure, starting May 30, 2022, Google will no longer support the use of third-party apps or devices which ask you to sign in to your Google Account using only your username and password”.
Read it here: https://support.google.com/accounts/answer/6010255
So, what does this mean in practice? Personally, you may need to re-configure your mail clients that use these protocols on your desktop and on your phone. But don’t forget to keep an eye on various business applications that need to send and receive mails!
OAuth2 with EriZone and OTRS
We provide an OAuth2 plugin for EriZone and OTRS, which supports the IMAP and IMAPS mail access protocols, compatible with OAuth2 for both Azure and Google. Please contact our Service Management consultants, which will also support you in the setup of the identity provider.
Benefits of the OAuth approach
- Your 3rd party application is able to log in to “classic” services without having to pass along a username and password
- The authorization is performed (in simple words) with a token obtained from the Identity Provider after a first interactive login on the Identity Provider’s login page (e.g., your company-specific Microsoft login portal). This is the only time that a password needs to be entered.
- It’s possible to limit the access that the application has to specific information
- It’s possible to revoke this specific token at any time without having to deactivate users or to invalidate passwords.
Activating OAuth for your application on the Microsoft Identity Platform (Azure AD):
To use the OAuth 2 authentication with Azure, the application that needs mailbox access must be registered within the Microsoft Identity Platform. To do this, log in to the Azure portal, and in the Manage menu of the Azure Active Directory of your tenant, select App registrations > New registration. Here you define a display name for the application, you select who can sign in, and you define the application-specific redirect URI to where tokens will be sent after a successful authentication, in our case e.g. https://servicedesk.xy.com/erizone/index.pl?Action=AdminMailAccount. After completing this registration, on the overview page you’ll see the new application ID, which is needed by your application to start the authorization workflow.
Now you need to obtain a credential specific to this app. In the “Certificates and secrets” section of the app registration, you can either upload a public key certificate, or generate a client secret. The OTRS OAuth plugin works with client secrets. The secret generated in this section is visualized only once, can be revoked at any time and has a maximum validity that can be set to no more than 24 months. Copy it, store it in the application and don’t keep it anywhere else. If you lose it, simply create a new one.
This is everything needed on the side of the Azure Portal. When you configure OAuth in EriZone, you will be directed to your company’s Azure login page where you’ll need to enter the credentials of the mailbox. Administrators can also log in with their credentials if they have access to the mailbox. However, this currently seems to work only with cloud accounts and fails with synchronized accounts.
Technical implementation details
Technically speaking, the Microsoft and Google implementations of IMAP, POP and SMTP now support the authorization command XOAUTH2, passing the Base64 encoding of the mailbox username and the token previously obtained, in the following format: base64("user=" + userName + "^Aauth=Bearer " + accessToken + "^A^A")
https://login.microsoftonline.com/<tenant_id>/oauth2/v2.0/authorize client_id=<application_id> response_type=coderedirect_uri=http://xy.com/otrs/... response_mode=query scope=openid offline_access https://graph.microsoft.com/mail.read state=<randomvalue>
This call redirects to the identity provider that in practice, in our case, is the company login page on microsoftonline.com. Here, you need to log in with the username and password of the mailbox or alternatively, if it’s a shared mailbox, with a user that has complete access to it. After a successful authentication, the identity provider returns a response to the indicated “redirect URI” which contains the state value defined in the original request (for verification, to prevent cross-site request forgery attacks) and an authorization code.
This authorization code (which is only valid for several minutes) is then used by the client application, together with the client secret previously generated on the Azure Portal, to request an access token, with a PUSH-request to https://login.microsoftonline.com/<tenant_id>/oauth2/v2.0/token
If this call is successful, the response contains two tokens: the access token with a short time-to-live that can be used for authentications of the application to some service (e.g. IMAP) without having to pass the username and the password; and a refresh token. This refresh token is saved in the OTRS DB and needs to be used to get a new access token each time the current one is expired.
The EriZone/OTRS Mail account OAuth2 plugin implements these steps for IMAP and IMAPS access to mailboxes and should in principle work with every OAUTH2-compatible identity provider. However, there are several differences in the OAuth2 implementations by Microsoft and Google.
For further details read https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-auth-code-flow. For Google OAuth, some different parameters are needed, which are described e.g. here: https://developers.google.com/identity/protocols/oauth2/native-app. Our plugin is already compatible with Google OAuth.
These Solutions are Engineered by Humans
Did you learn from this article? Perhaps you’re already familiar with some of the techniques above? If you find security issues interesting, maybe you could start in a roles like this as well as other roles here at Würth Phoenix.
Mirko Morandini
Mirko Morandini, PhD, is part of the EriZone team since 2015. As a consultant, he guided the implementation of EriZone in various projects in the DACH area and in Italy.
Author
Latest posts by Mirko Morandini
14. 12. 2023
Service Management
EriZone Servicedesk: Upgrade to RockyLinux9/RHEL9 (CentOS7 EOL in June 2024)!
06. 12. 2023
Asset Management, Service Management
Würth Phoenix is a GLPI Gold Partner! Exclusive News from GLPI Partner Day
04. 01. 2023
Asset Management, Unified Monitoring
Using GLPI with the Metabase Open Source BI Tool for Visualizing Rich Reports and Dashboards