Entwickler · OpenID Connect · OpenID4VP · ARF 3.0
EUDI-Wallet-Integration: Anmeldung mit der EU-Wallet für Ihre Website
Ihre Anwendung behält ihre normale OpenID-Connect-Anmeldung. Das CodeB EUDI Gateway auf phone.codeb.io spricht OpenID4VP, SD-JWT VC und ISO mdoc mit der Wallet, prüft die Präsentation und übergibt Ihnen ein signiertes id_token. Sie ergänzen einen Parameter und eine Prüfung.
- Jede OpenID-Connect-Bibliothek
- Ein Parameter, eine Prüfung
- Getestete Beispiele für sieben Plattformen
So funktioniert es
- Ihre App leitet zu CodeB weiter mit client_id, PKCE (S256), state, nonce und
acr_values=urn:codeb:acr:eudi-wallet. - CodeB öffnet die Wallet-Anmeldung: Auf dem Telefon öffnet sich die Wallet direkt; am Computer scannt die Person einen QR-Code mit dem Telefon, auf dem die Wallet ist.
- Die Wallet präsentiert, CodeB prüft über OpenID4VP: Ausstellersignatur und Vertrauenskette, Geräte-Bindung und Sperrstatus.
- CodeB gibt einen Autorisierungscode an Ihre Redirect-URI zurück.
- Ihr Server tauscht den Code ein, prüft das id_token und den
acr-Claim. Die Person ist angemeldet.
Die zwei Regeln
1. Nach der Wallet fragen: acr_values=urn:codeb:acr:eudi-wallet in die Autorisierungsanfrage aufnehmen.
2. Vor dem Zugriff prüfen: Der acr-Claim des geprüften id_token muss urn:codeb:acr:eudi-wallet oder urn:codeb:acr:eudi-wallet-linked sein. Eine Passwort-Anmeldung hat einen anderen Wert und muss abgelehnt werden.
Was Sie brauchen
Einen registrierten Client: CodeB registriert Ihre Redirect-URIs und schickt Ihnen Client-ID und Secret (info@aloaha.com). Ihr Name, Zweck und Ihre Datenschutzerklärung kommen ins Registrierungszertifikat, das die Wallet zeigt.
Das Discovery-Dokument: https://phone.aloaha.com/.well-known/openid-configuration für Ihre echte Integration – Autorisierungs-, Token-, UserInfo- und JWKS-Endpunkte, unterstützte Scopes, Claims und acr-Werte. Für Tests und Demos: phone.codeb.io.
Eine serverseitige Komponente, die das Client-Secret verwahrt (Authorization-Code-Flow mit PKCE).
Getestete Beispiele und Referenzen
Vollständige Beispiel-Apps für ASP.NET Core 8, Visual Basic .NET, Node.js, Python, PHP, Java und Go, jeweils gegen einen Anbieter getestet, der die CodeB-Endpunkte nachbildet: Integrations-Kochbuch. Kürzerer Einstieg: Entwickler-Schnellstart. Visual Basic .NET: Beispiel.
API-Referenz: EU-Wallet-API und die OpenAPI-Beschreibung.
Noch kein Backend? Das Anmelde-Widget setzt mit einem Script-Tag einen Button „Mit EU-Wallet anmelden“ auf eine Seite.
Mehr als Anmeldung
Nur das Alter: „über 18“ fragen und sonst nichts – Altersnachweis.
Nationaler eID-Ausweis: dieselbe Integration mit acr_values=urn:codeb:acr:eidcard – Anmeldung mit dem Authentisierungsschlüssel der Karte, über NFC von CodeB Wallet gelesen.
Jede Wallet testen: Der Interoperabilitäts-Selbsttest zeigt, welche Anforderungen eine Wallet erfüllt. Probieren Sie die Abläufe im Playground aus.
Darauf ausgelegt, ARF 3.0, OpenID4VP 1.0 und HAIP 1.0 zu folgen; nicht zertifiziert.
Gegen die Standards getestet
Was heißt das? Der CodeB-Aussteller ist der Dienst, der Karten in Ihre Wallet legt – Ihren digitalen Ausweis, Mitglieds- und Anmeldekarten. Der Prüfer ist der Dienst, der diese Karten prüft, wenn Sie sich damit anmelden. Damit sich Aussteller, Wallets und Dienste in ganz Europa verstehen, müssen alle nach demselben Regelwerk arbeiten – wie Stecker und Steckdose: Ist eine Seite anders gebaut, passt nichts.
Genau das prüft das offizielle Testlabor. Es spielt eine Wallet und führt über 250 Tests gegen unseren echten Dienst aus – ob jeder Schritt dem Regelwerk folgt und ob gefälschte, manipulierte oder wiederholte Anfragen abgewiesen werden. Im November 2026 hat unser Aussteller alle vier Testpläne für das Ausstellen von Karten bestanden und unser Prüfer beide Testpläne für das Prüfen – ohne fehlgeschlagenen Test.
Darauf sind wir stolz. Es zeigt, was über 20 Jahre Entwicklung in PDF, Smartcards und digitaler Identität – und das konsequente Bauen nach den Standards – wert sind: Wer sich von der ersten Zeile an an das Regelwerk hält, bekommt es von den Tests bestätigt.
Für Sie heißt das: Ihre Karten sprechen dieselbe Sprache wie jede Wallet und jeder Dienst, der dem europäischen Regelwerk folgt, statt an eine App gebunden zu sein, und ihr Schutz ist getestet, nicht nur versprochen. Welche Karten eine Wallet oder ein Dienst annimmt, entscheiden weiterhin Zertifikate und Vertrauenslisten.
Technisch: OpenID4VCI 1.0 und OpenID4VP 1.0 mit dem Profil HAIP 1.0 – die Standards, auf denen die EUDI Wallets aufbauen. Die Testpläne sind dieselben unabhängigen Testsuiten, die für die offizielle Zertifizierung dieser Protokolle verwendet werden. Das sind Tests unserer Server auf phone.codeb.io, keine Zertifizierung der CodeB Wallet selbst. Jedes Ergebnis lässt sich über seinen Link schreibgeschützt ansehen.
| Testplan | Format | Ergebnis |
|---|---|---|
| Aussteller: OpenID4VCI 1.0 + HAIP 1.0, von der Wallet gestartet | SD-JWT VC | Bestanden · 63 Tests, kein Fehlschlag · Ergebnisse ansehen |
| Aussteller: OpenID4VCI 1.0 + HAIP 1.0, von der Wallet gestartet | mdoc | Bestanden · 63 Tests, kein Fehlschlag · Ergebnisse ansehen |
| Aussteller: OpenID4VCI 1.0 + HAIP 1.0, vom Aussteller gestartet (Credential Offer) | SD-JWT VC | Bestanden · 63 Tests, kein Fehlschlag · Ergebnisse ansehen |
| Aussteller: OpenID4VCI 1.0 + HAIP 1.0, vom Aussteller gestartet (Credential Offer) | mdoc | Bestanden · 63 Tests, kein Fehlschlag · Ergebnisse ansehen |
| Prüfer: OpenID4VP 1.0 + HAIP 1.0, direct_post.jwt | SD-JWT VC | Bestanden · 14 Tests, kein Fehlschlag · Ergebnisse ansehen |
| Prüfer: OpenID4VP 1.0 + HAIP 1.0, direct_post.jwt | mdoc | Bestanden · 7 Tests, kein Fehlschlag · Ergebnisse ansehen |
Fragen von Entwicklern
Müssen wir OpenID4VP, SD-JWT VC oder ISO mdoc selbst umsetzen?
Nein. Das Gateway spricht die Wallet-Protokolle und prüft Signaturen, Vertrauensketten, Geräte-Bindung und Sperrstatus. Ihre Anwendung sieht eine Standard-OpenID-Connect-Anmeldung.
Welche OpenID-Connect-Bibliothek können wir nutzen?
Jede Bibliothek, die den Authorization-Code-Flow mit PKCE unterstützt und das Discovery-Dokument liest. Getestete Beispiele gibt es für ASP.NET Core, Visual Basic .NET, Node.js, Python, PHP, Java und Go.
Woran erkennen wir, dass die Person wirklich die Wallet benutzt hat?
Am acr-Claim des geprüften id_token: urn:codeb:acr:eudi-wallet oder urn:codeb:acr:eudi-wallet-linked. Lehnen Sie für Seiten, die die Wallet brauchen, jeden anderen Wert ab.
Welche personenbezogenen Daten erhalten wir?
Nur, was Sie anfragen, was Ihr Client darf und was die Person in der Wallet freigibt – zum Beispiel Name oder Geburtsdatum.