Appendix B. Platform-Specific Implementation Details (Anhang B. Plattformspezifische Implementierungsdetails)
Dieses Dokument definiert Best Practices primär auf eine generische Weise und referenziert Techniken, die in verschiedenen Umgebungen üblicherweise verfügbar sind. Dieser nicht-normative Abschnitt dokumentiert Implementierungsdetails der Best Practice für verschiedene Betriebssysteme.
Die hierin enthaltenen Implementierungsdetails werden zum Zeitpunkt der Veröffentlichung als korrekt angesehen, werden sich aber wahrscheinlich im Laufe der Zeit ändern. Es wird gehofft, dass eine solche Änderung die generischen Prinzipien im Rest des Dokuments nicht ungültig macht und dass diese Prinzipien im Falle eines Konflikts Vorrang haben sollten.
B.1. iOS Implementation Details (iOS Implementierungsdetails)
Apps können eine Autorisierungsanfrage im Browser initiieren, ohne dass der Benutzer die App verlässt, über die Klasse "SFSafariViewController" oder deren Nachfolger "SFAuthenticationSession", die das In-App-Browser-Tab-Muster implementieren. Safari kann verwendet werden, um Anfragen auf alten iOS-Versionen ohne In-App-Browser-Tab-Funktionalität zu bearbeiten.
Um die Autorisierungsantwort zu empfangen, sind sowohl privat genutzte URI-Schema-Redirects (als "custom URL scheme" bezeichnet) als auch beanspruchte "https"-Schema-URIs (bekannt als "Universal Links") praktikable Optionen. Apps können privat genutzte URI-Schemas mit dem "CFBundleURLTypes"-Schlüssel in der Property-List-Datei der Anwendung, "Info.plist", beanspruchen, und "https"-Schema-URIs unter Verwendung der Universal-Links-Funktion mit einer Entitlement-Datei in der App und einer Assoziationsdatei, die auf der Domain gehostet wird.
Beanspruchte "https"-Schema-URIs sind die bevorzugte Redirect-Option auf iOS 9 und höher aufgrund des vom Betriebssystem bereitgestellten Eigentumsnachweises.
Ein vollständiges Open-Source-Beispiel ist in der AppAuth for iOS and macOS [AppAuth.iOSmacOS] Bibliothek enthalten.
B.2. Android Implementation Details (Android Implementierungsdetails)
Apps können eine Autorisierungsanfrage im Browser initiieren, ohne dass der Benutzer die App verlässt, über die Android Custom Tab-Funktion, die das In-App-Browser-Tab-Muster implementiert. Der Standardbrowser des Benutzers kann verwendet werden, um Anfragen zu bearbeiten, wenn kein Browser Custom Tabs unterstützt.
Android-Browser-Anbieter sollten das Custom Tabs-Protokoll unterstützen (durch Bereitstellung einer Implementierung der "CustomTabsService"-Klasse), um ihren Benutzern die Benutzererfahrungs-Optimierung des In-App-Browser-Tabs zu bieten. Chrome ist ein solcher Browser, der Custom Tabs implementiert.
Um die Autorisierungsantwort zu empfangen, werden privat genutzte URI-Schemas über Android Implicit Intents breit unterstützt. Beanspruchte "https"-Schema-Redirect-URIs über Android App Links sind ab Android 6.0 verfügbar. Beide Arten von Redirect-URIs werden im Manifest der Anwendung registriert.
Ein vollständiges Open-Source-Beispiel ist in der AppAuth for Android [AppAuth.Android] Bibliothek enthalten.
B.3. Windows Implementation Details (Windows Implementierungsdetails)
Sowohl traditionelle als auch Universal Windows Platform (UWP) Apps können Autorisierungsanfragen im Browser des Benutzers durchführen. Traditionelle Apps verwenden typischerweise eine Loopback-Umleitung, um die Autorisierungsantwort zu empfangen, und das Lauschen auf der Loopback-Schnittstelle ist durch Standard-Firewall-Regeln erlaubt. Beim Erstellen des Loopback-Netzwerk-Sockets sollten (SHOULD) Apps die "SO_EXCLUSIVEADDRUSE"-Socket-Option setzen, um zu verhindern, dass andere Apps an denselben Socket binden.
UWP-Apps können privat genutzte URI-Schema-Redirects verwenden, um die Autorisierungsantwort vom Browser zu empfangen, was die App in den Vordergrund bringt. Auf der Plattform als "URI Activation" bekannt, ist das URI-Schema auf 39 Zeichen Länge begrenzt und kann das "."-Zeichen enthalten, wodurch kurze auf umgekehrten Domainnamen basierende Schemas (wie in Abschnitt 7.1 erforderlich) möglich sind.
UWP-Apps können alternativ die Web Authentication Broker API im Single Sign-on (SSO)-Modus verwenden, die ein externer User-Agent ist, der für Autorisierungsabläufe konzipiert wurde. Cookies werden zwischen Aufrufen des Brokers geteilt, aber nicht mit dem bevorzugten Browser des Benutzers, was bedeutet, dass sich der Benutzer erneut anmelden muss, selbst wenn er eine aktive Sitzung in seinem Browser hat; aber die im Broker erstellte Sitzung wird für nachfolgende Apps verfügbar sein, die den Broker verwenden. Personalisierungen, die der Benutzer an seinem Browser vorgenommen hat, wie das Konfigurieren eines Passwort-Managers, sind im Broker möglicherweise nicht verfügbar. Um als externer User-Agent zu qualifizieren, muss (MUST) der Broker im SSO-Modus verwendet werden.
Um den Web Authentication Broker im SSO-Modus zu verwenden, muss die Redirect-URI die Form msapp://{appSID} haben, wobei "{appSID}" der Sicherheitsidentifikator (SID) der App ist, der in den Registrierungsinformationen der App gefunden oder durch Aufrufen der "GetCurrentApplicationCallbackUri"-Methode ermittelt werden kann. Während Windows die URI-Autorität bei solchen Umleitungen durchsetzt und sicherstellt, dass nur die App mit der passenden SID die Antwort unter Windows empfangen kann, könnte das URI-Schema von Apps auf anderen Plattformen ohne dieselbe vorhandene Autorität beansprucht werden; daher sollte dieser Redirect-Typ ähnlich wie privat genutzte URI-Schema-Redirects zu Sicherheitszwecken behandelt werden.
Ein Open-Source-Beispiel, das diese Muster demonstriert, ist verfügbar [SamplesForWindows].
B.4. macOS Implementation Details (macOS Implementierungsdetails)
Apps können eine Autorisierungsanfrage im Standardbrowser des Benutzers initiieren, indem sie Plattform-APIs zum Öffnen von URIs im Browser verwenden.
Um die Autorisierungsantwort zu empfangen, sind privat genutzte URI-Schemas eine gute Redirect-URI-Wahl auf macOS, da der Benutzer direkt zur App zurückkehrt, von der er die Anfrage gestartet hat. Diese werden in der Bundle-Informations-Property-List der Anwendung mit dem "CFBundleURLSchemes"-Schlüssel registriert. Loopback-IP-Redirects sind eine weitere praktikable Option, und das Lauschen auf der Loopback-Schnittstelle ist durch Standard-Firewall-Regeln erlaubt.
Ein vollständiges Open-Source-Beispiel ist in der AppAuth for iOS and macOS [AppAuth.iOSmacOS] Bibliothek enthalten.
B.5. Linux Implementation Details (Linux Implementierungsdetails)
Das Öffnen der Autorisierungsanfrage im Standardbrowser des Benutzers erfordert einen distributionsspezifischen Befehl: "xdg-open" ist ein solches Tool.
Die Loopback-Umleitung ist die empfohlene Redirect-Option für Desktop-Apps unter Linux, um die Autorisierungsantwort zu empfangen. Apps sollten nicht (SHOULD NOT) die "SO_REUSEPORT"- oder "SO_REUSEADDR"-Socket-Optionen setzen, um zu verhindern, dass andere Apps an denselben Socket binden.