Skip to main content

Applications over SAML and RS256

Applies to: identity 0.27 · Checked: 26.09.2026

Identity is the sign-in provider for the organisation's applications. Most of them speak OpenID Connect, but there are two common exceptions, and both are covered:

  • an application that speaks only SAML 2.0 (older wikis, trackers, boxed systems);
  • an OIDC application whose library verifies only RS256 signatures.

In both cases the person sees identity's usual sign-in page: password, second factor, passkeys, sign-in through the company provider — the same as for every other application.

An OIDC application that needs RS256​

By default identity signs ID tokens with EdDSA. Beside that key lives an RSA-2048 key, published in the JWKS (/oauth/jwks, kty: RSA) and listed in discovery. For an application to receive ID tokens signed with RS256, set in the identity console, Applications → Edit, in options:

{ "id_token_alg": "RS256" }

Access tokens stay EdDSA — only identity itself reads them.

An application over SAML​

Sign-in started at the application (SP-initiated Web SSO) is supported, over the HTTP-Redirect and HTTP-POST bindings.

  1. Give the application identity's metadata:

    https://<identity address>/saml/metadata

    It carries identity's entity ID (https://<identity address>/saml), the sign-in address /saml/sso and the signing certificate. If the application cannot read metadata from an address, copy those three values by hand.

  2. Register the application in the identity console, Applications → SAML applications → New:

    FieldWhat it is
    entity_idthe application's entity ID — from its settings or metadata
    namethe name the person sees on the sign-in page
    acs_urlsits Assertion Consumer Service addresses; the response goes only there, matched exactly
    nameidwhat to name the person by: username (the account name) or email
    attributeswhether to send the attributes username, email, displayName, groups

  3. Try it: open the application and press its "Sign in with SSO".

The assertion is signed (and so is the whole response): RSA-SHA256, SHA-256 digest, Exclusive C14N canonicalization. Its audience is the application's entity ID, its recipient the ACS address, it refers to the application's request and is valid for five minutes. groups are identity's group ids, as in OIDC.

What is not there
  • Sign-in started at identity (IdP-initiated) is refused on purpose: it is the flow sign-in forgery attacks start from. Sign-in always starts at the application.
  • The application's request signature is not checked. The request is bound to the application by its registration and the exact ACS address — the response goes nowhere else.
  • No Single Logout, no encrypted assertions, no import of the application's metadata.

If nameid is email and the account has no address, the application receives an InvalidNameIDPolicy refusal. Every sign-in and refusal is written to identity's audit log as saml.sso; registry changes as saml.sp.put and saml.sp.delete.

Key rotation​

A rotation (POST /control/oidc/keys/rotate) replaces both keys at once — EdDSA and RSA. The old certificate stays in the metadata while tokens it signed are alive, so an application that re-reads the metadata moves to the new one by itself. An application with the certificate pasted in by hand needs the new one pasted after a rotation.

On an installation with certified GOST cryptography there is no RSA key: RS256 and SAML are not available there, and the console says so at registration.