Native Apps werden immer mehr Teil unseres Alltags. Von unseren Online–Einkäufen bis hin zu Instant–Messaging-Kommunikation erleichtern Native Apps bestimmte Aufgaben. Eine große Menge dieser Apps erfordern jedoch Authentifizierung zur Bestätigung der Identität ihrer Benutzer:innen. Angesichts der Komplexität des Designs eines sicheren Authentifizierungsmechanismus in Web- und mobile-Apps wurden mehrere Authentifizierungsprotokolle von verschiedenen Organisationen entwickelt, um die Implementierung eines Authentifizierungsmechanismus zu erleichtern. Dies ist ebenfalls beim OpenID Connect-Protokoll der Fall.
‚OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.‘
Aus der obigen Definition der OpenID Organisation ergibt sich, dass das OpenID Connect-Protokoll ein Nachfolger des OAuth 2.0–Protokolls ist. Zusätzlich zur Implementierung des OAuth 2.0–Autorisierungs- und Authentifizierungsmechanismus, der ein Zugriffstoken für die Zugriffsmanagement eines Drittanbietersystems generiert, integriert das OpenID Connect-Protokoll in seinem Authentifizierungsmechanismus ein Identitätstoken zur Verwaltung von Benutzerinformationen.
Die Authentifizierung mit OpenID Connect
Die Authentifizierung mit OpenID Connect kann je nach Art der Anwendungstyp (mobil oder Web) mit unterschiedlichen Flows erfolgen. Die verschiedenen möglichen Flows sind wie folgt:
Authorization Code Flow:
- Die Client–Anwendung sendet eine Anfrage mit erforderlichen Parametern an den Autorisierungsendpunkt des OpenID–Providers, um einen Autorisierungscode zu erhalten. Der OpenID–Provider leitet den Benutzer an die Client–Anwendung mit einem Autorisierungscode in der URL weiter. Die Client–Anwendung sendet dann eine Tokenanfrage mit dem erhaltenen Autorisierungscode an den Token–Endpunkt des Providers, der die Tokens (ID Token, Access Token, Refresh Token) zurücksendet.
Implicit Flow:
- Im Gegensatz zum Authorization Code Flow werden die Tokens (ohne Refresh Token) während der Weiterleitung als Query Parameter in der URL zurückgesendet. Der Token-Endpunkt wird nicht erforderlich.
Hybrid Flow:
- Es ist eine Kombination der beiden anderen Flows. Einige Token werden vom Autorisierung-Endpunkt und andere vom Token-Endpunkt zurückgesendet.
Unter Berücksichtigung des Sicherheitsaspekts wird festgestellt, dass die Weiterleitungs–URL während der Authentifizierung durch Implicit Flow die Tokens als Query Parameter enthält. Diese Tokens sind daher über den Browser und andere Apps, die Zugriff auf den Browser haben, zugreifbar. Darüber hinaus verfügt der Implicit Flow nicht über ein Aktualisierungstoken (Refresh Token), das in native Apps erforderlich ist, um die Benutzersitzung durch die Aktualisierung des Zugriffstokens (Access Token) beizubehalten.
Authorization Code Flow – die geeignete Variante für native Apps
Der Authentifizierungsmechanismus mit dem ‚Authorization Code Flow‘ ist daher besser geeignet für Native Apps und ist in der folgenden Abbildung dargestellt:
In der obigen Abbildung wird beobachtet, dass die native App gar keine Ahnung von Anmeldedaten des Benutzers hat, da sie nur dafür verantwortlich ist, die Anmeldeseite des OpenID–Providers dem Benutzer entweder über eine externe Browseranwendung oder über eine WebView der App zu präsentieren. Sobald die Anmeldedaten der Benutzer:innen vom OpenID–Provider abgerufen und erfolgreich überprüft wurden, werden die Benutzer:innen wieder vom Browser zur Nativen App weitergeleitet. Während dieser Weiterleitung zur App wird ein Autorisierungscode über ein URI–Schema übergeben. Mittels dieses Autorisierungscodes kann die Native App vom OpenID–Provider einen Identitätstoken zur Authentifizierung und ein Zugriffstoken zur Autorisierung erhalten.
Zusätzlich zum generierten Zugriffstoken (Access Token), wie beim OAuth 2.0–Protokoll werden auch ein Identitätstoken (ID Token) und ein Aktualisierungstoken (Refresh Token) vom OpenID–Provider generiert. Dieses Identitätstoken dient als Benutzerausweis, da es die Informationen dieses Benutzers enthält. Das Identitätstoken ist ein einfaches JSON–Objekt, das mit dem JWT–Standard (JSON Web Token) generiert wurde. Das heißt, es enthält eine Signatur, die vor der Verwendung überprüft werden muss. Das Aktualisierungstoken dient als Hauptschlüssel, da es dem OpenID–Provider die Generierung eines neuen Zugriffstokens ermöglicht, wenn das alte abgelaufen ist. Auf diese Weise können native Apps dem Benutzer den Eindruck erwecken, für einen bestimmten Zeitraum eingeloggt zu bleiben. Aus diesem Grund muss Aktualisierungstoken sicher in der App gespeichert werden, damit keine andere App darauf zugreifen kann.
E–Commerce–App als Beispiel für die Nutzung des Authorization Code Flow
Zum einfachen und praktischen Verständnis dieses Protokolls kann eine Native E-Commerce–App als Beispiel verwendet werden. Angesichts der Sensibilität der von dieser Art von Services verwendeten personenbezogenen Daten muss ein Authentifizierungs- und Autorisierungsmechanismus eingerichtet werden. Entwickler:innen können sich für die Verwendung dieses OpenID Connect–Protokolls entscheiden, um die Entwicklung Ihres eigenen Authentifizierungsmechanismus zu vermeiden. Nach der Konfiguration des Management–Servers von OpenID–Connect-Protokoll konfigurieren die Entwickler:innen den Management–Server von Ressourcen, der die vertraulichen Daten der Benutzer:innen enthält, wie z. B. die Adresse, die Kreditkarteninformationen, usw. Dieses Beispielszenario wird wie in der folgenden Abbildung aufgebaut:
- App => Hier ist der Benutzername: „Mueller“ und das Passwort: „Mueller-652“
- OpenID Server => Das Access Token von Benutzer „Mueller“ lautet “hjz74zj56*jtß06JHmbkj” und sein ID Token lautet “lgfnbn/8Gdf7568ju57”gf8gfd5fd%rg“
- App => Gib mir die Kreditkarteninformationen des Benutzers mit Access Token “hjz74zj56*jtß06JHmbkj”
- Ressourcen Server => Ist das Access Token: “hjz74zj56*jtß06JHmbkj” gültig?
- OpenID Server => ja, es ist gültig. Das gehört zum Benutzer mit Benutzername „Mueller“
- Ressourcen Server => Hier sind die Kreditkarteninformationen von Benutzer „Mueller“ mit Access Token “hjz74zj56*jtß06JHmbkj” { … }
Wie hilft OpenID Connect den Entwickler:innen?
Zusammenfassend vereinfacht der Authentifizierungs- und Autorisierungsmechanismus einer nativen App unter Verwendung des OpenID Connect–Protokolls die Aufgabe der Entwickler:innen. Dank der vom OpenID–Provider erhaltenen Token kann die native App die Identität ihrer Benutzer:innen, ihre Rollen und die für sie autorisierten Aktionen auf einfache Weise verwalten.
Artikel von Francis Ngeukam Pamjo
