Support for OIDC introduced in WAYF

Since WAYF started out, SAML has been the only technical protocol supported for transferring logins from user organisations to services in the federation. But now we’ve developed support for services to alternatively connect to WAYF via the OpenID Connect (‘OIDC’) protocol.

OIDC has in recent years become a popular technology in integrations where SAML could well have been used – probably because it uses a simpler format (JSON rather than XML) and builds on top of the widely used authorisation protocol, OAuth2. Owing to this, more and more service providers are expected to want to be able to connect services with WAYF's user organisations via OIDC.

Unlike SAML, however, OIDC is not truly a federation protocol – i.e. within the framework of OIDC, a provider cannot readily get logins to his service from more than a single user organisation. Consequently, today OIDC is mostly used in integrations where only a single organisation's users need access to a number of services.

But now it will actually be possible for services to receive logins from any user organisations within WAYF or eduGAIN through an OIDC integration with WAYF. And that even without any of the user organisations having to do anything: Via their existing SAML integration with WAYF, they now support OIDC out of the box for services participating in WAYF. Because WAYF, being in the middle of it all, translates between SAML and OIDC (and WS Federation) as needed each time a login transaction occurs. This is new added value for the service providers and organisations participating in WAYF.

There are several flavours of the OIDC protocol and WAYF's OIDC support will be expanded as service providers demand more flavours. Initially, we implement the Implicit Flow with Form Post flavour, which will be used in the DeiC Data Storage service, WAYF's first use case for OIDC. Services must be able to receive and decrypt so-called JWEs, i.e. encrypted JSON Web Tokens. The user claims WAYF returns to the service in the OIDC token are named according to the OIDC standard schema or as in SAML, depending on what the service provider wants.