OpenID Connect oder OIDC ist ein Identitätsprotokoll, das die Autorisierungs- und Authentifizierungsmechanismen von OAuth 2.0 nutzt. Die finale Spezifikation von OIDC wurde am 26. Februar 2014 veröffentlicht und wird mittlerweile von vielen Identitätsanbietern im Internet angewendet.

OIDC wurde von der OpenID Foundation entwickelt, der Unternehmen wie Google und Microsoft angehören. Während OAuth 2.0 ein Autorisierungsprotokoll ist, handelt es sich bei OIDC um ein Identitätsauthentifizierungsprotokoll, das zur Verifikation der Identität eines Nutzers gegenüber einem Client-Dienst, auch als Relying Party bezeichnet, dient. Zusätzlich können Claims der Nutzer wie Name, E-Mail-Adresse usw. auf Anfrage geteilt werden.

Eine Vielzahl von Clients können OpenID Connect (OIDC) nutzen, um Nutzer zu identifizieren, von einseitigen Anwendungen (Single-Page Applications, SPA) bis hin zu nativen und mobilen Apps. OpenID Connect kann auch zum Single Sign-on (SSO) für mehrere Anwendungen genutzt werden. OIDC setzt JSON Web Tokens (JWT) und HTTP-Flows ein und vermeidet es, die Anmeldedaten der Nutzer mit Diensten zu teilen.

OpenID Connect fragt nach der Zustimmung. Das ist wichtig, weil OIDC häufig in Diensten genutzt wird, die sich an Verbraucher (als Relying Party) richten und die ausdrückliche Zustimmung des Nutzers erfordern.

Diese Funktionen sowie die einfache Implementierung machen OpenID Connect zu einem nützlichen Protokoll, wenn die Identität eines Nutzers erforderlich ist, und zu einer leistungsstarken Alternative zum komplexeren Standard SAML 2.0. Es eignet sich auch insbesondere für mobile Apps.

OIDC nutzt OAuth 2.0 als zugrunde liegendes Protokoll. Die wesentlichen Erweiterungen sind ein spezieller Scope-Wert („openid“), die Verwendung eines zusätzlichen Tokens (des ID-Tokens, das die Identity-Claims in JSON-Format enthält) und der Schwerpunkt auf Authentifizierung anstelle von Autorisierung. Bei OIDC wird außerdem der Begriff „Flow“ anstelle des bei OAuth2 bekannten Begriffs „Grant“ verwendet.

Der OIDC-Anbieter (im Allgemeinen als OpenID-Anbieter, Identitätsanbieter oder IdP bezeichnet) führt die Authentifizierung und Zustimmung der Nutzer und die Ausstellung der Tokens durch. Der Client oder Dienst, der die Identität eines Nutzers abfragt, wird in der Regel als Relying Party (RP) bezeichnet. Dabei kann es sich um eine Web-Anwendung oder auch um eine JavaScript-Anwendung oder eine mobile App handeln.

Da OpenID Connect auf OAuth 2.0 aufbaut, nutzt es Tokens als einfache Identitätsebene innerhalb der zugrunde liegenden Autorisierungsstruktur. Diese Integration beinhaltet die Verwendung der folgenden Arten von Tokens:

ID-Token: Diese Art von Token ist spezifisch für OIDC. Seine primäre Nutzung im JWT-Format dient dazu, Informationen über das Ergebnis des Authentifizierungsschrittes bereitzustellen. Auf Anfrage kann es die Identitätsdaten bereitstellen, die ein Nutzerprofil beschreiben. Die Daten über das Ergebnis der Authentifizierung und das Nutzerprofil werden als Claims bezeichnet. Die Nutzerprofil-Claims können alle Daten umfassen, die der Relying Party zu Identifikationszwecken dienen, beispielsweise eine persistente ID, E-Mail-Adresse, ein Name usw.

Zugriffstoken: Dieses in OAuth2 definierte (optionale) Token mit kurzer Lebensdauer ermöglicht den Zugriff auf spezielle, in der Anfrage an den Autorisierungsserver in den Scope-Werten definierten Nutzerressourcen.

Aktualisierungstoken: Dieses Token ist ein Element aus der Spezifikation von OAuth2 und in der Regel langlebig. Es kann dazu genutzt werden, neue Zugriffstokens zu beschaffen.

ID-Tokens sollten digital signiert werden, um eine Manipulation zu verhindern. Zwecks zusätzlicher Sicherheit können sie auch verschlüsselt werden, auch wenn in vielen Fällen die Sicherheit der Transportebene (HTTPS) ausreichend ist. Für SPAs und mobile Apps ist die ID-Token-Verschlüsselung nicht empfehlenswert, da der Verschlüsselungscode leicht geknackt werden kann.

Die Wahl des OpenID-Connect-Flows hängt von der Art der Anwendung und deren Sicherheitsanforderungen ab. Es gibt drei gängige Flows:

• Implicit-Flow: Bei diesem normalerweise von SPAs genutzten Flow werden die Tokens über eine Redirect-URI direkt an die RP übermittelt.
• Autorisierungscode-Flow: Dieser Flow ist sicherer als der Implicit-Flow, da die Tokens nicht direkt zurückgesendet werden. Für native/mobile Apps und SPAs kann die Sicherheit durch Proof Key for Code Exchange erhöht werden.
• Hybrid-Flow: Eine Kombination aus Implicit- und Autorisierungscode-Flows. Hier wird das ID-Token direkt an die RP übermittelt, das Zugriffstoken jedoch nicht. Stattdessen wird ein Autorisierungscode ausgegeben, der gegen ein Zugriffstoken eingetauscht wird.

Der OpenID-Anbieter bestimmt die Methoden, die den Nutzern zur Authentifizierung zur Verfügung stehen, wenn diese sich bei ihrem IdP anmelden und möglicherweise der Freigabe ihrer Identitätsdaten an die RP zustimmen. Die OIDC-Spezifikation sagt nichts über die für die Authentifizierung der Nutzer selbst verwendeten Mechanismen aus. Der IdP kann eine Ein-Faktor- oder Multi-Faktor-Authentifizierung anbieten, z. B.

• Benutzername/Passwort
• Einmalcode per SMS oder E-Mail
• Per App generierter Code (OATH, TOTP oder HOTP)
• Biometrische Daten per App
• Föderierte Identität (z. B. Facebook, GoogleID)

Die RP kann ebenfalls Einfluss auf die IdP-Authentifizierung haben. Beispielsweise kann eine Multi-Faktor-Authentifizierung gefordert werden. Wie ein IdP Nutzer authentifiziert, ist jedoch nicht im OIDC-Umfang enthalten.

Lesen Sie unsere Einführung in IAM, um sich über weitere Themen rund um das Identitäts- und Zugriffsmanagement zu informieren.