WeftID 2.0 passes the OpenID Foundation conformance suite in both directions: as an OpenID Provider toward applications, and as a relying party toward upstream providers. Passing it changed provider behaviour that existing OIDC applications can depend on, so this is a major version.
1.11 made WeftID an OpenID Provider and 1.12 added upstream OIDC providers. Both were verified by WeftID's own tests and by trying them against a handful of libraries and providers.
What the suite tests
The conformance suite is written by the OpenID Foundation and used for its certification program, so the tests in 2.0 come from the authors of the specifications instead of from the author of the implementation. The run covers 177 test modules across 13 test plans. The 1.x releases worked with the libraries they were tried against and still failed it. An application built on a standard OIDC library, or an upstream provider that follows the specification, now needs no WeftID-specific handling.
The suite tests protocol behaviour. It is not a security audit, and it says nothing about the parts of WeftID outside OIDC.
What the suite checks, and what it found in 1.x
Most of the modules are about what an implementation refuses. The suite sends a token with the wrong issuer or a broken signature, redeems an authorization code twice, asks for a redirect to an unregistered address, and posts malformed logout tokens, then checks that each one is rejected in the way the specification prescribes. A sign-in through an ordinary OIDC library exercises none of this.
In 1.x, the provider put user claims in the ID token, wrapped token errors in a non-standard object, and did not rotate refresh tokens. The upstream connector refused a valid ID token that carried no key ID, and merged a UserInfo response without checking that it described the same user as the ID token. All of these are fixed in 2.0.
The suite runs nightly in CI. A run fails on any result that is not on a checked-in list of accepted deviations, so a change that breaks conformance is caught before a release.
What passes
As a provider, WeftID passes the Basic, Config, Form Post, RP-Initiated, Front-Channel, Back-Channel, and 3rd Party-Init profiles. It passes the Dynamic profile with one accepted failure: that profile requires the implicit flow, and WeftID issues authorization codes only. As a relying party, it passes the Basic, Config, RP-Initiated, and Back-Channel profiles.
The conformance page publishes the suite's output, including every accepted warning and skipped test with the reason. WeftID is not "OpenID Certified". That mark requires a formal submission to the OpenID Foundation, which has not been made.
Sign-out
Until now, signing out of WeftID cleared the session cookie in the browser and nothing else. In 2.0 the session is revoked on the server, and the sign-out travels to the systems on either side.
Toward applications, an OIDC app can sign the user out of WeftID, and when a WeftID session ends, every OIDC app that session signed in to is notified, through the browser or server to server. Refresh tokens issued with that sign-in stop working. Deactivating a user notifies the same apps.
Toward identity providers, an upstream OIDC provider can end the WeftID sessions it started, and WeftID can sign the user out at the provider when they sign out of WeftID. A logout request from a SAML identity provider now ends the WeftID session instead of only being acknowledged.
New ways to connect an application
- Device sign-in. A command-line tool or a TV app shows a short code, and the user approves it in a browser on another device.
- Client registration. An application can register itself as an OIDC app. It is off by default, and an admin decides who may register and whether a new app is open to anyone before access is granted.
- Private key JWT. An app or service account can authenticate with its own key pair instead of a client secret.
- Pairwise subject identifiers. An app can receive a user identifier that no other app shares, so two apps cannot match users between them.
- Token introspection and revocation. An API backend can ask WeftID whether a token is still valid, and an app can revoke its own tokens.
WeftID also remembers a user's consent per application, listed and revocable under Authorized Apps, and an OIDC app can appear in My Apps next to SAML applications. An upstream OIDC connection can map a group claim into WeftID groups, as SAML connections already do.
Upgrading from 1.x
Four changes can require work outside WeftID:
- The ID token no longer carries
email,profile, orgroupsclaims. They come from the UserInfo endpoint, which most OIDC libraries call already. - Refresh tokens rotate. Each refresh returns a new refresh token, and the old one stops working.
- Token endpoint errors follow RFC 6749 and are no longer wrapped in a
detailobject. - SAML Single Logout messages are signed and verified. An identity provider that sends unsigned logout requests has to be configured to sign them.
The changelog has the full list.
2.0 also fixes two security defects present in 1.x: CSRF protection on forms was not enforced, and SAML sign-in to an application could complete on a WeftID session that had expired or belonged to a deactivated user. Fixes are released for the latest version only, so 1.x installs should upgrade.
Social sign-in and Google Workspace directory sync are still next on the roadmap.