Authentifizierungs-Flow in React Native

Profildaten speichern, Highscores auswerten, Warenkörbe auslesen oder Änderungen am Kundenkonto vornehmen – immer dann, wenn man kundenspezifische Informationen serverseitig ablegen möchte, kommt man um einen Authentifizierungsmechanismus nicht herum.

Ziel dieses Artikels ist es, Best Practices für die clientseitige Implementierung der verschiedenen Authentifizierungsmechanismen in React Native vorzustellen. In den Code-Beispielen verwenden wir mit Firebase Auth einen der populärsten Authentication Provider, die vorgestellten Patterns lassen sich aber ebenso für proprietäre Systeme oder andere Authentifizierungsanbieter anwenden, die JSON Webtoken basierte Authentifizierung unterstützen.

Für das State Management verwenden wir das Bordmittel React Context, als Navigations­komponente React Navigation. Auch hier gilt, dass sich die vorgestellten Methoden auf alternative State Management Systeme (z.B. Redux, MobX oder Recoil) und Navigations-Bibliotheken (z.B. React Router Native) übertragen lassen.

JSON Web Tokens haben eine begrenzte Gültigkeit und müssen daher von Zeit zu Zeit vom Authentication Server erneuert werden. Zu diesem Zweck erzeugt der Authentication Server immer parallel ein sogenanntes Refresh Token, mit dessen Hilfe der Client ein neues Access Token anfordern kann. So besteht keine Notwendigkeit mehr, Benutzername und/oder Passwort des Users clientseitig zu speichern, nach einmaliger Anmeldung durch den Benutzer erfolgen alle weiteren Anfragen nur mithilfe des Access Tokens und ggf. des Refresh Tokens.

Der vom Client auslesbare Payload eines JSON Web Tokens enthält üblicherweise neben dem Ablaufdatum des Tokens eine eindeutige Nutzerkennung und zusätzliche sogenannte Custom Claims, die Auskunft über die Zugriffsrechte des Users geben – also z.B. Nutzerrollen o.Ä.

Schließlich aktivieren wir in der Firebase Console unter Authentifizierung noch die Authentifizierungs-Methode „E-Mail" und sind für die clientseitige Integration startbereit.

Die serverseitige Einbindung betrachten wir weiter unten.

Unserem React Native Projekt fügen wir nun nur noch das Firebase JavaScript SDK hinzu:

expo install firebase

Den Aufruf von initializeApp(…) platzieren wir z.B. in der App.js, wobei darauf zu achten ist, dass die Konfiguration z.B. per ENV-Parameter übergeben wird und nicht im Klartext in unserem Repo landet.

Es sei darauf hingewiesen, dass Firebase in der Standardkonfiguration Registrierungen ohne Verifizierung der E-Mail-Adresse durchführt, was zumindest in Europa eher unüblich ist.

E-Mail-Verifizierung kann aber selbstverständlich konfiguriert werden, das Firebase SDK bietet hierzu die Funktion sendEmailVerification an, weitere Details hierzu finden sich unter https://firebase.google.com/docs/auth/web/manage-users.

Standardmäßig verwendet das Firebase SDK das Persistenzmodell LOCAL, was bedeutet, dass Access Token und Refresh Token im App Storage abgelegt werden und bei einem Neustart der App automatisch wieder daraus geladen werden. Der Nutzer meldet sich also nur einmalig in der App an, bei zukünftigen App Starts erfolgt die Anmeldung per Token ohne Nutzerinteraktion.

Für den Zugriff auf besonders sensible Informationen kann das Persistenzmodell jedoch auch geändert werden, hierfür stellt das Firebase SDK die Funktion setPersistence bereit, die neben LOCAL die Persistenzmodelle SESSION und NONE unterstützt (Quelle: https://firebase.google.com/docs/auth/web/auth-state-persistence).

Unsere App verfügt nun über einen Registrierungs- und Anmeldemechanismus, den wir beim Aufruf von API-Methoden verwenden können, um bestimmte Funktionalitäten nur eingeloggten Nutzern zugänglich zu machen. Hierzu müssen wir das JSON Web Token des eingeloggten Nutzers im Authorization Header des API-Aufrufs übergeben.

Das Firebase SDK stellt uns die Funktion getIdToken zur Verfügung, um das aktuelle Token eines eingeloggten Nutzers zu erhalten. Zu beachten ist, dass diese Funktion asynchron ist, da sie im Falle eines abgelaufenen Access Tokens mithilfe des Refresh Tokens ein frisches Access Token erzeugt und hierzu intern ein API-Call beim Firebase-Server erforderlich ist.

getIdToken muss also immer unmittelbar vor einem API-Call aufgerufen werden, um sicherzustellen, dass wir immer ein aktuelles Access Token im Authorization Header verwenden.

Einige HTTP-Client-Libraries wie z.B. axios (Quelle: https://axios-http.com/)  erlauben die Verwendung von Interceptors (Quelle: https://axios-http.com/docs/interceptors), mit deren Hilfe HTTP-Requests an einer zentralen Stelle unterbrochen und manipuliert werden können. Ist dies nicht möglich, kann man alternativ mit Wrapperfunktionen arbeiten.

Serverseitig kann das im Authorization Header mitgelieferte Token nun mithilfe des Firebase Admin SDK überprüft werden. Dies kann ohne Kommunikation mit dem Firebase Server geschehen, da die Gültigkeit des Tokens durch die digitale Signatur gewährleistet ist.

Das Firebase Admin SDK ist verfügbar für Node.js, Java, Python, Go und C#.

Mithilfe der Methode verifyIdToken kann das im Header mitgelieferte Token überprüft werden und die angefragte Route geöffnet/gesperrt werden (Quelle: https://firebase.google.com/docs/auth/admin/verify-id-tokens).

Das Admin SDK bietet außerdem eine Reihe zusätzlicher Funktionen zum User Management. Hingewiesen sei auf die Möglichkeit, Tokens sogenannte Custom Claims zuzuweisen, mit denen z.B. Nutzerrollen im Token selbst übermittelt werden können, sodass keine zusätzliche Rollenverwaltung mit Datenbankzugriff o.Ä. mehr erforderlich ist. Da die Claims direkt im Token gespeichert werden, stehen sie auch clientseitig im User-Objekt ohne zusätzliche Abfrage zur Verfügung (Quelle: https://firebase.google.com/docs/auth/admin/custom-claims).

Registrierung und Login von Nutzern ist für die meisten Apps ein unverzichtbares Feature.

Wir denken, dass der oben am Beispiel von Firebase Authentication vorgestellte Implementierungsansatz einen guten Startpunkt für die Erstellung von Apps mit integriertem User-Management darstellt. Alternative auf JSON Webtoken basierende Systeme bieten vergleichbare SDKs und können analog eingebunden werden, die Kapselung des Authentifizierungsstatus in einem separaten Context-Modul erlaubt einen einfachen Austausch der Anbieter.

Wir wünschen viel Erfolg beim Ausprobieren: Happy Coding!