ISO-standaardisatie voor OpenID Connect na tien jaar rond

De OpenID Foundation heeft negen OpenID Connect-specificaties formeel erkend als ISO/IEC-standaarden. Deze ontwikkeling komt ruim tien jaar na de initiële publicatie van de definitieve specificaties in 2014.

Het aanvraagproces voor de ISO-standaardisatie werd ongeveer een jaar geleden in gang gezet en is nu succesvol afgerond. Deze officiële erkenning moet de adoptie van OpenID Connect verder versnellen. De erkenning door het standaardenorgaan ISO maakt implementatie mogelijk in regio's waar wetgeving het gebruik van gecertificeerde specificaties voorschrijft.

OpenID Connect, dat fungeert als authenticatielaag boven op OAuth 2.0, wordt gebruikt bij het inlogproces van een groot aantal websites en apps. Deze technologie stelt gebruikers in staat om via één identiteitsprovider toegang te krijgen tot verschillende diensten zonder telkens opnieuw inloggegevens te hoeven invoeren. Een belangrijk voordeel is de verhoogde veiligheid door het elimineren van traditioneel wachtwoordbeheer, wat vaak een zwakke schakel vormt bij datalekken.

Reacties (15)

[The Zep Man]

OpenID Connect, dat fungeert als authenticatielaag boven op OAuth 2.0, wordt gebruikt bij het inlogproces van een groot aantal websites en apps. Deze technologie stelt gebruikers in staat om via één identiteitsprovider toegang te krijgen tot verschillende diensten zonder telkens opnieuw inloggegevens te hoeven invoeren.

Klopt. Je kan dit zelfs kleinschalig met weinig systeemmiddelen inzetten met selfhosting. Zo kan je Authelia gebruiken als frontend authenticatie- en autorisatieserver, een reverse proxy (zoals HAProxy) om het webverkeer te routeren, en iets als LLDAP als backend voor accountbeheer. Dat krijg je zelfs op een Raspberry Pi Zero aan de praat, al zou je dat willen.

Een belangrijk voordeel is de verhoogde veiligheid door het elimineren van traditioneel wachtwoordbeheer, wat vaak een zwakke schakel vormt bij datalekken.

Dit heeft niets te maken met OpenID Connect (OIDC). OIDC stelt je in staat om single-sign on (SSO) te implementeren. Je kan nog steeds de authenticatie voor SSO met (enkel) een wachtwoord via OIDC uitvoeren, al zou je dat willen.

Zonder SSO zou je bijvoorbeeld nog steeds al je diensten direct kunnen koppelen aan LDAP om zo overal in te kunnen loggen met een enkel wachtwoord. Je hebt dan wel het nadeel dat je overal een wachtwoord moet invullen, en dat het implementeren van MFA een stuk lastiger wordt. Dat zijn nadelen van geen SSO gebruiken (bijvoorbeeld via OIDC).

Er zijn ook andere vormen van SSO. Zo ondersteunt Authelia bijvoorbeeld ook het meesturen van "trusted headers" die aan een backend webservice aangeven welke geauthenticeerde gebruiker het betreft en in welke groepen die zit. Dit vereist wel meer configuratie, want (in tegenstelling tot OIDC) er vindt geen autthenticatie plaats tussen webservice en Authelia. Het beste is dan bijvoorbeeld IP whitelisting in combinatie met een goed afgestelde reverse proxy, zodat de browser niet geniepig dergelijke headers vroegtijdig kan injecteren.

Qua dat is OIDC een slag beter, want het neemt wat hoofdpijn weg. Langzaamaan wordt het vaker en beter ondersteund.

[Reactie gewijzigd door The Zep Man op 12 november 2024 15:28]

[GerhardBurger]

Ik ben zelf net een 2 weken bezig met Authentik (https://goauthentik.io/) voor mijn selfhosted dingen. Zat wel te twijfelen tussen Authelia en Authentik, een van de dingen die ik prettig vond aan Authentik is dat ik social logins (bv. Google) kon koppelen aan mijn Authentik account.
Ben wel benieuwd naar de redenen om voor Authelia te kiezen (dan kan ik evt. nog overstappen voordat ik er nog meer tijd in stop )

[The Zep Man]

Ben wel benieuwd naar de redenen om voor Authelia te kiezen (dan kan ik evt. nog overstappen voordat ik er nog meer tijd in stop )

Authelia gaf ik enkel als voorbeeld. Je hebt ook anderen zoals Authentik en Keycloak.

Authelia kan je kiezen als je alles zelf host, geen afhankelijkheid hebt van/integraties wenst met externe partijen, en als je inzet op het gebruik van weinig systeemmiddelen. Een ander iets dat overwogen kan worden is dat Authelia geen commercieel/enterprise oogmerk heeft. Mijn ervaring is dat er daardoor minder ruimte is voor enshittification, de noodzaak voor forks, (toekomstig) gezeur met licenties (geen onzin als Contributor License Agreements), etc. Bij Authentik is er wat ruimte voor, ook omdat de licentiesituatie een stuk complexer is (meer soorten licenties op verschillende onderdelen).

Dat zegt overigens niet dat Authentik slecht is. Als het voor je werkt, gebruik het! Het is van wat ik begrijp een stuk makkelijker in gebruik, o.a. omdat user management geïntegreerd is. Dat ik Authelia zou prefereren bij het maken van een keuze komt meer vanuit een combinatie principes + technische know-how + een liefde voor bijzonder efficiënte software. Er zijn geen harde redenen in mijn overweging.

[Reactie gewijzigd door The Zep Man op 12 november 2024 14:27]

[GerhardBurger]

Dank voor je reactie, goede punten, ga ik in mijn achterhoofd houden!
(en die user management gebruik ik, goed om te weten dat Authelia dat niet heeft)

[d3burt]

Ik gebruik zelf oauth2proxy als "voorzetstuk" voor applicaties met matig gebruikersbeheer, en keycloak voor de authentificatie. Ik heb ook authentik en authelia bekeken, allebei met eigen voor en nadelen, maar alle drie robuuste keuzes.

Ik vind ze allemaal trouwens stuitend complex, waardoor het te makkelijk is een autorisatie in te richten die veel te breed rechten toekent (denk bijvoorbeeld aan Microsoft's blunder waardoor een willekeurig geldig account in een willekeurige tenant in Azure genoeg was om het Bing control panel te kunnen bedienen).

Ook aansluiting vinden met applicaties is vaak een drama. OIDC kent zoveel variaties dat je per applicatie, per OIDC implementatie een apart recept nodig hebt. Ik heb het voor Odoo inmiddels werkend met Keycloak, maar dat is met onofficiele patches op Odoo en daar hou ik niet van. Het moet zonder kunnen, maar daarvoor moet je Odoo's implementatie reverse engineeren om te kijken hoe je Keycloak kunt inrichten op een manier die Odoo lust...

[BCC]

Wordt het dan ook meer gestandaardiseerd ipv een variant voor Azura, eentje voor Google, eentje voor Keycloak, eentje voor Okta, etc etc?

[rko4u]

Uiteindelijk moet je systeem wel weten wie de key mag valideren. Anders zou je probleemloos zelf een key kunnen genereren en daarmee kunnen inloggen, met alle risico van dien.

[Cilph]

Klopt, maar de grote partijen hebben allemaal kun kleine afwijkingen op de OIDC spec, dus je hebt vaak niet "gewoon" een OIDC connector maar een aparte voor Google, Azure, ADFS,... en dan "Generic OIDC"

[Reactie gewijzigd door Cilph op 12 november 2024 12:53]

[mocem]

Uiteindelijk werkt generic OIDC ook je moet alleen veel meer uitzoeken en debuggen. De eigen connectoren geven zover ik weet de presets mee die je vaak nodig heb.

[zenlord]

De technologie was al gestandaardiseerd, dus iedere implementatie zou er zich aan moeten houden.
Nu is de standaard ook door het ISO orgaan erkend.

[CAPSLOCK2000]

Wordt het dan ook meer gestandaardiseerd ipv een variant voor Azura, eentje voor Google, eentje voor Keycloak, eentje voor Okta, etc etc?

Eerlijk gezegd ligt dat meer aan die organisaties dan aan de standaard.
De meesten willen eigenlijk dat iedereen hun systeem gebruikt en accepteren geen gebruikers van andere diensten. Ik weet niet of het een gebrek aan vertrouwen in anderen is of datahonger, maar als de grote bedrijven onderling compatible willen zijn dan kan dat al lang. Het lijkt vooral een bewuste kueze om het niet te doen. Pas als de techreuzen elkaars identiteiten gaan accepteren komen we ergens.

Dat er nu een officiele ISO-standaard is verandert weinig aan de praktijk, wat er in die standaard staat is al lang bekend.
Ik vrees dat dat pas komt als de overheid zich er mee bemoeit en (bv) verplicht stelt dat je met Nationale "Digitale Paspoort" (digid/idin/kiesmaarwat...) moet kunnen inloggen.

[Reactie gewijzigd door CAPSLOCK2000 op 12 november 2024 19:09]

[roelboel]

Hopelijk zorgt dit ervoor dat de veiligheidsramp die SAML heet eindelijk eens de deur uitgaat.

[cheerio77]

Een weinig onderbouwde stelling.

OpenID connect is niet per se veiliger dan SAM, SAML is ouder, maar voldoet zeker nog, en ja OIDC heeft zeker de toekomst. maar voor beide protocollen geldt dat deze staan of vallen met een goede implementatie. Een slechte OIDC implementatie is nog steeds onveiliger dan het degelijke SAML implementatie.

Tip: gebruik libraries, ga dit niet zelf doen.

[roelboel]

De onderbouwing: afgezien van dat SAML eindeloos complex is gebruikt het XML signatures, een eindeloze bron van kwetsbaarheden. XML signatures zijn in de praktijk nauwelijks goed te implementeren. Enkele maanden geleden nog in, zoals je adviseert, een library: https://ssoready.com/blog...gnature-wrapping-attacks/

[alienfruit]

Welke versie van de RFC is dit dan? Zijn de RFC documenten ook geüpdatet? ISO documenten kosten klauwen met geld. Maar OIDC in combinatie met SCIM werkt wel lekker.