Zum Inhalt springen
Skycloak
Anwendungsfall

Mobile-App-Authentifizierung für native iOS- und Android-Apps

Gute Mobile-App-Authentifizierung öffnet für die Anmeldung den Systembrowser, nutzt den Authorization Code Flow mit PKCE aus OAuth 2.1 und hält den Benutzer mit einem Offline-Refresh-Token angemeldet, das bei jeder Nutzung rotiert. Die Skycloak Platform ist dafür gebaut, diese Anmeldung für Ihre nativen Apps zu übernehmen, sodass Ihre App nie selbst mit einem Passwort umgeht.

Warum sich native Apps über den Systembrowser anmelden

Eine native App, die eigene Felder für Benutzername und Passwort zeigt oder die Anmeldeseite in einer eingebetteten Web View lädt, kann das Passwort des Benutzers mitlesen und gewöhnt Benutzer daran, es in jeden Bildschirm einzutippen, der danach fragt. Empfohlen ist für native Apps, die Anmeldeseite im Systembrowser zu öffnen oder in dem In-App-Browser-Tab, den das Betriebssystem bereitstellt und in den Ihre App nicht hineinsehen kann. Der Benutzer meldet sich dort an, und der Browser gibt über eine Weiterleitung einen Autorisierungscode an Ihre App zurück. Weil der Browser die Sitzung und die gespeicherten Zugangsdaten des Benutzers schon kennt, geht die erneute Anmeldung oft schneller als das Ausfüllen eines Formulars.

Eine mobile App kann kein Client-Secret geheim halten, weil jeder die App entpacken und es auslesen kann, deshalb schreibt OAuth 2.1 für diesen Ablauf PKCE (Proof Key for Code Exchange) vor. Die App erzeugt für jede Anmeldung ein zufälliges Geheimnis, sendet einen Hash davon mit der Anfrage und das Geheimnis selbst, wenn sie den Code gegen Tokens eintauscht. Eine andere App, die die Weiterleitung abfängt, erhält einen Code, mit dem sie nichts anfangen kann, weil ihr das Geheimnis fehlt. Die Plattform spricht OpenID Connect und OAuth 2.1, sodass jede Standard-Clientbibliothek, die diesem Muster folgt, Ihre Benutzer anmelden kann.

Wie Offline-Refresh-Tokens Benutzer angemeldet halten

Benutzer erwarten, dass sich eine mobile App tagelang an sie erinnert, während Zugriffstokens nur Minuten gelten sollten, also braucht die App ein Refresh-Token, um im Hintergrund neue Zugriffstokens zu holen. Die Plattform ist darauf ausgelegt, dass eine App, die den Scope offline_access anfordert, ein Offline-Refresh-Token erhält, das von der Single-Sign-On-Sitzung des Browsers getrennt ist und nicht mit ihr endet. Geplant ist eine Laufzeit von standardmäßig 7 Tagen, die Sie für jede App auf bis zu 30 Tage verlängern können sollen. So können Sie für eine App mit sensiblen Daten eine kürzere Laufzeit und für eine App, bei der eine erneute Anmeldung nur stören würde, eine längere wählen.

Das Offline-Refresh-Token soll bei jeder Nutzung rotieren, das heißt, jede Aktualisierung liefert ein neues Token und zieht das alte zurück. Wird ein altes Token noch einmal vorgelegt, ist die Wiederverwendungserkennung darauf ausgelegt, das als Zeichen einer Kopie zu werten, sodass eine gestohlene Kopie nutzlos wird. Das Token soll außerdem widerrufen werden, wenn sich der Benutzer von dieser App abmeldet, wenn Ihr Backend den Widerrufs-Endpunkt aufruft oder wenn ein Administrator es widerruft, und die Abmeldung von einer App soll nur deren Token beenden, sodass der Benutzer in Ihren anderen Apps angemeldet bleibt.

Passkeys und Multi-Faktor-Authentifizierung auf dem Smartphone

Ein Passkey ist ein Anmeldeschlüssel, der auf dem Gerät des Benutzers gespeichert und per Fingerabdruck, Gesichtserkennung oder Geräte-PIN entsperrt wird, sodass es kein Passwort zum Eintippen oder Abfischen gibt. Smartphones eignen sich gut für Passkeys, weil der Schlüssel auf dem Gerät liegt, das der Benutzer ohnehin in der Hand hält, und das Betriebssystem ihn mit seinen anderen Geräten synchronisieren kann. Da Ihre App sich über den Systembrowser anmeldet, kommt die Passkey-Abfrage vom Betriebssystem, und Ihre App braucht keinen eigenen Passkey-Code.

Passkeys und Multi-Faktor-Authentifizierung stehen im Plan der Plattform, zusammen mit einer Prüfung auf kompromittierte Passwörter für Benutzer, die sich noch mit Passwort anmelden. Jede Umgebung Ihrer App, etwa Produktion und Staging, ist ein eigener Mandant mit eigenen Benutzern und eigener Anmeldeadresse, sodass sich Testkonten nie mit echten Konten vermischen. Wir nennen eine Funktion erst verfügbar, wenn sie ausgeliefert ist, und in einer Demo sehen Sie, welche davon Ihre mobile App heute nutzen kann.

Häufige Fragen

Sollte eine mobile App für die Anmeldung eine eingebettete Web View nutzen?

Nein. Mit einer eingebetteten Web View kann die App mitlesen, was der Benutzer eintippt, und sie teilt weder die gespeicherte Sitzung noch die Passkeys des Browsers. Nutzen Sie den Systembrowser oder den In-App-Browser-Tab des Betriebssystems, mit dem Authorization Code Flow und PKCE.

Wie lange bleibt ein Benutzer in einer mobilen App angemeldet?

Auf der Plattform so lange, wie das Offline-Refresh-Token der App gültig ist, mit geplanten 7 Tagen als Standard und bis zu 30 Tagen, wenn Sie das für die App so einstellen. Eine Abmeldung in der App, ein Widerrufsaufruf oder ein Administrator soll es früher beenden.

Sehen Sie sich die Skycloak Platform selbst an

Buchen Sie eine Demo, und wir zeigen Ihnen die Plattform mit Blick auf Ihre eigenen Anmeldeabläufe.