OpenID Connect Authentifizierungsablauf (mit KeyCloak) in einem Mobile App + REST-Backend

Ich möchte das REST-Backend unserer mobilen App mit OpenID Connect sichern. Kurz gesagt, Benutzer der App sollten sich selbst authentifizieren (Benutzername / Passwort), bevor sie sensible Daten über das REST-Backend (mehrere Dienste) abrufen.

Nach der ersten Authentifizierung sollten sie ein ID / Access-Token erhalten, das sie dann für die restliche App-Sitzung für die Service-Kommunikation verwenden können. Es ist sehr wichtig, dass ich dieses ID-Token bekomme, da es Informationen enthält, die vom Backend benötigt werden.

Als Identität Für die Implementierung dieses Szenarios möchte ich KeyCloak verwenden. Ich bin mir jedoch nicht sicher über den besten zu implementierenden Authentifizierungsfluss. Ich lese dies und dies stackoverflow Beiträge aber Ich bin mir immer noch nicht sicher, ob meine gewünschte Lösung gültig / sicher / akzeptabel ist.

Nach dem, was ich über openID Connect gelesen habe, ist der empfohlene Authentifizierungsfluss von openID Connect der "3-strängige Autorisierungscode-Fluss ", der Folgendes beinhaltet:

1. Umleiten des Benutzers auf die Anmeldeseite des Identity Providers (in meinem Fall KeyCloak) zur Authentifizierung (z. B. Anmeldeformular).
2. nach erfolgreicher Authentifizierung leitet die IP den Benutzer zurück an die App zusammen mit einem Authentifizierungscode, der als Anforderungsparameter übergeben wird.
3. Die App kann dann die ID / Access-Token von der IP abrufen, indem sie diesen Authentifizierungscode an den "standardisierten" Token-Endpunkt übergibt.

Das klingt alles sehr gut für eine browserbasierte Webanwendung, aber in unserer App möchten wir die externe Anmeldeseite vermeiden und stattdessen eine "lokale" In-App-Anmeldeseite verwenden, um die Benutzererfahrung nicht zu sehr zu beeinträchtigen . Außerdem verfügt unsere App über eine Funktion, die Sie "eingeloggt" hält. In diesem Fall meldet sich der Benutzer nur einmal an und alle Token werden dann im Hintergrund von der App abgerufen, wenn sie gestartet wird.

Also, basierend auf unseren Anforderungen fand ich diesen Blogbeitrag , die einen zweibeinigen Resource Owner Credentials-Flow Ansatz verwendet, der es der App ermöglicht, sich zu authentifizieren UND die Token in der ONE-Anfrage zu sammeln, ohne zur Keycloak-Anmeldeseite navigieren zu müssen.

Ich habe das getestet und diese Lösung scheint genau die Funktionalität zu bieten, die wir brauchen. Auch in unserem Fall werden die App und KeyCloak (= Self-Issued OpenID Provider) ausschließlich intern genutzt und gehören derselben juristischen Person an.

Ist es in unserem Anwendungsfall erlaubt, den zweibeinigen Ansatz zu verwenden, und wenn nicht, warum nicht? Verursacht dieser Ansatz einige Sicherheitsrisiken, die der 3-beinige Ansatz nicht hat?

Ich hoffe wirklich von euch zu hören!

Grüße,

Kim Niederlande