In diesem Artikel werden wir die Schritte erläutern, die Sie befolgen können, um einen sichereren und anpassbaren Login-Flow in Single Page Applications oder Native Mobile Apps mit WSO2 Identity Server zu realisieren. Zunächst werden wir zeigen, wie der neue Flow zwischen verschiedenen Komponenten interagiert, und dann die technischen Änderungen in Ihrer App/Webseite erklären, damit er funktioniert!
Umstellung auf Autorisierungscode + PKCE
Viele webbasierte Anwendungen, die ihr IAM-Produkt nutzen, setzen Implicit Grant für ihren Login-Flow ein, während Native Mobile Apps den Typ Password Grant verwenden. Allerdings wurden in diesen Konzepten mehrere Schwachstellen gefunden, die in den OAUTH-Dokumenten 1 und 2 zusammengefasst sind.
Die aktuelle Empfehlung für mobile Apps und webbasierte Anwendungen ist der Wechsel zum Authorization Code + PKCE-Flow. Obwohl dies die beste Vorgehensweise ist, ist ein gewisser Aufwand auf der Anwendungsseite erforderlich, um auf diesen Flow umzustellen. Und diese Anleitung wird Ihnen hoffentlich helfen, reibungslos zu diesem Flow zu wechseln.
Neuer Flow als Sequenzdiagramm:
Änderung von WSO2 erforderlich:
Wenn Sie einen vorhandenen Service Provider für die Anwendung gemäß diesem WSO2-Artikel konfiguriert haben, benötigen Sie nur den Berechtigungstyp „code“ und müssen das Kontrollkästchen „PKCE Mandatory“ aktivieren. Sie können optional „Authentifizierung ohne Client-Secret zulassen“ wählen, so dass Ihre App oder die Webseite den wso2 Client-Secret-Wert nicht verwalten muss. Dies ist tatsächlich eine Best Practice bei der Verwendung von Autorisierungscode mit PKCE.
Webbasierte Anwendungen (Single-Page-Applikationen):
Die wichtigsten Unterschiede des neuen Anmeldevorgangs im Vergleich zum Implicit Grant-Vorgang sind die folgenden.
- Jedes Mal, wenn die Seite geladen wird oder eine Authentifizierung erforderlich ist, muss das Anwendungs-Backend
- einen „code_verifier“ gemäß https://tools.ietf.org/html/rfc7636#section-4.1 generieren und ihn persistieren (wenn er nicht bereits existiert).
- die „code_challenge“ = BASE64URL-ENCODE(SHA256(ASCII(code_verifier))) berechnen. Diese Website können Sie als Referenz für die gültige Umwandlung einer code_verifier-Zeichenfolge in eine code_challenge verwenden.
- Im impliziten Flow ruft die SPA-Anwendung (z. B. Angular) immer den „oauth2/authorize“-Endpunkt des Autorisierungsservers (WSO2) auf, damit WSO2 die Benutzersitzung validieren und bei Bedarf auf die Anmeldeseite umleiten kann. Dieser Call muss auch im neuen Flow erfolgen, aber mit folgenden Änderungen.
- „response_type“ Abfrageparameterwert ändert sich von „id_token token“ in „code“
- Es müssen zwei neue Parameter hinzugefügt werden;
- code_challenge_method = S256
- code_challenge = berechnet in Differenz #2
- Im impliziten Fluss erhält die Anwendung das ID-Token als URL-Fragment (z. B. http://app.com#id_token=JWT). In dem neuen Flow gibt WSO2 einen „Code“ als Abfrageparameter zurück, und das Anwendungs-Backend muss dann den WSO2-Endpunkt „oauth2/token“ wie unten beschrieben aufrufen, wobei {{AUTHORIZATION_CODE}} der in der Callback-URL empfangene Code ist:
curl --location --request POST 'https://localhost:9443/oauth2/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=authorization_code' \
--data-urlencode 'client_id={{CLIENT_ID}}' \
--data-urlencode 'client_secret={{CLIENT_SECRET}}' \
--data-urlencode 'code={{AUTHORIZATION_CODE}}' \
--data-urlencode 'redirect_uri={{redirect_uri}}' \
--data-urlencode 'code_verifier={{code_verifier}}' \Potenzielle Bibliotheken, die verwendet werden können:
Wenn die Anwendung auf Angular basiert, kann für den Login-Flow Ihrer Anwendung die Bibliothek „angular-oauth2-oidc“ verwendet werden – https://github.com/manfredsteyer/angular-oauth2-oidc. Sie ist zertifiziert und wird von der OpenID Foundation empfohlen, die die OAUTH2-Protokolle verwaltet.
Eine Referenz-Anwendung, die sich mit einem lokalen WSO2 Identity Server verbindet, finden Sie hier – https://github.com/davebaol/oidc-angular-wso2is
Native Mobile Apps
Die Hauptunterschiede des neuen Login-Flows im Vergleich zum Password Grant-Flow sehen wie folgt aus.
Im Password-Flow sammelt die Native App die Anmeldedaten des Benutzers. Im neuen Flow muss die App;
- einen „code_verifier“ gemäß https://tools.ietf.org/html/rfc7636#section-4.1 generieren und ihn persistieren (falls er nicht bereits existiert)
- die „code_challenge“ berechnen = BASE64URL-ENCODE(SHA256(ASCII(code_verifier)))
- öffnen Sie die „oauth2/authorize“-URL im mobilen Browser, einschließlich der Abfrageparameter ähnlich dem Webflow (response_type, scope, redirect_uri, client_id, nonce, code_challenge, code_challenge_method). Es empfiehlt sich, die Anmeldung über einen mobilen Browser und nicht über eine Inline-Webansicht in der App abzuwickeln
- Sobald der Benutzer die Anmeldeinformationen in den Browser eingibt und WSO2 den Browser an die „redirect_uri“ umleitet, muss die App auf diese URL hören und
- den Abfrageparameter „code“ extrahieren
- den Code gegen ein Token austauschen, einschließlich des gespeicherten „code_verifier“ (wie in Schritt 3 im webbasierten Anwendungsablauf)
Schlussfolgerung
Wir erleben nun eine Ära, in der die Identitäts- und Zugriffsmanagement-Landschaft kontinuierlich verändert und verbessert wird, um mehr Anpassbarkeit, Konnektivität über verschiedene soziale Medien und Business-Tools hinweg zu bieten und gleichzeitig die Sicherheit des Anwenders im Auge zu behalten. Meiner Meinung nach ist die OAUTH2-Spezifikation, erweitert um die PKCE-Verifizierung, ein großer Schritt in Richtung unserer Fähigkeit, uns über mehrere Systeme hinweg zu verbinden und dem Endbenutzer kreative Authentifizierungslösungen anzubieten. Der Artikel hat Sie oder Ihr Unternehmen hoffentlich dazu bewegt, Ihre Systeme hacksicher zu machen und gleichzeitig die Benutzerfreundlichkeit zu wahren.
