Single sign-on (SSO)

Bilateral identity federation for seamless transitions between applications

A bilateral identity federation is suitable where a comprehensive SSO domain is not required but a targeted and seamless transition from an application A in which the person is already authenticated to an application B is needed.

AGOV is neither extended nor specially configured for this purpose. In particular, no SSO domains are created in AGOV and no AGOV sessions are mediated between the applications involved.

Architectural principle

AGOV authenticates the natural person to application A or its IAM. The authentication that has already taken place can then be used by application A or its IAM as the basis for issuing a new identity assertion to application B that is specifically intended for B.

The trust chain is therefore:

AGOV
  |
  | authenticates the natural person
  v
IAM / application A
  |
  | issues its own identity assertion
  | specifically intended for application B
  v
Application B
  |
  | establishes its own session
  v
Target application

This creates two separate trust relationships:

• AGOV -> application A
• Application A / IAM A -> application B

The second trust relationship is operated entirely outside AGOV.

No reuse of AGOV tokens

Application B does not trust an AGOV token originally issued for application A. A token issued for a particular relying party is not automatically intended for another relying party. In particular, audience validation must not be weakened in order to accept such a token.
The following model is therefore not intended:

AGOV
  |
  | token for application A
  v
Application A
  |
  +-> Application B

Instead, A or its IAM issues a new assertion specifically for B:

AGOV
  |
  v
IAM A
  |
  | new signed assertion
  | Audience = application B
  v
Application B

The original AGOV authentication merely provides the basis on which the issuer for application A makes its own assertion.

Roles

AGOV
AGOV authenticates the natural person as part of application A’s existing login process. AGOV does not need to know that the person subsequently accesses application B, which applications are federated with each other, which session is created at application B, or which identity assertion application A later issues to B.

Issuer for application A
The issuer is the technical and organisational trust anchor on the side of application A. Ideally, this is an IAM or Security Token Service rather than arbitrary application code. The issuer may issue identity assertions for application B only on the basis of a valid authenticated session.

Application B
Application B maintains a list of explicitly approved issuers. It fully validates every incoming identity assertion and establishes its own application session from it. Application B does not necessarily need to know the person in advance.

Example flow

1. The person is already signed in to application A. The underlying authentication may, for example, have been performed using AGOV. After successful authentication, IAM A has its own session.
2. The person selects a function in application A that leads to application B. Application A recognises the existing session and requests from its own issuer an identity assertion specifically intended for application B.
3. The issuer generates a cryptographically signed assertion. It contains only the information agreed for B and is explicitly intended for B. It may, for example, contain the issuer, audience, subject, issue and expiry times, a unique transaction identifier, the time of the underlying authentication, and the agreed identity and quality information.
4. The identity assertion is preferably transferred to application B server-to-server. The connection may additionally be protected using mutual TLS authentication (mTLS).

This allows two independent security mechanisms to be combined:

Transport layer:
Is the calling party actually the registered technical client?

and

Message layer:
Was the identity assertion actually signed by the registered issuer?

Validation by application B

Application B accepts the identity assertion only if all required checks succeed. These include in particular:

• the technical client is authorised;
• the issuer is registered;
• the signature is valid;
• the signing key is assigned to that issuer;
• the token or assertion type is the expected type;
• the audience exactly matches application B;
• issue and expiry times are plausible;
• the maximum permitted lifetime is observed;
• the unique transaction identifier has not already been used;
• the time of the underlying authentication satisfies the policy;
• the asserted authentication and identity quality is sufficient for the use case;
• the schema and mandatory information are valid.

It is expressly not sufficient merely to verify that a signature is mathematically valid. The complete registered trust relationship must be checked: technical client, issuer, assigned key, correct assertion type, correct audience, valid signature and valid time window.

One-time handover code

Following successful validation, application B may generate a cryptographically random, unguessable and very short-lived handover code. The code itself contains no personal data and can be used exactly once.
Application B associates the hash of this code server-side with the already validated identity assertion, the issuer, subject, authentication information, creation and expiry times, and the status UNUSED.

The code should have high entropy, be valid only for a very short period and be redeemable only once. For an immediate browser transition, a validity period of a few seconds up to approximately one minute at most is appropriate.

Browser transition

The browser receives only this one-time code. The transition should preferably use an HTTPS POST to a dedicated endpoint on application B.
In particular, the browser does not transport:

• an AGOV token;
• an access token from application A;
• an application A session cookie;
• an AGOV session cookie;
• the complete identity assertion;
• unnecessary personal data.

The actual trust and identity information is therefore not transported between the applications through the browser.

Redeeming the code

When application B receives the handover code, it checks that the code exists, is still valid, has not already been used and is associated with a successfully validated transaction. It then atomically marks the code as USED and creates its own session for application B.

Redemption must be atomic. Even two requests arriving at exactly the same time must not be able to use the same code twice.

Application B’s own session

Application B establishes its own session. This is independent of the AGOV session, the application A session and, where applicable, the session of application A’s IAM.

This therefore does not automatically create cross-organisational single logout. Logging out of application A does not necessarily terminate the application B session, and vice versa.

Trust model

Application B maintains an explicit registration for every approved issuer. This defines at least:

• a unique issuer identifier;
• the authorised technical client identity, mTLS where applicable;
• authorised public signing keys or a controlled key source;
• the expected audience;
• the expected assertion type;
• permitted cryptographic algorithms;
• permitted and mandatory claims;
• maximum validity period.

An identity assertion from an unregistered issuer is rejected. A valid signature from another known issuer is also insufficient if the issuer, key, technical client and audience do not belong to the same registered trust relationship.

Key management

Private signing keys remain with the respective issuer. Application B requires only the public keys for verification.

During a key change, a controlled overlap period may be used in which both the old and the new public key are accepted. The old key is then removed. A compromised issuer or key must be capable of being blocked quickly.

Changes to issuers, keys and technical clients are made through a controlled administrative process. An incoming identity assertion must not itself be able to determine which arbitrary external key or arbitrary external key source is used to validate it.

Replay protection

The architecture combines several protection layers. The identity assertion is intended only for application B, is short-lived and signed, and has a unique transaction identifier. The handover code has high entropy, is short-lived, contains no personal data and can be redeemed atomically only once.

Application B implements replay protection for transaction identifiers that have already been used. A handover code that has already been used is likewise rejected.

Meaning of an indication such as auth_source = AGOV

If application B needs to know that the original authentication was performed using AGOV, the agreed federation profile may include a corresponding indication.

For example:

Issuer = application A’s IAM
auth_source = AGOV

This means: the issuer for application A confirms that the session underlying this identity assertion was authenticated using AGOV.
It does not mean: this identity assertion was issued by AGOV.
The issuer remains application A’s IAM. For this statement, application B trusts the issuer for application A and not AGOV directly.

Authentication and identity quality

The issuer must not assert to application B a higher quality than can reliably be derived from the authentication and identity verification that actually took place.
The representation of authentication quality, identity verification quality, authentication time, authentication means used and other relevant quality characteristics must therefore form part of the agreed federation profile. Freely interpretable quality indicators should be avoided.

Data protection and data minimisation

The identity assertion contains only the information application B requires for the specific transaction. A bilateral identity federation is not a general-purpose interface for exchanging all information held about a person.
The parties must define technically and organisationally which attributes may be transferred, for what purpose they may be used, how long they are required and which party is responsible for them.

Logging

Complete identity assertions, handover codes in clear text, session cookies, private keys and unnecessary personal data should not be logged.
For security audit and traceability, it may be appropriate to log the time, issuer, pseudonymised transaction identifier, validation result, key identifier used, handover result and technical error class.

Failure behaviour

A failed handover must never result in security checks being weakened. An unknown issuer, incorrect audience, invalid signature, expired assertion, transaction identifier already used, expired or already used handover code, insufficient quality or unauthorised technical client results in rejection.
Following a failed handover, application B may offer its normal login process where appropriate.

Onboarding a new trust relationship

Before production activation, the parties involved must define at least the issuer, technical client, keys and key rotation, audience, assertion type, mandatory and optional claims, accepted authentication and identity quality, maximum lifetime, replay protection, permitted personal data, operational contacts, emergency blocking, and positive and negative conformance tests.

Security-relevant tests

Before activation, at least the following negative cases should be tested:

• forged signature;
• unauthorised signing algorithm;
• incorrect issuer;
• correct issuer with incorrect key;
• correct key with incorrect audience;
• expired assertion;
• assertion with implausible timestamp;
• reused transaction identifier;
• reused handover code;
• expired handover code;
• incorrect technical client;
• assertion from another issuer;
• assertion from another service of the same issuer;
• manipulated claims;
• unknown key;
• simultaneous double redemption.

Decoupling from AGOV

A bilateral identity federation creates no additional runtime dependency from application B to AGOV. During the actual transition, the participating systems communicate directly:

Application A <-> application B

and not:

Application A <-> AGOV <-> application B

AGOV remains limited to its original role as the authentication system.

Distinction from an SSO domain

From the user’s perspective, the result may look like SSO: the person is signed in to application A, selects application B and reaches B directly without another interactive login.

Architecturally, however, no common SSO domain is created in AGOV. Responsibilities remain clearly separated:

• AGOV: authentication of the natural person.
• Application A / IAM A: its own session and targeted identity assertion.
• Application B: validation, its own identity, its own session and its own authorisations.

A bilateral identity federation is therefore particularly suitable for individual, clearly defined transitions between applications. Where many applications within an organisation need to use SSO with one another, an intermediate IAM system or a genuine organisational SSO domain is generally the more appropriate architecture.

Use of existing standards

If application A’s IAM can already act as a standards-compliant Identity Provider towards application B, an established standard such as OpenID Connect or SAML should be used wherever possible instead of defining a proprietary transition mechanism.

The architectural principle remains unchanged:

Application B <-> IAM A <-> AGOV

and not:

Application B <-> new AGOV SSO function

The decisive point is not the specific protocol used, but the clear separation of trust relationships.

Final architectural principle

A session that has already been authenticated using AGOV can be used by a downstream IAM as the basis for a bilateral identity federation to another application.

AGOV is neither extended nor specially configured for this purpose. In particular, no SSO domains are created in AGOV, no AGOV sessions are mediated between applications, no AGOV tokens issued for other relying parties are forwarded, and no application-specific federation functions are added to AGOV.

Instead, the applications involved or their IAM systems establish their own explicitly defined and secured trust relationship. This enables a seamless transition between individual applications without making AGOV the central SSO hub between those applications.