OpenID Connect-Anwendungsregistrierung

Mit einer FoxIDs-OpenID Connect-Anwendungsregistrierung kann eine Web-, Single-Page- oder native Anwendung Benutzer über FoxIDs authentifizieren und ID-Token sowie Zugriffstoken empfangen. Die Anwendung ist die Relying Party (RP), FoxIDs ist der OpenID Provider (OP).

FoxIDs OpenID Connect-Anwendungsregistrierung

Zu den wichtigen OpenID Connect-Funktionen gehören Discovery, Authorization Code Flow, PKCE, Client-Geheimnisse und Schlüssel, der UserInfo-Endpunkt, RP-initiierter Logout und Front-Channel-Logout.

Konfiguration

In FoxIDs Control:

  1. Wählen Sie die Umgebung aus, in der die Anwendung registriert werden soll.
  2. Öffnen Sie Applications und klicken Sie auf Add application.
  3. Wählen Sie Web Application, Single Page Application oder Native Application. Diese drei OpenID Connect-Optionen werden angezeigt, ohne Show all options zu aktivieren.
  4. Geben Sie einen Namen und eine Redirect-URI ein, prüfen Sie die generierten Anwendungsinformationen und klicken Sie auf Create.
  5. Kopieren Sie ein gegebenenfalls generiertes Geheimnis, bevor Sie das Erstellungsergebnis schließen. Ein generiertes Geheimnis wird nur während der Erstellung angezeigt.

OpenID Connect-Anwendungstyp auswählen

Klicken Sie nach der Erstellung auf Change application, um die vollständigen Anwendungseinstellungen zu prüfen oder zu ändern. Die Karte des Anwendungstyps stellt eine geeignete Ausgangskonfiguration bereit; der resultierende OpenID Connect-Client kann anschließend angepasst werden.

Webanwendung (vertraulicher Client)

Wählen Sie Web Application für eine Anwendung, die auf einem Server ausgeführt wird, z. B. eine ASP.NET Core-, Node.js-, Java- oder PHP-Anwendung. Sie wird als vertraulicher Client erstellt mit:

  • Authorization Code Flow mit dem Response Type code.
  • Einem generierten Client-Geheimnis.
  • Standardmäßig deaktiviertem PKCE. Aktivieren Sie nach der Erstellung Require PKCE, wenn die Anwendung PKCE unterstützt. Dies wird als zusätzlicher Schutz für den Autorisierungscode empfohlen.

Geben Sie die Basis-URL oder Callback-URL der Anwendung als Redirect URI ein. Aktivieren Sie Show advanced während der Erstellung nur, wenn Sie die Client-ID auswählen oder einen exakten Abgleich der Redirect-URL konfigurieren müssen.

OpenID Connect-Webanwendung erstellen

Single-Page-Anwendung (öffentlicher Client)

Wählen Sie Single Page Application für eine im Browser ausgeführte Anwendung, z. B. React, Angular, Vue oder Blazor WebAssembly. Sie wird als öffentlicher Client erstellt mit:

  • Authorization Code Flow mit dem Response Type code.
  • Standardmäßig aktiviertem PKCE.
  • Keinem Client-Geheimnis.
  • Der Origin der Redirect-URL als zulässiger CORS-Origin.

OpenID Connect-Single-Page-Anwendung mit PKCE erstellen

Native Anwendung (öffentlicher Client)

Wählen Sie Native Application für eine installierte Mobil- oder Desktopanwendung, z. B. iOS, Android, React Native, .NET MAUI oder Ionic. Sie wird als öffentlicher Client mit Authorization Code Flow, standardmäßig aktiviertem PKCE und ohne Client-Geheimnis erstellt.

Die Redirect-URI kann ein anwendungsspezifisches Schema wie myapp://callback oder eine von der Anwendung unterstützte HTTPS-URI verwenden.

Native OpenID Connect-Anwendung mit PKCE erstellen

Redirect-URIs und absolute Werte

Standardmäßig ist Absolute URIs für Web- und Single-Page-Anwendungen deaktiviert. Die konfigurierte Redirect-URL wird dann als Basiswert behandelt, und Redirect-URLs, die mit diesem Wert beginnen, werden akzeptiert.

Aktivieren Sie Show advanced und Absolute URIs, wenn Sie die exakte URL in Ihrer Anwendung kennen, zu der der Benutzer nach der Anmeldung zurückgeleitet werden soll. Geben Sie diese exakte URL als Redirect URI ein. Dieselbe Einstellung unterstützt exakte anwendungsspezifische URIs für native Anwendungen.

Nach der Erstellung können Redirect-URIs, Post-Logout-Redirect-URI und zulässige CORS-Origins auf der Registerkarte OpenID Connect Client geändert werden. Wenn die zulässigen CORS-Origins nicht separat bearbeitet wurden, sorgt FoxIDs dafür, dass CORS-Origins, die Redirect-URIs entsprechen, bei Änderungen der Redirect-URIs synchronisiert bleiben. Wenn Sie die zulässigen CORS-Origins explizit bearbeiten, bleiben die von Ihnen eingegebenen Werte erhalten. Lassen Sie Show advanced deaktiviert, sofern die benötigte Einstellung nicht erweitert ist.

Implicit Flow

Der Implicit Flow bleibt aus Kompatibilitätsgründen erhalten, wird jedoch für neue Anwendungen nicht empfohlen. Verwenden Sie stattdessen Authorization Code Flow mit PKCE.

Um einen vorhandenen öffentlichen Client für Implicit Flow zu konfigurieren, klicken Sie auf Change application, aktivieren Show advanced, ändern Response types in token id_token oder optional nur token und deaktivieren Require PKCE. Response Types können in denselben erweiterten Client-Einstellungen geändert werden, wenn eine andere unterstützte Kombination erforderlich ist.

Response Types für Token und ID-Token beim Implicit Flow auswählen

Anwendungsendpunkte und Client-Sicherheit

Die Anwendungsinformationen in FoxIDs Control enthalten Authority, Client-ID, Discovery-Endpunkt, Authorize-Endpunkt und Token-Endpunkt. Ein OpenID Connect-Discovery-Dokument hat folgende Form:

https://foxids.com/tenant-x/environment-y/application-client1(*)/.well-known/openid-configuration

Eine Anwendung kann die Anmeldung über mehrere Authentifizierungsmethoden zulassen. Wenn eine Authentifizierungsmethode Profile definiert, können die Basismethode und jedes Profil unabhängig ausgewählt werden. Um eine Authentifizierungsmethode in der Authority-URL auszuwählen, fügen Sie deren Namen zum Anwendungssegment hinzu:

https://foxids.com/tenant-x/environment-y/application-client1(login)/.well-known/openid-configuration

Beim RP-initiierten Logout kann der Name der Authentifizierungsmethode weggelassen werden, wenn das ID-Token in der Anfrage enthalten ist.

Anwendungsspezifischer Issuer

Standardmäßig verwenden für die Anwendung ausgestellte Token den Issuer der Umgebung:

https://foxids.com/tenant-x/environment-y/

Damit der Issuer mit der Authority der Anwendung übereinstimmt, klicken Sie auf Change application, aktivieren Show advanced und aktivieren Use matching issuer and authority with application specific issuer. Der Issuer lautet dann:

https://foxids.com/tenant-x/environment-y/application-client1(*)

Anwendungsspezifischen OpenID Connect-Issuer aktivieren

Der anwendungsspezifische Issuer ändert sich, wenn sich die ausgewählten Authentifizierungsmethoden in der Authority-URL ändern. Bei APIs hängt der Issuer daher von der aufrufenden Anwendung ab. Token Exchange ist nur zwischen Konfigurationen mit entsprechenden Authentifizierungsmethoden möglich.

Client-Sicherheit

Öffentliche Clients, darunter Single-Page- und native Anwendungen, können Client-Anmeldedaten nicht sicher speichern. Konfigurieren Sie sie ohne Client-Geheimnis und verwenden Sie Authorization Code Flow mit PKCE.

Vertrauliche Clients authentifizieren sich am Token-Endpunkt. Die Standardmethode für die Client-Authentifizierung ist client secret post. Aktivieren Sie Show advanced, um sie in client secret basic oder private key JWT zu ändern. PKCE wird ebenfalls empfohlen, wenn der vertrauliche Client es unterstützt. Wenn sowohl PKCE als auch ein Client-Geheimnis oder Schlüssel konfiguriert sind, validiert FoxIDs beides.

Die Client-Authentifizierungsmethode none wird mit PKCE unterstützt. Für einen Client können bis zu 10 Geheimnisse und 4 Schlüssel konfiguriert werden. Speichern Sie Client-Geheimnisse und private Schlüssel sicher und rotieren Sie sie bei Bedarf.

FoxIDs richtet bei der Authentifizierung des Benutzers eine Sitzung ein und nimmt deren Sitzungs-ID in das ID-Token auf. Die Sitzung wird beim Logout ungültig. Abhängig von der Client-Konfiguration und davon, ob die Logout-Anfrage ein ID-Token enthält, kann FoxIDs einen Bestätigungsdialog für den Logout anzeigen.

Client und API

Eine OpenID Connect-Anwendungsregistrierung kann sowohl den Client als auch dessen OAuth 2.0-Ressource enthalten. Die Client-ID ist dann zugleich der Name der API-Ressource.

Das folgende Beispiel konfiguriert oidc-web-app sowohl als OpenID Connect-Client als auch als API:

  1. Klicken Sie auf Change application und aktivieren Sie Show advanced.
  2. Ändern Sie den Anwendungsregistrierungstyp in OpenID Connect Client and OAuth 2.0 Resource.
  3. Lassen Sie auf der Registerkarte OpenID Connect Client die Option Default resource 'oidc-web-app' for the application itself ausgewählt.
  4. Fügen Sie die Scopes read und write unter der Standardressource hinzu.

Scopes unter der Standardressource eines OpenID Connect-Clients konfigurieren

Definieren Sie auf der Registerkarte OAuth 2.0 Resource dieselben Scopes read und write, die von der API bereitgestellt werden.

API-Scopes in derselben OpenID Connect-Anwendungsregistrierung konfigurieren

Ressource und Scopes

Eine API kann stattdessen separat als OAuth 2.0-Ressource registriert werden. In diesem Beispiel ruft der Client oidc-web-app eine separate Orders API mit dem Ressourcennamen orders-api auf.

Auf der Registerkarte OpenID Connect Client des Clients:

  1. Deaktivieren Sie Default resource 'oidc-web-app' for the application itself, da dieser Client nicht als eigene API fungiert.
  2. Fügen Sie die Ressource orders-api hinzu.
  3. Fügen Sie die Scopes read und write unter dieser Ressource hinzu.

Die vollständigen vom Client angeforderten Scope-Werte lauten orders-api:read und orders-api:write.

OpenID Connect-Client zum Anfordern von Scopes einer separaten API konfigurieren

Definieren Sie in der Anwendungsregistrierung der Orders API auf der Registerkarte OAuth 2.0 Resource die Scopes read und write.

Scopes für eine separate OAuth 2.0-API-Ressource konfigurieren

Von einem Client angeforderte Scopes werden anhand der für die API konfigurierten Scopes validiert. Befinden sich Client und API in derselben Anwendungsregistrierung, werden unter der Standardressource des Clients hinzugefügte Scopes automatisch zur Ressource hinzugefügt.

Standardmäßig ist die Client-ID die Audience sowohl des ID-Tokens als auch des Zugriffstokens. Konfigurierte Ressourcen-Scopes fügen dem Zugriffstoken API-Audiences hinzu, und ein Zugriffstoken kann für mehrere API-Ressourcen bestimmt sein.

Scopes und Claims

OpenID Connect-Scopes werden auf der Registerkarte OpenID Connect Client konfiguriert. Die Standard-Scopes offline_access, profile, email, address und phone können geändert oder entfernt werden. Für jeden Scope steuert Voluntary claims, welche Claims ausgegeben werden, wenn der Client diesen Scope anfordert.

OpenID Connect-Scopes und freiwillige Claims konfigurieren

Aktivieren Sie Show advanced, um Issue claims zu konfigurieren. Fügen Sie einen bestimmten Claim oder * hinzu, um alle verfügbaren Claims im Zugriffstoken auszugeben. Lassen Sie Include in ID token für * deaktiviert. Andernfalls werden alle verfügbaren Claims in das ID-Token kopiert, wodurch es übermäßig groß werden und in Abläufen Probleme verursachen kann, bei denen das ID-Token beim Logout gesendet wird.

Alle verfügbaren Claims ausgeben, ohne sie alle in das ID-Token aufzunehmen

Alternativ können Sie einen Claim zu Voluntary claims eines Scopes hinzufügen und diesen Scope von der Anwendung anfordern. Einzelne Claims können in das ID-Token aufgenommen werden, wenn die Anwendung sie dort benötigt. Claims können auch mit Claim-Transformationen und Claim-Tasks geändert werden.

Token-Lebensdauer

Klicken Sie auf Change application und aktivieren Sie Show advanced, um die Lebensdauer von Autorisierungscode, ID-Token, Zugriffstoken und Refresh-Token zu konfigurieren.

OpenID Connect-Token-Lebensdauern konfigurieren

In diesem Beispiel ist jedes Refresh-Token 36.000 Sekunden gültig. Die Anwendung kann die Sitzung weiter aktualisieren, bis die absolute Refresh-Token-Lebensdauer von 86.400 Sekunden erreicht ist.

Multi-Faktor-Authentifizierung (MFA) anfordern

Ein OpenID Connect-Client kann MFA anfordern, indem urn:foxids:mfa in den Parameter acr_values aufgenommen wird. Dies kann mit spezifischeren Werten wie urn:foxids:link kombiniert werden. Siehe MFA aus Anwendungen anfordern.

Der Parameter acr_values kann im Ereignis OnRedirectToIdentityProvider in Startup.cs festgelegt werden:

options.Events.OnRedirectToIdentityProvider = (context) =>
{
    context.ProtocolMessage.AcrValues = "urn:foxids:mfa";
    return Task.FromResult(string.Empty);
};

Siehe AspNetCoreOidcAuthorizationCodeSample und dessen Startup.cs-Konfiguration.

Anleitungen