By Mikkel Hald, 28/05/25
WAYF recently launched support for the code flow version of OIDC, publishing on this website the configuration data required for connecting a service to WAYF through that protocol.
Some relying-party OIDC libraries allow service providers to manually specify all configuration information for OpenID Providers (authentication sources), but far from all of them: Many instead presuppose the configuration being available somewhere online, in a standard format. Which is why we now publish the configuration for WAYF as an OpenID Provider that way as well, viz. at the URL https://wayf.wayf.dk/oidc/config/.well-known/openid-configuration.
In addition, we've now also made it possible, for service providers preferring that, to obtain a direct OIDC connection to each of WAYF's user organisations: Each organisation (as well as NemLog-in) now appears as a self-contained OpenID Provider with its configuration on https://wayf.wayf.dk/oidc/config/domain/.well-known/openid-configuration, domain being the DNS domain of the organisation. As an example, Aalborg University's configuration as an OpenID Provider in WAYF can be fetched from https://wayf.wayf.dk/oidc/config/aau.dk/.well-known/openid-configuration. Even though WAYF's server is in fact part of the login flow, users have the exact same experience as if the service were truly directly connected to an OpenID Provider at the organisation: WAYF is invisible to them.
It is no coincidence that all these URLs end in /.well-known/openid-configuration: Many OIDC libraries understand this convention and only want the initial part of the URL, e.g. https://wayf.wayf.dk/oidc/config/aau.dk for Aalborg University, specified as the online location of the OpenID Provider's configuration.
Service providers obtaining OpenID Provider configurations this way, however, must understand – and accept any risk related to the fact – that the federation's special trust structure is not in force for them in these cases: OIDC configuration data are, as opposed to our SAML metadata, not digitally signed with the federation's special private key for metadata – making the very TLS connection to wayf.wayf.dk, from where the data are read, the only kind of proof the configuration really originates from WAYF. That's a crucial difference from the SAML protocol.