By Mikkel Hald, 30/04/25
WAYF started supporting the OIDC protocol at the beginning of 2023. Back then, we only implemented the so-called id_token version of OIDC – where the information flows exactly like in WAYF's most common protocol, SAML with HTTP POST: The service requests a login token from the user's organisation through her browser, and receives the response via the same channel – the servers do not communicate directly with one another, only through the user's browser.
However, we've since noticed that service providers wishing to use OIDC often don't support the id_token flow, only the so-called code flow. Which is why we're now introducing support for that too.
The code version of OIDC initially has the same flow between servers and the browser as the id_token version, except that the response received by the service through the browser does not contain user information but instead is a “code” (an authorization code). This code the service must then “redeem” with WAYF for another code (an access token) – which it can then, in turn, redeem for information about the user. These two “redemptions” happen by the service querying WAYF directly, bypassing the user's browser; and this kind of server-to-server communication in the context of a login transaction has only seen limited use in WAYF up until now.
Interested service providers can can request a client_id and a client_secret from WAYF. Endpoints and public key for WAYF as an OpenID Provider can be found here. WAYF does not require PKCE but does enforce it if initiated by the service. As with the id_token flow, user information attributes (‘claims’) from WAYF are emitted with their LDAP names unless other names are agreed. ‘Scopes’ (requests for specific user attributes) in authentication requests are ignored; instead, WAYF always releases a fixed set of claims agreed upon when connecting the service to the federation.
Providers connecting their services to WAYF with the code flow in some respects can achieve a simpler integration. Notably, the option arises of receiving the Danish governmental ID, NemLog-in (MitID), from WAYF without the user information being encrypted other than at the TLS level. This due to the fact that the Danish Agency for Digital Government's NSIS requirement for application-level encryption only applies if the information passes through the user's browser, which in the code flow it obviously doesn't. And so, service providers can avoid having to implement decryption at the application level and maintain a public encryption key in their service configuration with WAYF – necessary with either id_token or standard SAML integrations with NemLog-in.
Also, according to the OIDC specification it's actually permitted not to validate the digital signature on the user information the service reads directly from WAYF; and so, the service provider can, in theory, avoid altogether having to handle algorithms and keys for encryption and signing, something generally posing challenges in login integrations. Even with the code flow, however, we do recommend providers always validate the signature of the JWT structure in which WAYF ships the user information – as doing so would give them exactly the same kind of guarantee as with the other forms of integration that WAYF is indeed the source of the information: This amounts to using the federation's own trust structure rather than just that inherent in TLS.
We've so far implemented the code flow for services (‘relying parties’) only; login systems of user organisations still can only connect to WAYF through OIDC's id_token flow or SAML. But regardless of which protocol the systems use with WAYF, they will always be able to communicate with each other through WAYF – which in the middle of each login transaction translates between the protocols as needed.