GLPI SSO with Okta, Google or Keycloak

How GLPI SSO with Okta, Google or Keycloak works through the OAuth SSO plugin

The OAuth SSO plugin adds Okta, Google or Keycloak sign-in buttons to the GLPI login page, and it needs a GLPI Network Basic subscription or higher before any of those buttons will work. The plugin can create a GLPI user automatically at first login, can hide the internal login form so that users must authenticate through the identity provider, and leaves permissions to authorization rules rather than granting them from the identity provider's groups by default. This page covers the method, prerequisites, build sequence, attribute and profile mapping, security settings, testing and the failure points that most often delay a go-live.

The sequence starts with the identity provider, not GLPI. You register GLPI as an OAuth client in Okta, Google or Keycloak, which produces a client ID and secret, and you define the redirect URI that the plugin expects. Confirm the exact redirect URI and the scopes the plugin requests in the plugin documentation for your GLPI version before you create the client, because a mismatch between the registered redirect URI and the one GLPI sends is the most common reason sign-in fails at the first attempt. The public URL GLPI uses must also match what users type in their browser, including the scheme and host, or the callback will not resolve correctly behind a reverse proxy.

Once the client exists, enter its settings in the plugin, then decide three things before you enable forced SSO. First, decide whether auto-creation is acceptable for every user the identity provider can authenticate, since an open tenant will create accounts for anyone who can sign in. Second, write the authorization rules that assign profiles and entities from claims, and test them with a non-administrator account. Third, keep at least one local administrator account with the internal form still reachable, so a misconfigured rule or an expired client secret does not lock every administrator out. Track the client secret expiry date in your identity provider, because a lapsed secret will stop sign-in for all users at once. Verify each step in a staging GLPI instance that uses the same identity provider tenant or realm.

What you need before enabling GLPI SSO with Okta, Google or Keycloak

Enabling SSO touches the GLPI version, its runtime, the subscription that unlocks the OAuth SSO plugin, the identity provider and the URL users return to. Confirm each item below before you change any login settings, because a mistake in one of them can lock out every user.

Supported GLPI version and runtime

Confirm the GLPI version you run and the PHP and database versions it needs before you install the plugin. 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, while the installation docs list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 for GLPI 11.0. Only MySQL and MariaDB are supported, so check which requirement applies to your release and plan any upgrade first.

GLPI Network subscription

The OAuth SSO plugin needs a GLPI Network Basic subscription or higher, so the plugin cannot be enabled on a community-only install. Ask Teclib' or your reseller which tier covers your agent and asset count, and confirm whether your deployment is self-hosted or hosted on GLPI Network Cloud. Get the subscription in writing before the project starts, since it is a recurring cost on top of the implementation work.

Identity provider application registration

Create an OpenID Connect application for GLPI in Okta, Google or Keycloak, and record the client ID and client secret in your secrets store. Register the exact redirect URI that the plugin displays, and decide which users or groups the application will allow. For Keycloak, plan the realm and client settings in advance, since a mismatched redirect URI is the most common cause of a failed first login.

Public HTTPS URL for GLPI

Identity providers redirect users back to GLPI, so GLPI needs a stable public HTTPS address that matches the redirect URI registered with the provider. Confirm the URL that users type into their browser, the certificate that serves it and the reverse proxy path that reaches GLPI's public directory. An internal hostname or a changing address will break the callback even when the rest of the setup is correct.

Tested internal fallback administrator

Keep one local GLPI administrator account that does not depend on the identity provider, and test that it signs in before you turn on forced SSO. Store its credentials in a sealed vault, and confirm which login path it uses after the internal login form is hidden. Without this account, an error in the authorization rules or an identity provider outage can leave no one able to change the configuration.

How to configure the OAuth SSO plugin step by step

This sequence moves GLPI from a configured sign-in button to a tested SSO setup, where each change is checked before the next one is made. The internal login form is hidden only after a non-administrator has signed in successfully.

Confirm subscription and plugin activation
Confirm that your GLPI Network subscription is at Basic or higher, since the OAuth SSO plugin requires it. Then install the plugin from the GLPI Network documentation for the OAuth SSO plugin, and check that it is listed as active in the plugin management screen. After any GLPI 11 update, check again, because plugins are suspended when a new version is detected and must be reactivated after major updates. Done when the plugin shows as active and the subscription is confirmed in writing by your Teclib' or partner contact.
Register GLPI as an OAuth client
In Okta, Google or Keycloak, create an OAuth or OpenID Connect client for GLPI. Copy the callback URL that the plugin displays, and enter it exactly as shown, including the scheme and path, because a mismatch is the most common reason sign-in fails. Confirm the exact registration fields against your provider's current documentation and the plugin page. Done when the provider shows a client ID and a client secret, and the redirect URI in the provider matches the one in the plugin character for character.
Enter client credentials in the plugin
In GLPI, open the OAuth SSO plugin configuration and select the identity provider you registered. Enter the client ID and client secret from the previous step, then save. Store the secret in your password vault as well, since it is shown once in most provider consoles. Done when the configuration saves without an error and the sign-in button for your provider appears on the GLPI login page. Open the page in a private browser window to confirm the button is visible to signed-out users.
Enable automatic user creation
Turn on automatic user creation so that a person who signs in through the provider for the first time gets a GLPI account without an administrator creating it by hand. Keep the setting documented, because it determines who can get an account at all. Check which identity provider groups or domains can reach the sign-in button in your provider's assignment settings. Done when a test user from the provider signs in and a matching account appears in GLPI's user list.
Define profile assignment with authorization rules
The plugin leaves permissions to GLPI authorization rules, so create rules that assign profiles and entities based on attributes returned by the provider, such as group membership or email domain. Start with a rule that gives a low-privilege profile by default, then add narrower rules for staff who need more access. Test each rule against the test user's attributes. Done when the test user lands in the expected profile and entity, and no account receives an administrator profile without an explicit rule for it.
Test sign-in with a non-administrator account
Sign in with a standard user account from a separate browser session that has no existing GLPI session. Check that the user reaches the tickets or assets they should see, cannot open administration pages, and that signing out and back in works. Repeat the test with a second user from a different group if your provider uses groups to assign profiles. Done when both test accounts behave as the authorization rules intend and the results are recorded in your change record.
Hide the internal login form last
Only after the previous checks pass, enable the setting that hides the internal login form so that users must sign in through SSO. Before you enable it, confirm that a local administrator account can still sign in and that its credentials are stored in a secure location for emergencies. Done when a signed-out browser shows only the SSO option, a test user can still sign in through it, and the local administrator recovery path has been tested once and documented.

How the login flow and trust boundary fit together

The identity provider proves who the user is, and GLPI decides what that user may do. When a user chooses the Okta, Google or Keycloak button, GLPI redirects the browser to the provider's authorization endpoint with the OAuth SSO plugin's client registration. The user authenticates there, possibly with multi-factor authentication enforced by the provider, and the provider redirects back to GLPI's callback with a code that GLPI exchanges server to server for tokens. GLPI then reads the identity claims from the returned token and matches them to a local account. Confirm with the plugin documentation which claims it reads and which callback URL your registration must list, because a mismatch here is the most common reason the return step fails.

The trust boundary sits between authentication and authorization. The provider is trusted to say a person is who they claim to be. It is not trusted to say which GLPI profile, entity or right that person receives. The plugin leaves permissions to GLPI's authorization rules, so the rule set you write determines whether a new user lands in a helpdesk profile or an administrator profile. Decide before go-live who owns those rules, how group or claim values map to profiles, and what happens to an account the rules do not match. Automatic user creation at first login is convenient, but it means any user the provider authenticates can get an account, so pair it with rules that default to the least privileged profile.

Keycloak adds a design question that Okta and Google do not. Keycloak can broker sign-in to upstream providers such as corporate directories or social logins, so GLPI may see Keycloak as its only identity source while the real identity store sits behind it. Whether Keycloak should be the single trusted issuer, or whether GLPI should connect to Okta or Google directly, depends on what your identity estate already contains and which system is the source of truth for group membership. Inventory your existing providers, their group claims and their lifecycle processes first, then choose the issuer. Confirm the Keycloak version and client settings with your own team, since the trust chain is only as strong as the broker configuration.

Which identity claims map to GLPI users, profiles and entities

This table shows which identity provider attributes feed GLPI user records, authorization rules, profiles and entities when signing in through the OAuth SSO plugin. Exact claim names differ between Okta, Google and Keycloak, so confirm each one in the provider's own configuration before writing rules that depend on it.

Identity attribute	What GLPI uses it for	What to confirm before go-live
Subject (sub)	Stable identifier that should link a GLPI account to the same person across sign-ins	The claim name and whether it stays unchanged if a username or email changes in the provider
Email	Account email address, notification target and often the matching key for existing GLPI users	Whether the claim is verified and whether the same address can exist on two accounts
Name (given and family)	Displayed user name in GLPI and in ticket requesters and assignees	Which claims the provider sends by default and whether your scopes request them
Group membership	Input to authorization rules that assign a GLPI profile and entity to the user	Whether groups arrive in the token at all, the claim name, and whether nested groups are included
Custom role or attribute	Optional input to rules where groups are not enough, such as a job title or department	That the attribute is added to the token or user info response and is populated for every user who signs in
Profile assignment	Set by authorization rules after login, so the user receives the GLPI profile you intend	That every rule matches a claim value that exists in the provider, and a default fallback for users who match no rule
Entity assignment	Determines which GLPI entities and assets a user can see, set through rules or the entity mapping	That the entity rules match the group or attribute scheme you use for data separation

Security settings to decide before forcing SSO

Forcing sign-in through Okta, Google or Keycloak moves the front door of GLPI to your identity provider, so the choices below decide who gets in, what they can do and how you recover if the identity provider or the plugin fails. Settle them in the design phase, then test each one in a non-production instance before the internal login form is hidden.

Client secret storage and rotation

The OAuth SSO plugin holds a client ID and client secret issued by your identity provider. Decide who can read that secret in GLPI's configuration, where the secret is recorded in your change records, and how it reaches the staging and production instances without being pasted into tickets or chat. Confirm with your identity provider team how the secret is rotated, how long it stays valid, and who is notified before it expires. Test the rotation on staging first, because a rotated secret that is not updated in GLPI will stop every SSO login at once.

Who can create users at first login

Automatic user creation is convenient, but it means any account that your identity provider authenticates can become a GLPI user. Limit the sign-in to the groups, domains or applications in your identity provider that should have GLPI access, and confirm that the plugin's domain or identifier checks are set to match. Review the account attributes that GLPI stores on first login, such as the login name and email address, so that a later rename or domain change in the identity provider does not create a second account with the same person's history.

Break-glass local administrator

Keep at least one local GLPI administrator account that does not depend on Okta, Google or Keycloak. Store its password in your secrets vault, restrict its use to documented recovery cases, and test that it can still sign in after forced SSO is enabled. Without this account, an identity provider outage, a misconfigured redirect URL or an expired client secret can lock every administrator out of the console. Confirm the account's authentication method with your team, since GLPI's authentication order also determines whether it is tried before or after external methods.

Least-privilege profile rules

The plugin leaves permissions to authorization rules, so a new SSO user receives no access beyond what those rules grant. Write rules that map identity provider groups to the narrowest GLPI profile that does the job, and set a default profile that gives a self-service or read-only view. Avoid a catch-all rule that assigns the super-administrator profile, and review rule order because the first matching rule can decide the outcome. Ask your GLPI partner or internal team to run a test login for each profile before go-live.

GLPI 12 session view and step-up authentication

GLPI 12.0.0 adds a view of active user sessions with the ability to revoke them, and step-up authentication for certain administrative actions. Decide who will watch that session view, how quickly a compromised SSO session must be revoked, and whether step-up authentication is enforced for administrators who sign in through the identity provider. Check whether step-up prompts reach the user through the identity provider's own second factor, so that administrators are not asked to authenticate twice with separate methods. Applies only if you deploy GLPI 12.

How the setup differs for Okta, Google and Keycloak

Okta is the most direct of the three for this plugin because it is a standard OpenID Connect provider with an admin console for application integrations. You create a web application for GLPI, record the client ID and client secret, and register the callback address that the OAuth SSO plugin displays. Most of the planning effort goes into deciding which Okta users may sign in and how their group memberships reach GLPI.

App integration: Create an OpenID Connect web application in the Okta admin console and assign only the users or groups that should reach GLPI.
Redirect URI: Register the exact callback address generated from your public GLPI URL, including scheme and host. A mismatch stops sign-in before any user is created.
Groups claim: Group membership reaches GLPI only if a claim is configured on the authorization server that Okta uses. Confirm the claim name and filter in your tenant before you write authorization rules against it.
Secret handling: Store the client secret only in the plugin configuration, set a rotation schedule and record the expiry date.

Check that a test user from each group signs in and that the profile GLPI assigns matches the rule you intended.

Why GLPI SSO sign-in fails and how to fix it

This table lists the most common reasons GLPI sign-in through the OAuth SSO plugin fails with Okta, Google or Keycloak, with the cause and fix for each. Work down the rows in order when a login breaks, because several failures look identical from the user's side but have different causes. The main takeaway is that most failures sit in the identity provider app settings, the subscription state, or the authorization rules rather than in GLPI itself.

Failure	Likely cause	Fix
Redirect URI mismatch	The callback URL registered in Okta, Google or Keycloak does not match the GLPI URL exactly, including scheme, host and path.	Copy the callback URL from the OAuth SSO plugin configuration and paste it unchanged into the identity provider client settings, then test again.
Plugin not reactivated after an upgrade	Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates.	Check the plugin list in GLPI after every upgrade, reactivate OAuth SSO, and confirm the login buttons reappear.
Subscription not active	The OAuth SSO plugin needs a GLPI Network Basic subscription or higher, so the feature stops working when the subscription lapses or is not linked.	Confirm the subscription status with Teclib' or your GLPI Network contact and verify the plugin accepts the activation before troubleshooting further.
Users blocked because automatic creation is off	The identity provider authenticates the user, but GLPI has no local account and automatic user creation at first login is disabled.	Enable automatic creation in the plugin settings, or create the accounts in advance and confirm the login identifier matches the one the provider sends.
Profile not assigned because no authorization rule matches	Permissions are left to authorization rules, so a user with no matching rule may sign in with no useful profile or see an empty interface.	Review the authorization rules against the claims your provider sends, add a default rule if your policy allows one, and test with a representative account.
Locked out after forcing SSO	Hiding the internal login form removes the fallback path, so if the provider or its settings fail, administrators cannot sign in with a local account.	Keep at least one break-glass local administrator account, document how to re-enable the internal form, and test that path before forcing SSO in production.
Clock or certificate issues	Token validation fails when the GLPI server clock drifts from the provider, or when the provider signing certificate or TLS chain is not trusted by GLPI.	Synchronize GLPI server time with an approved time source, confirm the provider certificate and CA chain are trusted by the web server, and check the provider certificate rotation schedule.

What teams ask before running GLPI SSO with an outside partner

What drives the cost of GLPI SSO with Okta, Google or Keycloak?

The main drivers are the GLPI Network subscription tier you need, the number of identity providers you connect, how complex your authorization rules are, and whether you host Keycloak yourself. The OAuth SSO plugin requires a GLPI Network Basic subscription or higher, so the subscription is a recurring cost on top of the one-time configuration work. Self-hosted subscriptions start at 100 euros per month for Basic, according to the GLPI Network subscriptions page, and rise to 4,500 euros per month for Enterprise. Each additional provider adds configuration, testing and login-flow review. Keycloak hosting adds infrastructure, patching and backup work if your team does not already run it. Ask any partner for a quote that separates the one-time build, the subscription you pay Teclib' directly, and any ongoing support.

How long does GLPI SSO setup take for our identity setup?

Duration depends mostly on how many identity providers you connect, how your users, groups and attributes are organized, and how many profile assignments your rules must cover. A single provider with a simple group-to-profile mapping is a much shorter task than several providers feeding multiple entities. Keycloak adds time if the realm, clients and user federation are not yet built. No researched duration is available for this work, so ask the partner to state the timeline in the written scope and list the assumptions behind it, including which identity systems are already in place and who signs off each test.

What must our team provide before an outside partner starts?

Expect to provide access and decisions rather than code. The usual inputs are:

A GLPI instance you already run, or a plan for one, with its public URL settled, since the redirect addresses depend on it.
Administrative access to the identity provider or Keycloak realm, with an owner who can create OAuth clients.
A list of which users should sign in through which provider, and which groups should map to which GLPI profiles and entities.
A test group of users and a named approver for forced SSO cut-over.
Confirmation that a GLPI Network subscription covers the GLPI instance.

Confirm the exact steps for your environment with the partner and your identity team before work starts.

Can an internal team set up GLPI SSO without a partner?

Yes, if your team already administers GLPI, your identity provider and your web server, and has someone who can read and write authorization rules. The plugin itself is configured in the GLPI interface, so the main risk is not the screens but the rules. Mistakes in automatic user creation or profile assignment can give users too much access, and forced SSO can lock out administrators if it is enabled before a fallback exists. A partner is useful when you want a documented test plan, a reviewed rule set and a cut-over that your security team can evidence. Ask any partner to state in writing which parts of the work they will hand over to your staff.

Does GLPI Network pricing apply per user for the SSO plugin?

Not necessarily. The GLPI Network subscriptions page lists public cloud at 19 euros per user per month and private cloud at 21 euros per user per month with a 25-user minimum, but the self-hosted subscriptions it lists are priced by tier, from 100 euros per month for Basic, up to 10 agents and 500 assets, to 4,500 euros per month for Enterprise. The OAuth SSO plugin requires a Basic subscription or higher, so the per-user figures apply only if you choose a per-user cloud offering. Confirm with Teclib' which model covers your GLPI instance and whether your user count changes the tier you need.

How do GLPI upgrades affect the OAuth SSO plugin?

Plugins need attention during every GLPI upgrade. The update procedure requires backing up the database, the files and the config directory, including the glpi.key and glpicrypt.key files, then replacing the application files and running php bin/console db:update. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates. Check the plugin's compatibility with the target version, including GLPI 12.0.0, before you schedule the upgrade, and retest the login flow, the redirect URLs and the rules afterwards. Ask your partner how they will keep the SSO configuration documented across upgrades.

What should an engineer check after SSO goes live in GLPI?

Check the path a real user takes, not only the first successful login. Confirm that automatic user creation produces the right account, that each rule assigns the expected profile and entity, and that the internal login form is hidden only when forced SSO is intended. Test an administrator account to confirm a recovery route exists. On the Keycloak side, confirm the client settings, the redirect URIs and the token lifetime match the GLPI configuration. Keep the test results and the rule export with your change records, since your auditors will ask how access was granted.

How to test SSO before you force it

Test every sign-in path in a staging GLPI instance before you hide the internal login form. Build that instance on the same OAuth SSO plugin version as production, and point it at a test tenant in Okta, Google or Keycloak with its own test users and groups, so that a broken rule cannot lock real administrators out. Confirm the plugin version and the GLPI Network subscription level on staging with your vendor before the first test, because the plugin needs a GLPI Network Basic subscription or higher and staging needs the same entitlement to behave like production.

Cover these cases, each with a written expected result. First, a new user signing in for the first time, where the account should be created automatically and receive the profile that the authorization rules assign, not a default profile. Second, an existing local GLPI user whose email or login matches the identity provider account, where you confirm whether GLPI links the two or creates a duplicate, since duplicates split ticket history and assets. Third, a user in each group you map to a profile, checking that the profile and entity match the rule. Fourth, a user who exists in the identity provider but should be refused by your rules, which must result in no GLPI profile. Fifth, logout, confirming whether the GLPI session and the identity provider session end together. Sixth, the fallback path: the internal login for a named break-glass administrator, tested with the form still visible and again after it is hidden.

Record the result of each case with the account, the rule that fired and the profile granted, and repeat the full set after every rule change or plugin update. Confirm the break-glass account and its recovery steps with your security team before you enable forced SSO, and keep the GLPI encryption keys and database backup in place as described in the update procedure. Your own environment decides which identity provider attributes carry group membership, so check that mapping against your directory, not against this list.

How DeployOpen scopes and delivers GLPI SSO

DeployOpen plans GLPI SSO with Okta, Google or Keycloak as a fixed-scope engagement inside your own infrastructure. We confirm the subscription, identity provider and access model first, then build, test and document the sign-in path so your team can run it afterward.

How we scope

Confirm which identity provider (Okta, Google or Keycloak) and which GLPI version and hosting model apply to your environment
Confirm the GLPI Network subscription tier required by the OAuth SSO plugin before any build work starts
Record the agreed scope, deliverables and timelines in writing before work begins, since most engagements are fixed-scope

How we build

Configure the OAuth client in your identity provider and the matching OAuth SSO settings in GLPI on infrastructure you control
Design automatic user creation at first login and map authorization rules to GLPI profiles and entities
Test forced SSO and the internal login fallback in a non-production instance before any change reaches users

How we hand over

Document the redirect URIs, client settings, rule logic and profile assignments so your team can audit them
Walk your identity and GLPI administrators through the sign-in flow, failure cases and the break-glass account procedure
Deliver a written record of configuration and test results that your internal reviewers and auditors can reference

How we support

Plan GLPI version upgrades and plugin reactivation steps alongside the SSO configuration so sign-in survives the update
Offer ongoing support, upgrades and continuous testing as a retainer after handover
Review identity provider changes, such as client secret rotation or Keycloak upgrades, before they affect GLPI sign-in

GLPI SSO with Okta, Google or Keycloak through the OAuth SSO plugin