GOV.UK One Login is the consolidated identity service replacing the patchwork of departmental logins, Government Gateway, and ad-hoc account systems across central government and, increasingly, devolved and local public services. For citizen-facing operational software, it is the path everyone should be on by 2027. The implementation is straightforward; the gotchas are where it usually goes wrong.
What One Login is (and is not)
One Login is a federated identity provider built on OpenID Connect. It gives a citizen a single account that works across participating GOV.UK services, with verified identity attributes available to relying services that request them. It is not a replacement for Government Gateway in every context yet, but the migration path is published and most new services are expected to use One Login as the default.
For operational software, this matters most for tenant portals, citizen request forms, and any system where a member of the public might land. Internal staff authentication is usually a separate Single Sign-On flow via Azure AD, Google Workspace, or similar; One Login is for the citizen-facing edge.
Levels of confidence
One Login supports several levels of identity assurance, expressed as Levels of Confidence in the OIDC request. Cl is "the user authenticated themselves": an email address, a verified MFA second factor. P1, P2 and higher add identity verification of varying strengths, including document checks and biometric matching.
For most CAFM tenant portals, Cl is sufficient. The user proves they are who they claim to be on a session basis; the actual link to a specific tenancy is established by the housing or service-provider system. P-level identity verification matters when the platform itself needs to make benefit, eligibility, or financial decisions, which is rarer in operational software.
The mistake to avoid is requesting a higher level of confidence than the use case actually requires. P-level verification is not free, both in cost and in user friction. Specify the lowest level that meets the policy need.
The integration flow
The integration is a standard OIDC Authorization Code flow with PKCE. Your service registers as a relying party with the One Login admin tool. When a citizen tries to sign in, you redirect them to One Login with the requested scopes and confidence level. They authenticate. One Login redirects them back with an authorisation code. Your service exchanges the code for an ID token, validates it, and creates a session.
The pieces that catch teams out are the certificate rotation policy, the retry logic for token exchange when One Login is briefly under load, and the requirement to handle the case where a citizen revokes consent or is signed out elsewhere. The published integration kits handle most of this; the edge cases are usually only visible after the first month of production use.
What CAFM vendors should already support
If you are evaluating CAFM software for a UK public sector buyer in 2026, the question is not "does it support One Login," it is "has it actually been deployed with One Login at this level of confidence." Vendors who can answer the second question concretely tend to have the integration sorted; vendors who answer the first question vaguely tend not to.
Specifically, you should expect: full OIDC flow with PKCE, configurable level-of-confidence requests per service, claim mapping into the platform's own user model, sign-out propagation, and a working answer to what happens when a citizen turns up authenticated by One Login but with no existing record in the platform.
GOV.UK Notify as the natural pair
One Login handles authentication. GOV.UK Notify handles outbound communication. Together they form the GOV.UK citizen interaction stack: the citizen logs in with One Login, the platform confirms their identity, and any follow-up communication goes through Notify with verified templates and full audit trail. SMS, email, and letter are all available; the templates have to be approved before use, which is usually fine but worth allowing lead time for.
The pair is more than the sum of its parts. A repair tracker that lets a citizen log in with One Login, view their job, and receive Notify-delivered status updates is a smaller integration than building all of that yourself and a much better user experience than a generic supplier portal.
Common gotchas
Three things bite teams in the first month of production. The first is the difference between sandbox and production environments: One Login's sandbox is permissive, the production environment is stricter, and certificates that work in one do not always work in the other without adjustment. The second is the case where a user with a One Login account first signs into your service: you have an authenticated identity but no application record, and the journey to attach the identity to the right tenant or property needs to be designed deliberately. The third is sign-out: a user signing out of your service does not sign them out of One Login by default, which can be confusing and requires explicit handling.
None of these are blockers. They just need to be in the test plan rather than the bug log.
See One Login working in CAFM
Jarsis Platform ships GOV.UK One Login and Notify as part of the Professional tier. Book a 30-minute walkthrough to see it end-to-end, from citizen sign-in to outbound status notifications.