Authentication

Beschreibung

In Sektion Authentication wird die Anbindung an einen OIDC-fähigen IDP (z.B. elego IDP oder UserManagement, Azure EntraId, etc.) parametriert. Es werden folgende Settings unterstützt:

Setting	Beschreibung
UseAuth	Definiert, ob die Authentifizierung aktiv ist. Alle folgenden Konfigurationen werden nur berücksichtigt, wenn der Wert auf true gesetzt ist. Gültige Werte: [true/false] Wichtig: In produktiven Umgebungen muss UseAuth auf true gesetzt sein!
ShowPII	Definiert, ob detaillierte Fehlermeldungen über den Authentifizierungsprozess ausgegeben werden. Gültige Werte: [true/false] Wichtig: Diese Einstellung ist für die Fehleranalyse vorgesehen und sollte auf produktiven Systemen nicht eingesetzt werden, da auch Geheimnisse wie z.B. Tokens etc. geloggt werden.
Authority	Url des angebundenen IDP's. (mit Schema wie z.B. HTTPS)
Audience	Kennung für die API, für die das Token bestimmt ist.
Scopes	Folgende Scopes sind erforderlich: openid, profile und ein Service-Scope wie z.B. elego-service
SwaggerClientId	Eindeutige Kennung des Swagger-Clients. Die SwaggerClientId wird durch den IDP bestimmt. Sie muss für jeden angebundenen Client eindeutig sein.
ValidIssuers	Wird in der Regel nicht benötigt, da der Issuer automatisch aus der Authority ermittelt wird. Bei AD FS (Active Directory Federation Services) kann es jedoch erforderlich sein, die Valid Issuers explizit zu definieren, da der Issuer im Token von der Authority abweichen kann.

Scopes

Die beiden Scopes openid und profile werden von unserem eingesetzten Library immer automatisch angefordert und müssten nicht explizit definiert werden. Zur Dokumentation und Verständlichkeit ist die Angabe dieser Scopes hilfreich.

Flows

Die OIDC-Flows zwischen IDP und der Frontend-Anwendung sind unter OIDC-Flows beschrieben.

Beispiele

Authentication in appsettings.json

# Beispiel Sektion Authentication in appsettings.json

 "Authentication": {
    "UseAuth": true,
    "ShowPII": true,
    "Authority": "https://devidp-eis.egeli-apps.dev",
    "Audience": "https://devidp-eis.egeli-apps.dev/resources",
    "Scopes": "elego_service_local openid profile",
    "SwaggerClientId": "elego_swagger_local"
  }

Einstellungen im UserManagement

Für die Anbindung an das elego UserManagement sind für den referenzierten Client (ClientId) Einstellungen empfohlen:

Basics

Setting	Wert	Beschreibung
Require Client Secret	true	Die Einstellung definiert, ob für den Zugriff auf den Token-Enpunkt ein Client-Secret erforderlich ist. Die elego-Frontendanwendung validiert, ob im appsettings.json unter Authentication.ClientSecret ein ClientSecret gesetzt ist. Das Secret muss einem im IDP definierten Secret entsprechen.
Require Pkce	true	Wenn aktiviert, muss der Client eine gültige code_challenge und eine code_challenge_Method mitschicken. Sonst wird ein code_verifier erwartet. elego setzt einen PKCE-Flow ein. Die Einstellung soll daher true sein.
Allow Accesstoken Via Browser	false	Die Einstellung erlaubt die Ausgabe eines Access-Token direkt an den Browser. Sie soll nur in Leagacy-Anwendungen, die keinen Authorization Code Flow unterstützen aktiviert werden.
Allow Offline Access	true	Soll die Verwendung von Refresh-Tokens erlaubt sein? Wenn ja, muss im appsetting.json der Anwendung unter Authentication.Scopes zwingend der Scope offline_access eingetragen sein.
Allow Plaintext PKCE	false	Die aktivierte Einstellung erlaubt einen weniger sicheren PKCE-Flow zu.
Redirect Uris	[Anwendung]/signin-oidc
Allowed Scopes	openid, profile, offline_access elego-frontend	elego-frontend kann durch einen definierten API-Scope ersetzt werden
Allowed Grant Types	authorization_code	Definiert den OIDC-Flow, um ein Zugriffstoken zu lösen: authorization_code: für Webanwendungen mit Login client_credentials: für Machine-to-Machine
Default Client URL	[Anwendung]	URL der Anwendung, die im User als Default-URL ausgewählt werden kann

Authentifizierung/Login

In dieser Sektion sind keine Einstellungen notwendig.

Tokens

Setting	Wert	Beschreibung
Identity Token-Lifetime	600
Access Token Lifetime	600
Access Token Type	Jwt
Authorization Code Lifetime	300
Sliding Refresh Token Lifetime	1296000
Refresh-Token Usage	ReUse	Da Ext.Direct teils parallele Requests schickt, muss ein Token mehrfach verwendet werden können. Sonst führt das zu nicht authentifizierten Requests.
Refresh Token Expiration	Absolute
Client-Claims Prefix	_client
Update Access Tokenclaims On Refresh	true
Include JWT Id	true
Always Send Client Claims	true	Client Claims werden in Access- und Id Token übernommen.
Always Include User Claims in Id Token	false	Wird nicht benötigt, da Infos aus Access-Tokens übernommen werden.
Erlaubte CORS Origins	https://localhost:7144	[URL der Frontendanwendung]. Wichtig: Nur Schema, Host und Port.