Why GLPI email-to-ticket needs OAuth for Microsoft 365 and Gmail
If your GLPI mail collector stopped fetching mail after Microsoft 365 or Google changed how IMAP accounts sign in, the fix is the OAuth IMAP plugin, configured with an Entra app registration or a Google client. The collector keeps its existing role in email-to-ticket, but it stops relying on a username and password and instead authenticates with an OAuth token. Microsoft is removing TLS 1.0 and 1.1 for Microsoft 365 applications, which is the change that breaks older collector configurations. The plugin's documentation lists Gmail and Entra as its supported mail services, so those are the two providers this page covers.
The plugin works by requesting tokens from the provider on behalf of a mailbox that GLPI reads. According to the plugin documentation, the tokens it retrieves are offline tokens with a renewal code, so GLPI renews them automatically after the first authorization and does not ask a user to sign in again. That changes the operational question. The risk is less about daily login and more about the initial consent: confirm which account owns the mailbox, which permissions the app requests, and who is allowed to perform the first authorization. Also confirm that the mailbox is not protected by a policy that blocks third-party app consent, because a blocked consent will look like a collector failure in GLPI.
Before you change anything, record the current collector settings, the mailbox it reads, and the error shown in the collector logs, so you can confirm the fix against a known baseline. Then check the current IMAP and OAuth requirements with Microsoft and Google directly, since provider policy changes on their own schedules. The GLPI OAuth IMAP plugin documentation is the natural next read for the exact client setup steps. Plan a test mailbox first, and treat the first successful ticket creation from a real message as the acceptance test.
What you need before configuring the OAuth IMAP collector
Most failed mail collector setups trace back to a missing prerequisite rather than a wrong setting. The cards below cover the GLPI platform, the plugin, the mailbox identity, the tenant or workspace rights and the network path that have to be in place before you open the collector form.
GLPI version, PHP and database
Confirm your GLPI build and its runtime before anything else. The installation docs list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 for GLPI 11.0, while the GLPI README on the main branch lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later. Use the stricter requirement for the version you actually run, and note that only MySQL and MariaDB are supported.
Plugin installation and activation
Install the OAuth IMAP plugin into the GLPI plugins directory, then activate it from the plugin administration screen. Confirm compatibility with your exact GLPI 11 build in the plugin documentation before you install, since a plugin that does not match the core version will not run reliably. Plan to reactivate plugins after any major update, because GLPI 11 suspends them when a new version is detected.
Mailbox owned by a service identity
Use a shared or service mailbox, such as a helpdesk address, rather than a personal account. A personal mailbox ties ticket intake to one employee's leaving date, password changes and mail rules. Confirm that the mailbox is licensed, that its folders and retention meet your helpdesk process, and that the people who will receive ticket replies can see it.
Admin rights in Entra or Google Workspace
Identify who can register an application in Microsoft Entra ID or create and configure a client in Google Cloud for your Workspace tenant. Entra app registration and consent for mail permissions usually need an administrator role, and Google client setup depends on your Workspace administration settings. Agree that person's role before the change window, because the collector cannot be authorized without it.
Callback URL reachable from GLPI
The OAuth redirect must return to your GLPI server, so the public URL you configure in GLPI has to match the callback registered with Microsoft or Google exactly. Check that the GLPI server can reach the provider's token endpoints outbound and that your reverse proxy passes the callback path through. A mismatch between http and https or a trailing slash is a common cause of rejected sign-ins.
How to register the app and configure the mail collector step by step
This sequence moves a Microsoft 365 or Gmail mailbox from basic authentication to an OAuth connection that GLPI renews on its own. Each step ends with a check you can record, so the setup can be reviewed and handed over.
Install and activate the OAuth IMAP plugin
A GLPI administrator installs the OAuth IMAP plugin on the GLPI instance, following the plugin documentation. Before installing, confirm that the plugin version supports your GLPI release, since GLPI 11 and later suspend plugins when it detects a new version. Activate the plugin from the plugin list. You know this step is done when the plugin shows as active and its configuration page opens without errors.
Register the Entra app or Google OAuth client
For Microsoft 365, a Microsoft Entra administrator registers an application for the tenant that owns the mailbox. For Gmail, a Google Cloud administrator creates an OAuth client for the project that will be used for the mailbox. Confirm the account type and consent settings with the plugin documentation before you register anything. Record the application or client identifier and the tenant details in your configuration record. The step is complete when the registration appears in the admin console with its identifier.
Set redirect URIs and IMAP permissions
Add the redirect URI shown on the plugin configuration page to the app or client registration. The URI must match the address users reach GLPI at, character for character, including the scheme and path. Then grant the IMAP mail permissions the plugin documents. Microsoft tenants usually need an administrator to grant consent for these permissions. The check is that the redirect URI in the registration matches the plugin page exactly and that consent shows as granted for the required permissions.
Create the client secret and record its expiry
Create a client secret in the Entra app registration, or the equivalent credential for the Google client, and copy the value when the console displays it. Enter the value into the plugin configuration and store the original copy in your approved secrets store. Record the expiry date and name a owner in your renewal calendar or ticket queue, because an expired secret stops the connection even when the tokens are valid. The check is that the secret is saved in the plugin, the expiry date is written down, and the owner has been named.
Authorize the mailbox once
Start the authorization from the plugin configuration and sign in with the mailbox account the collector will read. Approve the requested consent. The plugin receives offline tokens with a renewal code, and GLPI uses them to renew access without asking anyone to sign in again after this first authorization. Sign in with the mailbox itself rather than an administrator account, so that the connection belongs to the mailbox. The check is that the token appears as stored on the OAuth connection for that mailbox.
Point the mail collector at the OAuth connection
Open the mail collector in GLPI and change its authentication from password to the OAuth connection you created. Confirm the IMAP server, port and encryption settings against the plugin documentation and your provider's current requirements. Run the collector manually against a test message sent to the mailbox. The check is that the test fetch completes without authentication errors and the test message is created as a ticket with the expected requester and content.
How offline tokens keep collectors running without re-authentication
The OAuth IMAP plugin stores offline tokens with a renewal code, so after the first authorization GLPI can renew its access token on its own and keep polling the mailbox without asking a user to sign in again. That first consent is the only interactive step. Everything after it depends on the grant staying valid at the identity provider, which is why the collector can run for long periods without attention and then stop abruptly when something upstream changes. Plan the first authorization as a deliberate act by an account that will still exist and hold the right permissions when the collector is in production, not as a setup step done by whoever is available that day.
Several changes on the provider side will break renewal even though GLPI itself has not changed. Revoked consent, a disabled or deleted user account, and a password reset that your tenant's policy treats as invalidating existing sessions can all end the grant. A client secret that has expired on the Entra app registration or a removed mailbox permission will also cause the next renewal to fail, and the collector will report errors on the next run rather than at the moment of the change. Assign ownership of the authorizing account, track the client secret expiry date, and review the mailbox permission whenever the mailbox is moved or its access model is changed.
Token lifetime and revocation behavior depend on your tenant's configuration, including conditional access, session controls and any refresh token policies your administrators have set, so do not assume the default behavior applies to your organization. Ask your Microsoft 365 or Google Workspace administrators to confirm how long the offline grant stays valid under your policies and what triggers revocation. Then check the GLPI OAuth IMAP plugin documentation against your chosen provider and run a test of the renewal path before go-live, so you know what a failed renewal looks like in your logs.
Which mailbox, server and identity settings map to which GLPI fields
This table maps each mailbox, server and identity setting to the GLPI collector, OAuth connection or notification field it feeds. Read it before you create the collector so the mailbox address, the authenticated account and the sender identity match. Exact labels vary by GLPI and plugin version, so confirm them in your own instance.
| Setting | Where it lands in GLPI | What to confirm |
|---|---|---|
| Mailbox address | Collector login or target address on the mail collector | Use the shared support mailbox that receives requests, not a personal account |
| Microsoft 365 IMAP host and port | Collector server string for Microsoft 365 with OAuth IMAP | Confirm the host and port listed in the plugin documentation for your tenant setup |
| Gmail IMAP host and port | Collector server string for Gmail with OAuth IMAP | Confirm the host, port and security mode against the plugin documentation |
| Authenticated identity | OAuth connection tied to the account that completed consent | Must be the same mailbox the collector reads, or access will fail or read the wrong folder |
| GLPI entity | Entity that receives tickets created from the collector | Choose the entity before creating the collector, since moving it later changes ticket ownership |
| Default ticket category | Category applied to tickets created from incoming mail | Pick a category that routing rules can refine, and confirm the field name in your version |
| Notification sender address | From address used for OAuth SMTP notifications | Usually the same mailbox or an alias the tenant allows to send, so check send-as permissions |
| OAuth consent and renewal | Stored offline token that GLPI renews without re-authentication | Confirm the first authorization was completed by the intended account and is not an administrator's personal login |
Entra app registration compared with Google client setup
The Microsoft side is an app registration in Microsoft Entra ID, created in the tenant that holds the mailbox the collector will read. The registration gives the OAuth IMAP plugin an identity to present to Microsoft, and the plugin then requests mail access on behalf of a signed-in account. Plan this with the Microsoft 365 administrator, because they control who can create registrations and whether consent is granted by a user or an administrator.
- Application identifiers: Record the application (client) ID and the directory (tenant) ID from the registration overview. The plugin asks for both during configuration.
- Redirect URI: Register the exact callback address that the plugin shows for your GLPI base URL, using the web platform. A single character mismatch causes the sign-in to fail before any mail is read.
- Delegated mail permissions: Add the delegated IMAP and offline access permissions named in the plugin documentation, and confirm with the plugin documentation whether admin consent is required for your tenant.
- Client secret: Create a secret, copy its value once, and store it in your secrets management system. Record the expiry date in your renewal calendar, because an expired secret stops every collector that uses the registration.
- Expiry tracking: Confirm the maximum secret lifetime your tenant policy allows and assign an owner to the renewal task.
Before testing a collector, confirm the redirect URI, the consent state, and the secret expiry date together.
The Google side is an OAuth client in a Google Cloud project, with a configured consent screen that tells the signed-in account what access it grants. The OAuth IMAP plugin uses that client to obtain mail access for a Google Workspace or consumer Gmail account. Most of the decisions sit with the Google Workspace administrator, so agree them before the project is built.
- Project and client: Create or choose a Google Cloud project and create a web application OAuth client. Register the callback address the plugin displays, exactly as shown.
- Consent screen: Configure the OAuth consent screen with the application name and the support contact. Add the Gmail scope that grants IMAP access, and confirm the scope name in the plugin documentation.
- Publishing status: Check whether the app is in testing or production status. Restrictions on which accounts can authorize differ by status, so confirm the current Google rules before relying on either.
- Workspace controls: Ask the Workspace administrator whether third-party app access is allowed for the organizational unit that holds the mailbox, and whether an admin-trusted app list applies.
- Mailbox ownership: Decide which account will sign in for the collector. Shared service mailboxes need a named owner who can re-authorize if the account changes.
Before testing, confirm that the scope, callback address, and Workspace access settings match what the plugin requests.
Both providers require the same two decisions: which account signs in, and who keeps the credentials working afterward. The tables differ, but the administrative work is similar in each tenant. Write the responsibilities down per provider so that a credential renewal or a mailbox change does not stop ticket intake.
- Microsoft 365 administrator: Creates the app registration, grants any required consent, creates and renews the client secret, and tracks its expiry date.
- Google Workspace administrator: Decides whether third-party app access is permitted for the mailbox's organizational unit and reviews the OAuth client's consent configuration.
- Google Cloud project owner: Holds the OAuth client and the consent screen, and should be a named role rather than a personal account where possible. Confirm this with your access policy.
- GLPI administrator: Enters the client identifiers and secret into the plugin, sets the collector to use the OAuth method, and tests sign-in after each change.
- Mailbox owner: Completes the first authorization and re-authorizes if the account password, sign-in method, or access policy changes.
Ask each administrator to confirm their item in writing, and set the Microsoft secret expiry date and any Google re-authorization steps as recurring reminders.
Sending GLPI notifications through OAuth SMTP
Outbound notifications can use SMTP with OAuth instead of basic authentication, and the same provider rules that govern the mail collector apply to them. GLPI sends notifications for ticket creation, follow-ups, approvals and reminders through its own SMTP configuration, so the mailbox that sends those messages needs its own identity, its own permissions and its own credentials. Keep the inbound and outbound paths separate in your planning: the collector reads a mailbox over IMAP, while the SMTP path submits messages on behalf of a sending account. A broken collector stops tickets from being created, but a broken SMTP path silently stops people from hearing about the tickets they already have.
Before you configure anything, confirm which mailbox GLPI will send from and which app registration or Google client will hold the send permission for it. Microsoft 365 and Gmail each have their own consent, scope and client secret behavior, so the reader should check the current requirements with the provider rather than reusing the settings from the collector. Record who owns the app registration, when the client secret expires and who receives the warning before it does. An expired secret stops outbound mail without any error in GLPI's ticket view, which makes the expiry date a monitoring item, not an afterthought.
The detailed configuration for the OAuth SMTP path, including the Entra app registration, callback URL and client secret expiry, is covered in its own sibling topic. Read that page before you change the production SMTP settings, and test notifications from a non-production entity first. Ask your mail administrator whether outbound sending is restricted by transport rules or sending policies, since those controls can reject GLPI messages even when the OAuth flow succeeds.
Securing the service identity and OAuth client
The OAuth client and the mailbox it reads are the keys to every ticket that arrives by email, so they deserve the same care as an administrator account. The cards below cover how to scope the identity, store and rotate its secret, review what it can reach, and protect the GLPI encryption keys that the mail collector configuration depends on.
Dedicated service mailbox
Create a mailbox used only by GLPI for the collector, rather than pointing it at a shared support inbox or a person's account. A dedicated mailbox limits what the collector can read, makes audit logs easy to filter, and survives staff changes. Confirm with your mail administrator whether the mailbox needs a licence and how it will be monitored for sign-in failures.
Least-privilege mailbox access
Grant the application access only to the mailbox the collector reads, not the whole tenant or every mailbox in the domain. On Microsoft 365, ask whether an application access policy can restrict the Entra app to specific mailboxes, and on Google Workspace, confirm which access the Gmail scope gives to a single account. Write the chosen boundary into the change record so reviewers can test it.
Restricting the app to required scopes
Request only the mail read and send permissions the collector and OAuth SMTP notifications need, and avoid broad directory or full mailbox permissions added for convenience during testing. Remove any permission that was added while troubleshooting. Recheck the scope list after every plugin upgrade, because a new release can request something different.
Storing the client secret in a vault
Keep the Entra client secret or Google client secret out of tickets, wiki pages and shared spreadsheets, and put it in a managed secrets store such as OpenBao or your existing vault. Restrict read access to the people who maintain GLPI and the host that runs it. Ask who can view the secret in the GLPI configuration screen and whether that access is logged.
Tracking secret expiry
Entra client secrets expire on a date you choose at creation, and an expired secret stops every collector and notification that uses it without a clear error in GLPI. Record the expiry date in your calendar or monitoring system and set a reminder well before it. Plan the replacement secret and the cut-over window in advance so the collector does not stop during business hours.
Reviewing consent grants
Review the consent grants and enterprise application entries in your identity provider on a schedule, and remove any consent granted to an app that no longer has a GLPI collector behind it. Check that the consent was given by an administrator who understands the scope, and that the redirect URI still points to your GLPI host. Ask your identity team how these reviews are recorded for audit.
Protecting GLPI encryption keys
Back up glpi.key and glpicrypt.key together with the database and the config directory, because GLPI cannot read values it encrypted without the keys that match them. Store the key backups under the same access controls as the database backup, and keep them out of the web root. Test a restore on a non-production host to confirm the stored OAuth credentials decrypt correctly.
Why a Microsoft 365 or Gmail collector stops fetching mail
This table lists the failures that most often stop an OAuth IMAP mail collector in GLPI, with the cause tied to how the plugin and the provider behave and the first fix to check. Read it from the top when a collector shows no new messages, and confirm each item against your own tenant or Google project settings before changing anything.
| Failure | Likely cause | First fix to check |
|---|---|---|
| Collector still uses the password | The mail collector was not switched to the OAuth IMAP authentication method, so GLPI keeps attempting basic authentication that the provider no longer accepts for these mailboxes. | Edit the collector and confirm the OAuth authentication option is selected before retesting the connection. |
| Wrong redirect URI | The redirect URI registered in the Entra app or Google client does not match the callback URL the OAuth IMAP plugin sends, so the authorization step fails or returns to an unexpected address. | Copy the callback URL from the plugin configuration exactly, including scheme, host and path, and register that value on the provider side. |
| Missing IMAP permission | The app registration or Google client lacks the mail access scope the plugin requests, so tokens are issued without permission to read the mailbox over IMAP. | Review the API permissions granted to the app and confirm the IMAP access scope is present and consented. |
| Expired client secret | On Microsoft 365 the client secret in the app registration has an expiry date, and once it passes the plugin can no longer obtain or renew tokens. | Check the secret's expiry in the Entra app registration, create a new one, and update the plugin configuration before the old value lapses. |
| Consent revoked or not granted | A tenant administrator or the mailbox owner withdrew consent, or consent was never granted for the app, so token requests are refused. | Re-run the authorization from the plugin for the affected mailbox and confirm the administrator consent state in the provider console. |
| Mailbox policy blocks the app | Tenant policies such as conditional access, app access restrictions or Google Workspace admin controls can block the application from reading the mailbox even when consent exists. | Ask the Microsoft 365 or Google Workspace administrator to confirm that policies allow this app and the account to access IMAP. |
| TLS errors on older clients | Microsoft is removing TLS 1.0 and 1.1 for Microsoft 365 applications, so an IMAP connection from an older server or PHP stack can fail during the handshake. | Confirm the GLPI server's TLS library and PHP build support TLS 1.2 or later, then test the collector again. |
| Tokens not renewing after a password change | The plugin stores offline tokens with a renewal code after the first authorization, so a password change or sign-in policy change can invalidate that grant and require a new authorization. | Re-authorize the collector from the plugin after the password change and document the step in your operations runbook. |
What buyers ask before outsourcing mail collector OAuth setup
What drives the cost of setting up OAuth mail collectors for GLPI?
The cost follows the scope agreed in writing before work starts, and the main drivers are the tenant access model, the number of mailboxes, the number of collectors and the depth of testing. A single shared support mailbox in one Microsoft 365 tenant is a small job. Several mailboxes across Microsoft 365 and Gmail, each with its own collector, shared or delegated access, and test cases for replies, attachments and threading, takes more planning and verification. Ask for a quote that lists each mailbox, each collector, the identity platform involved and the test cases you expect to see signed off. DeployOpen does not publish a price list, so the written scope is what sets the figure.
How long does mail collector OAuth setup take?
Duration depends mostly on how quickly your administrators can respond, not on the technical steps alone. The work needs an Entra app registration or a Google client, consent from a tenant or Workspace administrator, a first authorization by each mailbox owner, and a test pass in GLPI. If the tenant admin is available for a short review window, the sequence can run in a few working sessions. If approvals, change windows or mailbox owner availability are unpredictable, the calendar stretches. No duration is fixed here, so ask any provider to state the dependencies it expects from your side and the points where work waits on your people.
What does the client need to provide for this work?
You need three kinds of access and time from people. A Microsoft Entra administrator or Google Workspace administrator must be able to register the application or create the client and grant consent. Each mailbox owner must complete the first authorization, because the OAuth IMAP flow asks the account holder to approve access. Someone with administrator rights in GLPI must install and configure the plugin, create the mail collectors and link them to entities and notification rules. Confirm in advance who holds each role, whether any of them requires a change request, and which test mailbox can be used without touching live customer mail.
Can our internal team set up OAuth mail collectors without an outside partner?
Yes, a team with administrator access to both GLPI and the identity platform can do this internally, provided it has the time and the skills to check each step. The OAuth IMAP documentation identifies Gmail and Entra as supported mail services, and the plugin keeps collectors running as Microsoft removes TLS 1.0 and 1.1 for Microsoft 365 applications. The points that usually go wrong are an incorrect redirect or scope in the app registration, a collector pointed at the wrong folder, and missing tests for failure paths. A partner adds value when you want that verification done against a written scope and documented for your operators.
Do OAuth mail collectors need care after go-live?
The OAuth tokens the plugin retrieves are offline tokens with a renewal code, so GLPI renews them automatically after the first authorization without asking the user to sign in again. That removes routine re-authentication, but it does not remove ongoing work. Operators still need to watch collector status, review mailbox ownership when staff leave, and track the expiry dates of any client secret used in the app registration. Rotation of that secret is a scheduled task that should be written into your operations runbook with an owner and a reminder date.
How should client secrets be rotated for Entra or Google OAuth clients?
Rotate the client secret before it expires, store the new value in your approved secrets store, update the GLPI configuration, and confirm that collectors and outbound notifications still work before you revoke the old secret. Record the expiry date, the owner, and the test steps in the runbook. Use a separate test mailbox for the check. Confirm the exact steps for your identity platform against the current vendor documentation, because the portal screens and secret lifetime options change over time. Ask any provider to include rotation in the handover and to show how the reminder is tracked.
What should we check if a mail collector stops fetching tickets?
Check four things in order: whether the collector is enabled and reports a successful connection, whether the mailbox owner's authorization is still valid, whether the app registration or Google client still has the permissions and consent it needs, and whether the client secret has expired. Then check whether the mail is landing in the folder the collector reads. Keep a log of each change so you can see whether a tenant policy change or a password reset caused the fault. If the failure repeats after these checks, collect the plugin and GLPI logs before changing settings again.
Does DeployOpen certify that our mail setup meets compliance rules?
No. DeployOpen configures, documents and tests the mail collector and its identity settings, and can prepare the evidence your compliance team needs, such as the configuration record, access assignments and test results. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Ask your assessor early which records they expect for mail access and secret management, so the handover produces them.
How DeployOpen scopes and delivers GLPI mail collector OAuth
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and GLPI mail collectors are scoped the same way: a written scope first, then a tested build, then a handover the mail administrators can run. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- We inventory every mail collector, its mailbox, its entity and the tickets it creates before any app registration is requested.
- We confirm which Microsoft 365 tenant or Google Workspace domain owns each mailbox and who can grant administrator consent.
- The written scope names the OAuth IMAP plugin version, the GLPI version in use and the SMTP notification flows that will move to OAuth too.
How we build
- We register the Entra application or Google client in a test tenant first, then verify redirect URIs and granted mailbox permissions.
- We configure each collector with OAuth, confirm the first authorization yields an offline token, and test that the renewal code refreshes it.
- We test email-to-ticket end to end with replies, attachments and rejected senders, and record the results against the agreed scope.
How we hand over
- You receive configuration records for each app registration, collector and SMTP flow, with client secret expiry dates written down.
- We document the renewal, rotation and reauthorization steps, including what to do when a plugin update suspends a collector.
- Your administrators run a walkthrough on their own tenant so they can repeat the setup for new mailboxes without us.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so mail collectors can be watched after go-live.
- A retainer can cover monitoring of collector errors, planned client secret renewals and checks after each GLPI or plugin update.
- Ask any provider to confirm in writing who owns the Entra or Google credentials after handover and where those secrets are stored.
