Eine Relying Party fordert den Scope openid bei einem OpenID Provider an, der den Endbenutzer authentifiziert und ein ID Token mit verifizierbaren Claims über das Authentifizierungsereignis und das Subjekt zurückgibt. Das Protokoll kann außerdem ausgewählte Claims über einen UserInfo-Endpunkt liefern.
In einem üblichen Authorization-Code-Flow erhält die Relying Party einen Code über den Browser und tauscht ihn am Token-Endpunkt ein. Sie muss Signatur, Issuer, Audience, Ablauf und transaktionsbindende Werte wie nonce des ID Tokens validieren, soweit anwendbar. Provider Discovery und Registrierung können die Konfiguration automatisieren — jedoch nur innerhalb eines Vertrauensmodells, das festlegt, welche Issuer, Endpunkte, Schlüssel und Algorithmen akzeptabel sind.
Wichtigste Punkte
ProtokollrollenDer OpenID Provider führt die Authentifizierung durch und stellt Claims aus; die Relying Party validiert die Antwort und erzeugt ihre eigene Anwendungssitzung.
Getrennte ArtefakteDas ID Token nutzen, um das Authentifizierungsergebnis zu verstehen, und ein Access Token nur für die dafür vorgesehene geschützte Ressource verwenden; die Tokens sind nicht austauschbar.
Datenschutz und LebenszyklusNur notwendige Claims anfordern, stabile Identifikatoren bedacht einsetzen, Sitzungen schützen, Signaturschlüssel-Rotation managen sowie Logout- und Kontoänderungsverhalten explizit definieren.
Wichtige EinschränkungEin gültiges ID Token beweist nur die Claims und den Authentifizierungskontext, die ein vertrauenswürdiger Provider behauptet. Es begründet weder Rechtsidentität noch aktuelle Anwendungsautorisierung oder die Sicherheit der resultierenden lokalen Sitzung.