CodeB als Custom-OpenID-Connect-Provider in Microsoft Entra einbinden.

0 Warum das funktioniert

Die Custom-OpenID-Connect-Provider-Fläche von Microsoft Entra erwartet vom Drittanbieter reines OpenID Connect Core 1.0 mit PKCE und ein per Discovery abrufbares Metadaten-Dokument. CodeB liefert alles davon unter festen URLs auf jedem Tenant:

• /.well-known/openid-configuration — Discovery-Dokument mit authorize / token / userinfo / jwks-Endpunkten, unterstützten Scopes, Response-Types, Algorithmen.
• /.well-known/jwks.json — RS256-Public-Key-Set mit Previous-Key-Rotationsfenster.
• /.well-known/openid-federation — ES256-signierte OpenID-Federation-1.0-Entity-Statement (optional, aber vorhanden für zukünftige Entra-Föderations-Trust-Chains).
• /.well-known/security.txt — RFC-9116-Kontakt und -Policy.

Entra holt sich das Discovery-Dokument, lernt daraus alles über den Provider und führt den Standard-Authorization-Code+PKCE-Tanz durch. Nichts Maßgeschneidertes auf beiden Seiten.

1 CodeB-Endpunkte, die Entra ansprechen wird

Ersetzen Sie <CODEB_TENANT_HOST> durch Ihren CodeB-Tenant-Hostnamen (z. B. www.aloaha.com). Jeder Endpunkt ist HTTPS, pro-Tenant, unabhängig ratenbegrenzt.

2 Voraussetzungen

• Ein CodeB-Tenant mit Admin-Zugang zu /oidc-clients.html.
• Ein Entra-Tenant mit entweder der External ID for customers-Konfiguration oder dem Workforce-Tenant, in dem Sie B2B-Gast-Föderation wollen. Sie brauchen die Entra-Rolle External Identity Provider Administrator oder höher.
• Ihre Entra-Tenant-ID (GUID). Steht auf der Übersichtsseite des Entra-Admin-Centers.

Die zwei Entra-Callback-URLs, die Sie bei CodeB freigeben müssen:

• External ID for customers: https://<YOUR_ENTRA_TENANT_HOST>/<POLICY_ID>/oauth2/authresp (Entra zeigt die vollständige URL beim Hinzufügen des Providers — wortwörtlich kopieren).
• B2B-Gast-Föderation: https://login.microsoftonline.com/te/<ENTRA_TENANT_ID>/oauth2/authresp

3 OIDC-Client bei CodeB registrieren

1. Öffnen Sie https://<CODEB_TENANT_HOST>/oidc-clients.html und melden Sie sich als Admin an.
2. Klicken Sie auf Neuer Client. Geben Sie ihm einen einprägsamen Namen (z. B. entra-external-id oder entra-b2b-guests).
3. Setzen Sie Grant-Types auf authorization_code. Setzen Sie Response-Types auf code.
4. Unter Redirect-URIs fügen Sie die Entra-Callback-URL aus dem vorigen Schritt ein. Sie können auch mehrere hinterlegen, wenn derselbe CodeB-Client beide Entra-Flächen bedienen soll.
5. Bestätigen Sie, dass PKCE erforderlich ist (Standard: an). Entra sendet immer code_challenge_method=S256.
6. Bestätigen Sie, dass Client-Authentifizierung client_secret_basic oder client_secret_post ist. Beides funktioniert mit Entra.
7. Speichern. Kopieren Sie client_id und client_secret. Das Secret wird nur einmal angezeigt.

4 Entra External ID for customers — User-Flow-Setup

External ID for customers ist der moderne Nachfolger von Azure AD B2C. Er hostet kundenseitige Anmelde-/Registrier-Flows gegen Ihr eigenes Verzeichnis. Custom-OpenID-Connect-Provider sind eine First-Class-Funktion.

1. Melden Sie sich am Entra-Admin-Center als Nutzer mit External Identity Provider Administrator an.
2. Navigieren Sie zu External Identities → All identity providers → Custom → + New OpenID Connect provider.
3. Füllen Sie das Formular aus:

   Name                CodeB (European Digital Identity Wallet)
   Client ID           <die client_id aus Schritt 3>
   Client secret       <das client_secret aus Schritt 3>
   Scope               openid profile email
   Response type       code
   Response mode       query
   Metadata URL        https://<CODEB_TENANT_HOST>/.well-known/openid-configuration

4. Unter Identity provider claims mapping mappen Sie (vollständige Liste siehe Claim-Tabelle):

   User ID       <-  sub
   Display name  <-  name         (Fallback: preferred_username)
   Given name    <-  given_name
   Surname       <-  family_name
   Email         <-  email

5. Speichern.
6. Verknüpfen Sie den Provider mit einem User-Flow. Navigieren Sie zu External Identities → User flows → wählen Sie Ihren Anmelde-/Registrier-Flow → Identity providers → kreuzen Sie CodeB (European Digital Identity Wallet) an. Speichern.

5 Entra ID B2B-Kollaboration — Direct-Federation via OIDC

Die B2B-Kollaborations-Fläche existiert innerhalb Ihres Workforce-Entra-Tenants und erlaubt Ihnen, Gäste einzuladen. Historisch unterstützte B2B-Föderation nur SAML/WS-Fed-Direct-Federation. Microsoft hat inzwischen OIDC Direct Federation hinzugefügt, sodass Sie eine Domain (z. B. aloaha.com) auf jeden OpenID-Connect-Provider verweisen können, inklusive CodeB.

1. Melden Sie sich am Entra-Admin-Center als Nutzer mit External Identity Provider Administrator an.
2. Navigieren Sie zu External Identities → All identity providers → + New OpenID Connect provider (Workforce-Tenant-Variante).
3. Füllen Sie aus:

   Display name        CodeB (European Digital Identity Wallet)
   Client ID           <client_id aus Schritt 3>
   Client secret       <client_secret aus Schritt 3>
   Metadata URL        https://<CODEB_TENANT_HOST>/.well-known/openid-configuration
   Scope               openid profile email
   Response type       code
   Response mode       form_post
   Domain              <zu föderierende E-Mail-Domain(s), Komma-getrennt>

4. Unter Claims mapping das gleiche Mapping wie für External ID setzen (siehe Claim-Tabelle).
5. Speichern. Ab diesem Moment gilt: wenn Sie einen Gast einladen, dessen E-Mail auf eine föderierte Domain endet, leitet Entra ihn zu CodeB weiter statt ein Microsoft-Konto oder Einmalcode zu verlangen.

6 Claim-Mapping-Referenz

Die Custom-OIDC-Fläche von Entra konsumiert eine kleine, feste Menge Standard-OpenID-Connect-Claims. CodeB liefert alle davon in /oidc.ashx?action=userinfo und im ID-Token. Nicht-standard CodeB-Claims (eudi_verified, wallet_attestation, role, groups) fließen nicht automatisch durch Entra — siehe den Hinweis "Custom Claims" unten.

7 Integration End-to-End verifizieren

1. Öffnen Sie ein frisches Inkognito-/Private-Fenster (damit keine gecachte Entra-Session stört).
2. External ID: rufen Sie die Sign-in-URL Ihres Entra-User-Flows auf. B2B: schicken Sie sich selbst eine Einladung an eine föderierte Domain-Adresse und öffnen Sie den Einladungslink.
3. Bestätigen Sie, dass Sie einen CodeB (European Digital Identity Wallet)-Knopf sehen (bzw. bei B2B automatisch zu CodeB weitergeleitet werden, nachdem Entra die Domain aufgelöst hat).
4. Melden Sie sich bei CodeB mit einer beliebigen Methode an — Passwort, Passkey oder Wallet.
5. Bestätigen Sie, dass Sie zu Entra zurückgeleitet werden und Entra den External-User provisioniert und Sie in die Zielanwendung reicht.
6. Im Entra-Admin-Center unter Users bestätigen Sie, dass der External-User-Datensatz die gemappten Felder gefüllt hat.
7. Auf der CodeB-Seite App_Data/<tenant>/logs/oidc.log tailen nach Zeilen beginnend mit [OIDC-AUTHORIZE-DIAG], [OIDC-TOKEN-DIAG] und [OIDC-USERINFO-DIAG]. Jede trägt die angeforderte client_id, gewährte Scopes und Outcome.

8 Fehlersuche

Entra sagt "Etwas ist schief gelaufen" nachdem CodeB zurückleitet

Fast immer die Redirect-URI. Kopieren Sie die URL aus der Entra-Provider-Detailseite wortwörtlich in die Redirect-URIs-Liste des CodeB-Clients. Achten Sie auf einen Slash am Ende (/oauth2/authresp vs. /oauth2/authresp/) — Entra lehnt einen Byte-für-Byte-Mismatch ab.

Entra sagt "AADSTS90056: PII / Claim fehlt"

Das Claim-Mapping in Entra referenziert einen Claim, den CodeB nicht liefert. CodeB liefert immer sub, email und name. Wenn Sie given_name oder family_name für einen Nutzer gemappt haben, der sein Profil noch nicht ausgefüllt hat, fehlen diese Schlüssel im Token und Entra lehnt die gesamte Assertion ab. Fix: entweder das Mapping in Entra als optional markieren, oder sicherstellen dass CodeB-Nutzer die Profilregistrierung abgeschlossen haben bevor sie föderiert werden.

Discovery scheitert: "Metadata-URL nicht erreichbar"

Entra holt Discovery von Azure-Egress-IPs. Wenn Ihr CodeB-Tenant hinter einer IP-Allowlist steht, tragen Sie die öffentlichen Microsoft-Azure-IP-Bereiche in die Allowlist ein (oder stellen Sie den CodeB-Tenant auf einen öffentlichen Egress und verlassen sich auf OAuth-PKCE als Authentifizierung).

Wallet-basierte Anmeldung funktioniert, aber Entra-Token hat keine Wallet-Claims

Erwartet. Lesen Sie den Custom-Claims-Hinweis in Abschnitt Claim-Mapping. Entra proxied keine beliebigen Claims — verdrahten Sie einen Entra Custom claims provider, der Ihre App ruft, und Ihre App wiederum CodeB userinfo.

B2B-Gast-Föderation leitet um, aber Entra fordert ein Microsoft-Konto

Die Domain der eingeladenen E-Mail ist keine der Domains, die Sie beim CodeB-Provider registriert haben. Editieren Sie den Provider in Entra und fügen die fehlende Domain hinzu, oder laden Sie den Gast unter einer föderierten Domain ein.

9 Anhang — kopierfertiges JSON

Wenn Sie das Entra-Provider-Setup über die Microsoft-Graph-API (identityProviders-Ressource) skripten, hier ein minimales Payload das dem manuellen Durchlauf in Abschnitten 4 und 5 entspricht:

{
  "@odata.type": "#microsoft.graph.openIdConnectIdentityProvider",
  "displayName": "CodeB (European Digital Identity Wallet)",
  "clientId": "<CLIENT_ID>",
  "clientSecret": "<CLIENT_SECRET>",
  "scope": "openid profile email",
  "responseType": "code",
  "responseMode": "query",
  "metadataUrl": "https://<CODEB_TENANT_HOST>/.well-known/openid-configuration",
  "claimsMapping": {
    "userId":      { "claim": "sub" },
    "displayName": { "claim": "name" },
    "givenName":   { "claim": "given_name" },
    "surname":     { "claim": "family_name" },
    "email":       { "claim": "email" }
  }
}

Posten Sie es an POST https://graph.microsoft.com/v1.0/identity/identityProviders mit einem Access-Token, das IdentityProvider.ReadWrite.All hält. Der Provider muss danach separat mit einem User-Flow verknüpft werden (entweder übers Portal oder über die userFlow-Graph-Ressource).