Af Mikkel Hald, 28/04/25
I WAYF tog vi hul på understøttelse af OIDC-protokollen i begyndelsen af 2023. Dengang implementerede vi kun den udgave af OIDC som kaldes id_token, hvor informationen flyder på nøjagtig samme måde som i WAYFs almindeligste protokol, SAML med HTTP POST: Tjenesten spørger gennem browseren brugerens organisation om login og modtager svaret med brugeroplysninger ad samme kanal – serverne kommunikerer ikke direkte sammen, men alene gennem brugerens browser.
Siden har det imidlertid vist sig at tjenesteudbydere som ønsker at bruge OIDC, ofte ikke understøtter id_token-flow'et, men kun det såkaldte code-flow. Derfor indfører vi nu også understøttelse for dét.
I code-udgaven af OIDC sker der i begyndelsen af flow'et det samme som i id_token-udgaven, på nær at svaret tjenesten modtager gennem browseren, ikke indeholder brugeroplysninger, men er en “kode” (en authorization code). Den skal tjenesten så “indløse” hos WAYF til en anden kode (en access token) – som den igen kan indløse til oplysninger om brugeren. De to “indløsninger” foregår ved at tjenesten spørger WAYF direkte, uden om brugerens browser; og den slags server-til-server-kommunikation ifm. loginprocesen har WAYF hidtil kun benyttet sig af i begrænset omfang.
Interesserede udbydere kan ved henvendelse til WAYF få tildelt et client_id og en client_secret. Endpoints og offenlig nøgle for WAYF som OIDC provider kan findes her. WAYF kræver ikke PKCE, men håndhæver det hvis tjenesten initierer det. Som ved id_token-flow'et gælder det at brugeroplysninger (claims) fra WAYF i udgangspunktet benævnes som i LDAP, men at andre navne kan aftales. Scopes (angivelse af ønskede brugeroplysninger) i autentifikationsanmodninger ignoreres; i stedet frigiver WAYF altid en bestemt mængde claims, som aftales ved tilslutningen.
Udbyderen som forbinder sin tjeneste til WAYF med code-flow'et, kan på nogle punkter opnå en enklere integration end ellers. Specielt opstår muligheden for at modtage NemLog-in (MitID) fra WAYF uden at brugeroplysningerne er krypteret ud over på TLS-niveauet. Digitaliseringsstyrelsens NSIS-krav om særskilt kryptering gælder nemlig kun hvis oplysningerne passerer gennem brugerens browser, hvilket de jo ikke gør i code-flow'et. Man kan altså slippe for at skulle implementere afkryptering på applikationsniveauet og vedligeholde en offentlig krypteringsnøgle i sin tjenestes konfiguration hos WAYF – sådan som man ellers er nødt til med en id_token- eller almindelig SAML-integration til NemLog-in.
Derudover er det ifølge OIDC-specifikationen faktisk tilladt ikke at validere den digitale signatur over brugeroplysningerne tjenesten læser direkte hos WAYF; og dermed kan udbyderen i teorien helt undgå at skulle håndtere algoritmer og nøgler til kryptering og signering, noget som generelt trækker tænder ud i loginintegrationer. Selv ved code-flow'et anbefaler vi dog udbyderne altid at validere signaturen på den JWT-struktur WAYF sender brugeroplysningerne i – fordi dét giver helt samme slags garanti som ved de øvrige integrationsformer for at WAYF er oplysningernes afsender: Så bruges føderationens særskilte tillidsstruktur og ikke kun den tillidsstruktur som ligger i TLS.
Foreløbig har vi kun implementeret code-flow'et for tjenester (“relying parties”); brugerorganisationers loginsystemer kan stadig kun tilsluttes WAYF via SAML eller OIDC's id_token-flow. Men uanset hvilken protokol systemerne bruger i WAYF, vil de altid kunne kommunikere sammen gennem WAYF – som i nødvendigt omfang oversætter mellem protokollerne i midten af hver logintransaktion.