Federated Identity vs Single Sign-On in Government Systems

Public sector digital services in Australia have moved well beyond the era of paper forms and separate logins for every agency. Citizens now expect a single, trustworthy way to prove who they are when dealing with the Australian Taxation Office, Services Australia, state revenue offices and a growing list of local councils. Two terms dominate the conversation about that experience: federated identity and single sign-on. They are often used interchangeably in marketing material and even in some procurement briefs, yet they describe different technical patterns with different trust boundaries, costs and risks. Getting the distinction right is the first step toward designing a service that citizens actually trust.

The confusion is understandable because the two patterns frequently appear together. A well-known platform such as myGov, which millions of Australians use to access Centrelink, Medicare and the ATO, looks and feels like one system, yet under the surface it is a layered combination of authentication, session handling and inter-agency agreements. Pinpointing where single sign-on ends and federation begins is essential for anyone evaluating vendors, drafting policy or planning a digital transformation program, particularly in jurisdictions where state and federal agencies must cooperate.

Core Concepts: What Each Term Actually Means

Single sign-on, usually abbreviated to SSO, refers to a pattern where a user authenticates once and is then recognised across multiple applications within the same administrative domain. The classic example is an employee logging in at the start of a shift and gaining access to email, the human resources portal, the document management system and the internal intranet without being asked for credentials again. The session is shared, the trust is internal, and the identity provider is the same legal organisation that runs the consuming applications.

Federated identity is a broader concept. It describes an arrangement where identity assertions are accepted across different legal entities, security domains or technology stacks. Instead of one organisation issuing and consuming identities, multiple parties participate through a trust framework that defines how identity is proven, what attributes can be shared and what liability each side carries. The user still experiences a seamless login, yet behind the scenes a contract, a technical protocol and a governance process are doing the work. In other words, SSO is a capability, while federation is a relationship.

Architectural Reach: Domains, Boundaries and Trust

The clearest way to separate the two patterns is to look at where the trust boundary sits. In an SSO deployment, the boundary is usually the perimeter of a single organisation. All participating applications trust the same identity provider, share the same user store and operate under the same security policies. Federation, on the other hand, crosses organisational lines. A state health department might accept identities issued by a federal identity provider, or a council might accept logins from a state digital ID, and each side remains an independent legal entity with its own obligations.

That difference has practical consequences. An SSO solution can be procured, configured and operated by a single agency. A federation requires negotiation, contractual alignment and often a separate trust framework operator. The technical protocols used in federation, such as SAML or OpenID Connect, are essentially the same ones that power SSO, but the governance overhead is heavier. Readers exploring practical references on this topic, including notes drawn from technical resources, will see the same theme: protocol choice is rarely the hard part, while governance and operational ownership are.

The distinction also shows up in how user attributes are handled. In SSO, attributes such as role, department or clearance level are typically maintained in a central directory that the identity provider controls. In federation, the originating party asserts attributes, and the relying party decides whether to accept them. That shift from authoritative source to trusted assertion is the heart of federation and the reason federated systems need rigorous attribute mapping policies.

Government Use Cases Across Australia

Australia offers a rich set of examples that illustrate how these patterns coexist. The federal myGov platform is widely treated as a federated identity hub. It allows a user to authenticate once and then link to participating services such as the ATO, Medicare, Centrelink and the Australian JobActive system. From the user's perspective the experience is seamless. Behind the scenes, however, each participating agency remains an independent legal entity, with its own policies, its own record systems and its own accountability to the Privacy Act 1988.

At the state level, services such as Service NSW, Service Victoria and Queensland's QGov provide SSO within their own portfolios, but they also participate in cross-jurisdictional federation pilots. A Sydney resident renewing a driver's licence might use a state-issued credential that is accepted by a federal partner under a federation agreement. In South Australia, the mySA account follows a similar pattern, blending internal SSO with selective acceptance of identities from outside its own boundary.

The Australian Government Digital ID program, formerly known as GovPass and now operating under the Trusted Digital Identity Framework, is a deliberate attempt to provide a federated identity layer for both government and private sector use. Banks, telcos and other identity providers can issue credentials that relying parties such as the ATO can accept. That program is federation in its purest form: multiple identity providers, multiple relying parties, a shared trust framework and an accreditation regime. The architecture helps resolve practical would you rather questions about privacy versus convenience by providing accredited options for both.

Security, Privacy and Compliance Under Australian Law

Both patterns carry security obligations, but federation amplifies them because more parties handle identity data. The Privacy Act 1988 and the Australian Privacy Principles apply to every agency that handles personal information, and the Notifiable Data Breaches scheme means a federation partner that suffers a breach may have to notify regulators and affected individuals even if the breach occurred entirely outside the relying party's own systems. Agencies in Adelaide, Brisbane, Perth and Hobart all operate under the same federal framework, with state-based overlays where health or justice information is concerned.

Compliance with strong authentication is frequently underdone by relying parties that assume federation will handle everything. The Australian Government Information Security Manual, the Protective Security Policy Framework and the Essential Eight maturity model all apply. In practice, the identity provider may deliver a robust authentication event, but the relying party still owns session management, authorisation decisions and audit logging. Treating the federation as a turnkey security solution is one of the most common procurement errors in government ICT.

Procurement obligations strengthen the need for clarity. When a tender asks for SSO but the business case implies federation, vendors respond with proposals that match the words rather than the need. The result is a contract for a product that solves only half the problem. Agencies that map their requirements against the Digital Transformation Agency's secure cloud guidelines and the Australian Cyber Security Centre's publications tend to write clearer specifications and avoid that trap.

Common Misconceptions and Practical Pitfalls

The most persistent misconception is that buying an identity product automatically delivers federation. It does not. A product might offer excellent SSO within a single domain and yet lack the policy infrastructure to participate in a federation. Conversely, a federation agreement might be in place while the SSO experience for end users is poor, because session handling and attribute exchange have not been designed with the user in mind.

Another pitfall is underestimating the operational cost of federation. Trust frameworks need governance committees, dispute processes, regular assurance reviews and a way to retire participants that no longer meet the bar. Smaller councils and agencies sometimes enter federation pilots expecting the technology to absorb the governance overhead. It does not. Federation is as much a legal and administrative arrangement as it is a technical one.

Legacy systems also complicate the picture. Many agencies in Canberra and the broader public sector still operate line-of-business applications built decades ago, with proprietary authentication schemes. Adapting those to participate in federation requires adapters, custom code or risk acceptance. A pragmatic roadmap usually begins with SSO inside the agency, then layers federation where cross-jurisdictional benefits are clear, rather than attempting a federation-first design that leaves legacy users behind. Federation work, like any long-running program, occasionally demands a change of pace, and practitioners in the field sometimes browse quite varied material in between reviews. A curious architect might, between drafting trust framework documents, look up an international recipe for grilled yoghurt with mint just to clear their head before the next review meeting.

Agencies looking to modernise their identity platforms should start by mapping their actual trust boundaries, then choose SSO where the boundary is internal and federation where it is external. Most successful programs in Australia blend both, layering internal SSO for staff and operational systems on top of a federation layer for citizens and external partners. Readers who want a broader reading list on digital governance, enterprise architecture and the practical side of running multi-niche ICT projects can explore E-Pragati for further reading and practical references. The cost of getting identity right is small, while the cost of getting it wrong is measured in security reviews, frustrated citizens and years of rework.