The UK government has been quietly rolling out one of the most ambitious identity infrastructure projects in British public sector history. GOV.UK One Login is the single sign-on layer being stitched across dozens of government services, from HMRC tax accounts to DVLA lookups. Right now, millions of people are already using it. And because it sits between citizens and the state, the GOV.UK One Login security architecture is worth pulling apart properly, not to cause panic, but because understanding it is exactly the kind of thing we should be doing.
Let’s get into the stack.
How GOV.UK One Login Actually Works Under the Hood
At its core, One Login is an OAuth 2.0 authorisation server paired with an OpenID Connect (OIDC) identity layer on top. If you’ve built anything with modern auth, this pattern is familiar. A relying party (a government service like “Manage your driving licence”) redirects the user to the One Login authorisation endpoint. The user authenticates, consents if required, and One Login returns an authorisation code. That code gets exchanged for an access token and, critically, an ID token signed with One Login’s private key.
The ID token is a JWT (JSON Web Token). It carries claims about the user: a persistent subject identifier (sub), authentication assurance level, and in higher-assurance flows, verified identity attributes. Relying parties validate the token signature against One Login’s published JWKS (JSON Web Key Set) endpoint. Standard stuff, well-understood protocol. The interesting attack surface isn’t usually in the protocol itself but in the implementation details around it.
Authentication Levels and Credential Binding
One Login uses the DCMS/DSIT identity assurance framework built around three authentication confidence levels: Cl.Cm (low), Cl.Cm with medium, and the higher-assurance flows that tie into biometric passport checks and real-time document verification. For most services, a verified email plus SMS OTP gets you through. For higher-value services, you’re looking at a full identity proofing pipeline.
Credential binding is where it gets interesting. When a user completes identity verification (uploading a passport photo, live selfie match, NFC chip read on supported devices), the resulting verified identity proof is bound to the user’s credential set. That binding is recorded in One Login’s backend. The credential is now “vouched” at a higher level. This is separate from the OIDC session itself, but the session token carries a claim reflecting the assurance level achieved.
The Identity Verification Pipeline
The identity proofing flow is arguably the most complex part of the GOV.UK One Login security architecture. It involves several discrete stages:
- Document capture: The user photographs their passport or driving licence. The image is processed for MRZ (machine-readable zone) data and checked against HMPO and DVLA records.
- Biometric liveness: A live selfie is taken and compared against the document photo using facial recognition. This is handled by a contracted supplier pipeline rather than in-house GDS code.
- Fraud signal checks: The verified attributes are cross-referenced against the National Fraud Initiative and other data sources to flag synthetic identities or previously compromised credentials.
- Identity claim storage: Verified attributes are stored separately from authentication credentials. The OIDC layer receives a reference token that resolves to the verified claims at request time, rather than embedding raw PII in the JWT itself.
That last point matters a lot. By keeping identity claims in a separate store and issuing reference tokens, One Login avoids stuffing a passport number into every session token floating around. It’s a decent architectural choice. But it also means there are two high-value targets instead of one: the session token infrastructure and the identity claim store.
Where the Real Attack Surface Lives
Let’s be direct about the threat model. Nation-state actors, organised fraud rings, and opportunistic credential thieves all have different motives but overlapping targets. Here’s where I’d focus if I were writing a threat model for this system:
Token Theft and Session Hijacking
OIDC tokens are bearer tokens. If you have one, you are that user as far as the relying party is concerned. One Login uses short-lived access tokens with refresh token rotation, which limits the window. But refresh token theft at scale (via a compromised relying party, a phishing kit mimicking a gov service, or a man-in-the-browser attack on a low-assurance session) could still hand an attacker persistent access to whatever services that identity is enrolled in.
PKCE (Proof Key for Code Exchange) is implemented for public clients, which plugs authorisation code interception. But the weakest link is usually the user’s device or the relying party’s session management, not the One Login OIDC endpoints themselves.
Account Takeover via Weak Recovery Flows
SMS OTP as a second factor is vulnerable to SIM-swapping. In the UK, this is a documented and active fraud vector. If an attacker can SIM-swap a target’s mobile number, they can bypass the SMS-based MFA on a One Login account. At that point, they have access to every service linked to that identity, and if the account was identity-verified, they’re walking around with a state-backed digital identity that isn’t theirs.
Compromised Relying Party as a Token Harvesting Vector
One Login’s token security is only as good as the relying parties trusting it. If a poorly secured government service (an older departmental application bolted onto the OIDC integration) is compromised, attackers can harvest valid tokens from active sessions. The One Login platform itself doesn’t need to be breached for this to be devastating.
Blast Radius: What a Real Compromise Looks Like
This is the part that should focus minds. One Login is being positioned as the identity layer for dozens, eventually hundreds, of government services. Tax. Benefits. Driving. Passport applications. NHS login alignment is being discussed. The blast radius of a serious compromise scales with adoption.
A bulk compromise of high-assurance identity tokens would not just affect individual accounts. It would undermine the trust model underpinning all those services simultaneously. Fraudsters with verified identities could file fraudulent HMRC self-assessments, alter benefit payment details at DWP, or redirect DVLA correspondence. The financial and social harm would be enormous, and the forensic cleanup would take years.
GDS have published some of their architecture thinking openly, and they’ve clearly made sensible choices in places. Short token lifetimes, claim separation, PKCE enforcement. The harder problem is the human factors: the SIM-swap vectors, the phishing kits that will inevitably target this platform as adoption grows, and the third-party supplier risk in the identity proofing pipeline where biometric processing happens outside of direct GDS control.
Is the GOV.UK One Login Security Architecture Actually Good?
Honestly? For a government platform, it’s not bad. The OIDC implementation follows current best practice. Claim separation is smart. Assurance levels are clearly defined. The published technical documentation is unusually transparent for a public sector project.
The gaps are in the areas that are hardest to fix: MFA quality, relying party security posture, and the concentration risk that comes from centralising identity across the entire British government. Centralisation always trades resilience for convenience. One Login is a massive target precisely because it works. That’s the deal you make.
Watch the bug bounty reports. Watch the NCSC advisories. And if you’re building anything that integrates with this platform, treat it like what it is: a high-value identity provider with a very large target painted on it.
Frequently Asked Questions
What authentication standards does GOV.UK One Login use?
GOV.UK One Login is built on OAuth 2.0 for authorisation and OpenID Connect (OIDC) for identity. It issues signed JWTs as ID tokens and uses PKCE for public client flows to prevent authorisation code interception attacks.
How does GOV.UK One Login verify your identity?
Higher-assurance identity verification involves photographing an approved document (passport or driving licence), a live biometric selfie matched against the document, and cross-referencing your details against government records including HMPO and DVLA data. Lower-assurance services only require email and SMS OTP.
What happens if your GOV.UK One Login account is compromised?
An attacker with access to your account can reach every government service linked to that identity, potentially including HMRC, DVLA, and DWP services. At high assurance level, they effectively hold a state-verified digital identity, making the fraud impact significantly worse than a standard account takeover.
Is SMS two-factor authentication on GOV.UK One Login secure?
SMS OTP is vulnerable to SIM-swapping attacks, which are an active fraud method in the UK. If an attacker can port your mobile number to a SIM they control, they can bypass SMS-based MFA. Using an authenticator app where One Login offers the option is meaningfully more secure.
Can a hacked government website compromise your GOV.UK One Login credentials?
Not directly, but a compromised relying party (a government service that uses One Login) could harvest valid session tokens from authenticated users. The One Login platform itself would not need to be breached for this attack to succeed, which is why third-party service security matters in this ecosystem.
Leave a Reply