Wann kann ich diesen Ablauf einsetzen?

Wenn App ID keine direkte Unterstützung für einen bestimmten Identitätsprovider bereitstellt, können Sie den angepassten Identitätsablauf verwenden, um das Authentifizierungsprotokoll mit dem vorhandenen Authentifizierungsablauf von App ID zu verbinden. Beispiel: Sie möchten GitHub oder LinkedIn verwenden, um Ihren Benutzern die Anmeldung zu ermöglichen. Sie können das vorhandene SDK des Identitätsproviders verwenden, um die Benutzerauthentifizierungsinformationen zu vereinfachen, bevor sie mit App ID gepackt und ausgetauscht werden.

Es gibt zahlreiche Szenarios, in denen ein anderer Authentifizierungsablauf erforderlich ist:

• Proprietäre interne Identitätsprovider
• Identitätsprovider anderer Anbieter
• Komplexe Authentifizierungsabläufe, zu denen auch proprietäre Mehrfaktormechanismen gehören können

Gelegentlich verwendet ein traditioneller Provider sein eigenes Authentifizierungsprotokoll. Da der angepasste Identitätsablauf die Authentifizierung vollständig von der Autorisierung entkoppelt, können Sie jedes Authentifizierungsverfahren Ihrer Wahl anwenden und dann die resultierenden Authentifizierungsdaten für App ID bereitstellen. Dazu sind keine Benutzerberechtigungsnachweise erforderlich.

Wie funktioniert dieser Ablauf in technischer Hinsicht?

Der benutzerdefinierte Identitäts-Workflow basiert auf dem JWT-Bearer-Erweiterungstyp, der in Assertion Framework for OAuth 2.0 Authorization Grants [RFC7521 ] definiert ist. Zum Austauschen von Benutzerinformationen für App ID-Token stellt Ihre Authentifizierungsarchitektur eine Vertrauensbeziehung mit App ID her und verwendet dafür ein asymmetrisches RSA-Schlüsselpaar. Sobald die Vertrauensbeziehung hergestellt ist, können Sie den "JWT-Bearer"-Grant-Typ verwenden, um verifizierte Benutzerinformationen in einem signierten JWT für App ID-Token auszutauschen.

Wie sieht der Ablauf aus?

Wie bei allen Authentifizierungsabläufen erfordert die angepasste Identität, dass die Anwendung in der Lage ist, eine Vertrauensbeziehung zu App ID herzustellen, um die Integrität der Benutzerinformationen des Identitätsproviders sicherzustellen. Die angepasste Identität verwendet ein asymmetrisches RSA-Paar aus öffentlichem und privatem Schlüssel, um die Vertrauensbeziehung aufzubauen. Abhängig von Ihren Architekturanforderungen unterstützt die angepasste Identität zwei Vertrauensmodelle, die sich nur in der Speicherposition und der Verwendung des privaten Schlüssels unterscheiden.

Beispiel für ein JWT-Format

{
  // Header
  "alg": "RS256",
  "typ": "JOSE",
  // Payload
  // Required
  "iss": "String", // Should reference your identity provider
  "aud": "String", // Must be the OAuth server URL name
  "exp": "Int",    // Should be a value with a short lifespan
  "sub": "String", // Must be the unique user ID provided by your identity provider

  // Normalized claims (optional)
  "name": "String",
  "email": "String",
  "locale": "String",
  "picture": "String",
  "gender": "String",

  // Custom Scopes to add to access token (optional)
  scope="custom_scope1 custom_scope2"

  // Other custom claims (optional)
  role="admin"
}