Single-Sign-On mit OpenID Connect

Nur für Enterprise Lizenz Kunden

Single-Sign-On ist Teil der Enterprise Lizenz und wird in der Organisationsverwaltung eingerichtet.

Mit OpenID Connect (OIDC) melden sich Nutzer deiner Organisation mit ihrem Firmenkonto an, in der Webapp und in der Mobile App. AMS Go legt den Nutzer beim ersten Login automatisch an, ordnet ihn seinem Standort zu und kann Stammdaten wie Abteilung, Fachfunktion oder Personalnummer aus dem Verzeichnis übernehmen.

Diese Anleitung beschreibt die Einrichtung mit Microsoft Entra ID. Ein kurzer Abschnitt am Ende behandelt Keycloak.

Überblick

Die Einrichtung besteht aus drei Teilen:

1. In Entra eine App-Registrierung anlegen und AMS Go als Antwort-URL eintragen.
2. In AMS Go im Reiter OpenID Connect der Organisation die Daten aus Entra hinterlegen.
3. Festlegen, welche Angaben aus Entra in welches Feld in AMS Go übernommen werden (Claim-Mapping).

Dazwischen gibt es Prüfwerkzeuge (Verbindung prüfen, Test-Login starten, Letzte Claims), mit denen du jeden Schritt kontrollieren kannst, bevor Nutzer betroffen sind.

Parallelbetrieb mit SAML und oAuth

Eine bestehende SAML- oder oAuth-Konfiguration bleibt unberührt und funktioniert weiter. OpenID Connect hat eigene Einstellungen und einen eigenen Reiter. Du kannst OIDC vollständig einrichten und testen, während deine Nutzer sich weiterhin über SAML anmelden, und erst am Ende umschalten. Siehe Umstieg von SAML.

Teil 1: Einrichtung in Microsoft Entra

Alle Schritte finden im Entra Admin Center statt, Bereich Identität → Anwendungen.

App-Registrierung anlegen

1. App-Registrierungen → Neue Registrierung.
2. Name frei wählen, z. B. „AMS Go".
3. Kontotyp: Nur Konten in diesem Organisationsverzeichnis (Single-Tenant). Das ist Voraussetzung für Schritt Stammdaten ins Token holen.
4. Redirect-URI: Plattform Web, Wert ist die Antwort-URL aus dem Reiter OpenID Connect in AMS Go (dort gibt es einen Kopieren-Button). Sie lautet https://app.amsgo.de/auth/oidc/callback und ist für alle Organisationen gleich.
5. Registrieren.

Auf der Übersichtsseite der Registrierung findest du jetzt zwei Werte, die du in AMS Go brauchst:

Entra: Übersicht	AMS Go: Reiter OpenID Connect
Anwendungs-ID (Client)	Client-ID
Verzeichnis-ID (Mandant)	Mandanten-ID (Tenant)

Bestehende Registrierung weiterverwenden

Wenn für die Mobile App bereits eine App-Registrierung existiert (siehe veraltete App Einstellungen), kannst du diese weiterverwenden. Ergänze dann unter Authentifizierung nur die Web-Redirect-URI.

Client-Secret erzeugen

1. Zertifikate & Geheimnisse → Geheime Clientschlüssel → Neuer geheimer Clientschlüssel.
2. Beschreibung und Gültigkeit wählen (maximal 24 Monate).
3. Sofort die Spalte Wert kopieren. Der Wert ist nach dem Verlassen der Seite nicht mehr sichtbar.

Entra: Secret	AMS Go
Wert	Client-Secret
Läuft ab	Secret läuft ab am

Häufige Verwechslungen

• Lege einen geheimen Clientschlüssel an, kein Zertifikat. AMS Go unterstützt keine Zertifikatsauthentifizierung.
• Kopiere den Wert, nicht die Geheimnis-ID. Beides sind lange Zeichenfolgen; die Geheimnis-ID wird nirgends eingetragen.
• Die Client-ID stammt von der Übersichtsseite (Anwendungs-ID), nicht von der Secret-Seite. Die GUID neben dem Secret ist eine andere.

Ein falscher oder fehlender Wert führt beim Login zu „Das Anmelde-Token ist ungültig (invalid_client)".

Variante ohne Secret

Die Redirect-URI kann alternativ unter der Plattform Mobile- und Desktopanwendungen eingetragen werden. Dann läuft der Login ohne Secret (PKCE), das Feld Client-Secret in AMS Go bleibt leer, und es gibt nichts, das abläuft. Microsoft empfiehlt das für Web-Anwendungen nicht, manche Tenant-Richtlinien blockieren öffentliche Clients, und für spätere Funktionen wie den Verzeichnis-Abgleich wird ohnehin ein Secret gebraucht. Für Produktivbetrieb empfehlen wir die Variante mit Secret.

Wichtig: Steht die Redirect-URI unter Web, ist das Secret Pflicht. Ohne Secret antwortet Entra mit invalid_client.

Berechtigungen

1. API-Berechtigungen → Berechtigung hinzufügen → Microsoft Graph → Delegierte Berechtigungen.
2. openid, profile und email hinzufügen.
3. Administratorzustimmung erteilen, damit Nutzer beim ersten Login keinen Zustimmungsdialog sehen.

User.Read wird nur benötigt, wenn du den Graph-Fallback nutzt.

E-Mail ins Token holen

Tokenkonfiguration → Optionalen Anspruch hinzufügen → Tokentyp ID → email und upn anhaken.

Ohne diesen Schritt enthält das Token nur preferred_username. Das ist meist die E-Mail-Adresse, aber nicht garantiert. AMS Go braucht die E-Mail zwingend, um den Nutzer anzulegen oder einen bestehenden Nutzer zu erkennen.

Stammdaten ins Token holen

Entra liefert Abteilung, Bürostandort, Position und Personalnummer nicht von sich aus mit. Dafür braucht es zwei Schritte:

1. Zugeordnete Ansprüche erlauben

App-Registrierung → Manifest. Verwende das Microsoft Graph-App-Manifest (das AAD Graph-Manifest ist veraltet). Suche den Block api und setze darin "acceptMappedClaims": true. Speichern.

"api": {
    "acceptMappedClaims": true,
    ...
}

2. Ansprüche definieren

Unternehmensanwendungen → deine App → Single Sign-On → Attribute und Ansprüche → Bearbeiten → Neuen Anspruch hinzufügen. Pro Zeile:

Name	Namespace	Quelle	Quellattribut	Wird in AMS Go
officeLocation	leer	Attribut	user.officelocation	Standort (Zuordnung zum Team)
department	leer	Attribut	user.department	Abteilung
jobTitle	leer	Attribut	user.jobtitle	Fachfunktion (Freitext)
employeeId	leer	Attribut	user.employeeid	Mitarbeiterkennung
employeeHireDate	leer	Attribut	user.employeehiredate	Eintrittsdatum

Weitere Attribute (Kostenstelle, Schicht, Geburtsdatum, Geschlecht) sind in Entra keine Standardfelder. Wenn dein Unternehmen sie in extensionAttribute1 bis 15 pflegt, kannst du sie genauso als Anspruch mit frei gewähltem Namen hinzufügen und in AMS Go zuordnen.

Fallstricke

• Richtige App: Die Unternehmensanwendung muss dieselbe Anwendungs-ID haben wie die App-Registrierung. Bei mehreren gleichnamigen Apps landet man leicht in der falschen.
• Namespace leer lassen: Ein gesetzter Namespace verändert den Namen des Anspruchs im Token zu einer langen URL. Dann passt die Vorlage in AMS Go nicht mehr.
• Hinweis zu Signaturschlüsseln ignorieren: Entra zeigt an dieser Stelle die Meldung „OIDC-Anwendungen erfordern benutzerdefinierte Signaturschlüssel, um Ansprüche anzupassen". Das ist der allgemeine Hinweis; mit acceptMappedClaims bei einer Single-Tenant-App ist kein Schlüssel nötig. Lege keinen benutzerdefinierten Signaturschlüssel an. Mit eigenem Schlüssel kann AMS Go die Tokens nicht mehr prüfen und lehnt jeden Login ab.
• Leere Attribute fehlen im Token: Ist beim Nutzer in Entra kein Bürostandort oder keine Abteilung gepflegt, wird der Anspruch gar nicht erst mitgeschickt.
• Frisches Login: Entra liefert innerhalb einer Browsersitzung gecachte Tokens. Nach jeder Änderung in Entra den Test-Login in einem neuen privaten Fenster starten, nicht nur die Seite neu laden.

Nutzer vorbereiten

• Zuweisung erforderlich? Unter Unternehmensanwendungen → deine App → Eigenschaften. Steht sie auf Ja, muss jeder Nutzer unter Benutzer und Gruppen einzeln zugewiesen werden, bevor er sich anmelden darf. Auf Nein dürfen sich alle Nutzer des Tenants anmelden; AMS Go entscheidet dann über Domain und Standort, wer hineinkommt. Für Organisationen ohne Entra ID P1 ist Nein meist die praktikable Wahl, weil die Zuweisung ganzer Gruppen dort nicht verfügbar ist.
• Attribute pflegen: Beim Nutzer unter Benutzer → Eigenschaften → Auftragsinformationen müssen E-Mail, Bürostandort und Abteilung gefüllt sein. Der Bürostandort muss exakt dem Namen eines Standorts (Teams) in der Organisation entsprechen, Groß-/Kleinschreibung ist egal. Abweichende Namen lassen sich über die Wert-Zuordnung übersetzen.

Teil 2: Einstellungen in AMS Go

Öffne die Organisation und wechsle in den Reiter OpenID Connect.

Antwort-URL

Oben steht die Antwort-URL mit Kopieren-Button. Sie gehört in Entra in die Redirect-URI der App-Registrierung. Darunter siehst du, ob ein Secret hinterlegt ist und wann es abläuft.

Verbindung

Feld	Bedeutung
OpenID Connect aktiviert	Schaltet den OIDC-Login für diese Organisation frei (Test-Login, Web und App).
Standard für Domain-Anmeldung	Erst einschalten, wenn die Erprobung abgeschlossen ist. Leitet die Anmeldung über „Mit Single-Sign-On anmelden" auf OIDC statt auf SAML.
OIDC erzwingen	Nutzer der Domain können sich nicht mehr mit Passwort anmelden.
Anbieter	Microsoft Entra ID, Keycloak oder Generisch.
Mandanten-ID (Tenant)	Nur bei Entra. Verzeichnis-ID aus der Übersichtsseite.
Issuer	Nur bei Keycloak/Generisch. Basis-URL des Anbieters.
Client-ID	Anwendungs-ID aus der Übersichtsseite.
Client-Secret	Wert des Secrets. Wird nach dem Speichern nie wieder angezeigt; leer speichern behält das gespeicherte Secret.
Secret läuft ab am	Ablaufdatum aus Entra. In der Organisationsliste erscheint rechtzeitig eine Warnung.
Scopes	openid profile email; mit Graph-Fallback zusätzlich User.Read.
Domain	E-Mail-Domain der Nutzer, z. B. firma.de. Nur Nutzer mit dieser Domain werden akzeptiert.
Standard Rolle für neue Nutzer	Rolle, die neue Nutzer im Standort bekommen, wenn das Mapping keine Rolle liefert.
Stammdaten-Abgleich	Nur beim Anlegen: Daten aus Entra werden nur beim ersten Login geschrieben, spätere Pflege in AMS Go bleibt erhalten. Bei jedem Login: Entra ist führend und überschreibt gelieferte Werte.
Graph-Fallback	Siehe Graph-Fallback.

Speichern, dann Verbindung prüfen. Das Ergebnis muss „Issuer stimmt überein" und eine Anzahl Signaturschlüssel größer null zeigen. Schlägt die Prüfung fehl, sind Mandanten-ID oder Issuer falsch.

Test-Login

Test-Login starten öffnet den OIDC-Login dieser Organisation direkt, unabhängig davon, ob „Standard für Domain-Anmeldung" aktiv ist. Das funktioniert auch, wenn du angemeldet bist: Nach erfolgreichem Login bist du als der per Entra angemeldete Nutzer eingeloggt und die vorherige Sitzung ist beendet.

Am besten in einem privaten Fenster starten, weil Entra dich sonst ohne Nachfrage mit dem zuletzt genutzten Microsoft-Konto anmeldet.

Letzte Claims

Diese Karte ist das wichtigste Werkzeug bei der Einrichtung. Sie zeigt nach jedem OIDC-Login (auch nach einem abgewiesenen) für 24 Stunden:

• den Grund, falls der Login abgewiesen wurde,
• die Rohdaten, also alle Angaben, die im Token von Entra angekommen sind,
• das Mapping-Ergebnis, also was AMS Go daraus in seine Felder übernommen hat,
• nicht gemappte Claims, also Angaben im Token, die kein Mapping verwendet,
• Hinweise, etwa ungültige Datumsformate oder unbekannte Werte.

Fehlt in den Rohdaten etwa department, liegt das Problem in Entra (Stammdaten ins Token holen). Steht department in den Rohdaten, aber nicht im Mapping-Ergebnis, fehlt die Zeile im Claim-Mapping.

Teil 3: Claim-Mapping

Das Claim-Mapping legt fest, welche Angabe aus dem Token (Claim) in welches Feld in AMS Go geschrieben wird. Es ist eine Liste von Zeilen mit den Spalten Zielfeld, Claim, Datumsformat, Wert-Zuordnung und Standardwert.

Vorlage laden

Mit Vorlage Entra laden wird eine passende Liste eingesetzt und sofort gespeichert. Sie deckt E-Mail, Name, Standort, Abteilung, Fachfunktion, Personalnummer, Eintrittsdatum und Kostenstelle ab und passt zu den Ansprüchen aus Stammdaten ins Token holen. Für einen ersten Test reicht die Vorlage ohne Änderung.

Zielfelder

Zielfeld	Landet in	Hinweis
E-Mail	Nutzer	Pflicht. Mehrere Kandidaten möglich, z. B. email, upn, preferred_username.
Name	Nutzer	join(given_name+family_name) setzt Vor- und Nachname zusammen.
Standort (Team)	Zuordnung zum Standort	Wert muss einem Standortnamen entsprechen, oder über die Wert-Zuordnung übersetzt werden.
Abteilung	Abteilung im Standort	Wird angelegt, wenn sie noch nicht existiert.
Fachfunktion (Freitext)	Nutzer	z. B. Position.
Rolle	Rolle im Standort	Siehe Rollen aus Entra.
Mitarbeiterkennung, Eintrittsdatum, Austrittsdatum, Kostenstelle, Schicht, Mitgliedschaftsstatus	Mitgliedschaft im Standort
Geburtsdatum, Geschlecht	Nutzer
Fachfunktionen (Liste)	Fachfunktionen des Standorts	Namen müssen im Standort existieren.
Subject (stabile ID)	Nutzer	Stabile Kennung aus Entra, wird automatisch gesetzt.

Claim

Name der Angabe im Token, so wie sie in den Rohdaten unter Letzte Claims erscheint. Mehrere Kandidaten werden durch Komma getrennt; der erste, der einen Wert hat, gewinnt. Verschachtelte Angaben werden mit Punkt adressiert (realm_access.roles).

Datumsformat

Nur für Datumsfelder. Beschreibt, wie das Datum im Token aussieht, z. B. Y-m-d für 2024-03-01 oder d.m.Y für 01.03.2024. Ungültige Werte werden ignoriert und unter Hinweisen gemeldet, der Login schlägt dadurch nicht fehl.

Wert-Zuordnung

Die Wert-Zuordnung übersetzt Werte aus Entra in Werte, die AMS Go erwartet, eine Zeile je Paar im Format quelle=ZIEL. Sie ist bei den meisten Zeilen leer, und das ist richtig so: E-Mail, Name, Personalnummer oder Datum werden unverändert übernommen. Gebraucht wird sie nur in zwei Fällen:

Felder mit festen Werten (Rolle, Geschlecht, Schicht, Mitgliedschaftsstatus, Aktiv). Beispiel Geschlecht, wenn Entra m/w/d liefert:

m=MALE
w=FEMALE
d=DIVERSE

Passt kein Eintrag, greift der Standardwert; ist auch der leer, bleibt das Feld unberührt.

Abweichende Namen bei Standort und Abteilung. Hier wirkt die Zuordnung als Synonymliste, alles ohne Eintrag wird unverändert durchgereicht:

Werk Nord=Berlin
HQ=Zentrale

Warum die Vorlage leere Zuordnungen hat

Die Vorlage kennt deine Werte nicht. Welche Gruppe Administrator bedeutet oder ob dein Verzeichnis m oder male führt, weißt nur du. Für einen ersten Login ist keine Zuordnung nötig.

Rollen aus Entra

Standardmäßig bekommen alle per SSO angelegten Nutzer die Standard Rolle für neue Nutzer. Administratoren und Maintainer werden wie gewohnt in AMS Go hochgestuft; bei Stammdaten-Abgleich: nur beim Anlegen bleibt das dauerhaft erhalten. Für die meisten Organisationen ist das ausreichend und erfordert keine Einrichtung in Entra.

Wer Rollen zentral in Entra pflegen will, hat zwei Möglichkeiten:

Bestehende Sicherheitsgruppen (keine Lizenz nötig, keine Zuweisung einzelner Nutzer)

1. Entra: App-Registrierung → Tokenkonfiguration → Gruppenanspruch hinzufügen → Sicherheitsgruppen, Format Gruppen-ID.
2. Nach einem frischen Login erscheint in den Rohdaten groups mit den Objekt-IDs aller Gruppen des Nutzers.
3. AMS Go: Zeile mit Zielfeld Rolle, Claim groups, Standardwert USER und in der Wert-Zuordnung die Objekt-IDs der Gruppen:

7c1b3f52-0d1a-4c9e-9a21-2e0f1b7d8a44=ADMINISTRATOR
2f9a6e10-83b5-4d77-b6c0-5f41d2e9c7aa=MAINTAINER

Ist ein Nutzer in mehreren zugeordneten Gruppen, gewinnt die oberste Zeile. Die Administrator-Gruppe gehört deshalb nach oben. Die Objekt-ID steht in Entra unter Gruppen → Gruppe → Übersicht.

Grenzen

• Die Option „Der Anwendung zugewiesene Gruppen" setzt voraus, dass Gruppen der App zugewiesen sind. Das ist ein Feature von Entra ID P1; ohne P1 erscheint „Gruppen sind in Ihrer Active Directory-Planebene nicht für die Zuweisung verfügbar". Wähle dann Sicherheitsgruppen.
• Ist ein Nutzer in mehr als 200 Gruppen, liefert Entra keine Liste mehr. Dann greift der Standardwert.

App-Rollen (sauberer, Zuweisung pro Nutzer oder, mit Entra ID P1, pro Gruppe)

1. App-Registrierung → App-Rollen: Rollen mit dem Wert ADMINISTRATOR, MAINTAINER, USER anlegen, Mitgliedstyp Benutzer/Gruppen.
2. Unternehmensanwendung → Benutzer und Gruppen → Hinzufügen: Nutzer (oder mit P1 eine Gruppe) auswählen und eine Rolle zuweisen.
3. AMS Go: Zeile mit Zielfeld Rolle, Claim roles, Wert-Zuordnung leer, Standardwert USER. Heißen die Rollenwerte in Entra anders, übersetzt die Wert-Zuordnung sie, z. B. Admin=ADMINISTRATOR.

Ohne P1 bedeutet das eine Zuweisung pro Nutzer. Bei vielen Nutzern ist der Weg über Sicherheitsgruppen oder die Standard-Rolle praktikabler.

Graph-Fallback

Übergangslösung, solange die Ansprüche aus Stammdaten ins Token holen noch nicht im Token ankommen. Ist der Schalter aktiv und steht User.Read in den Scopes, liest AMS Go Abteilung, Bürostandort und Position nach dem Login aus Microsoft Graph nach. Angaben, die bereits im Token stehen, haben Vorrang.

Sobald die Ansprüche im Token sind, schalte den Fallback ab und entferne User.Read aus den Scopes.

Was beim Login passiert

1. AMS Go prüft das Token und die E-Mail-Domain. Passt die Domain nicht, wird der Login abgewiesen.
2. Der Nutzer wird gesucht: zuerst über die stabile Entra-Kennung, dann über die Mitarbeiterkennung, dann über die E-Mail-Adresse. Bestehende Nutzer, die bisher per SAML, Passwort oder Einladung angelegt wurden, werden also über die E-Mail erkannt. Es entstehen keine Doppelkonten.
3. Gibt es den Nutzer nicht, wird er angelegt.
4. Der Standort aus dem Token wird gesucht. Ein neuer Nutzer ohne auffindbaren Standort wird mit der Meldung „Der Standort, der für deinen Nutzer hinterlegt ist wurde noch nicht in AMS Go hinterlegt" abgewiesen. Ein Nutzer, der bereits Mitglied eines Standorts der Organisation ist, darf sich auch ohne Standort anmelden.
5. Der Nutzer wird dem Standort mit der Rolle aus dem Mapping oder der Standard-Rolle hinzugefügt. Liefert Entra später einen anderen Standort, wird der Nutzer zusätzlich dort aufgenommen, nie entfernt.
6. Abteilung, Fachfunktion und die weiteren gemappten Felder werden geschrieben, abhängig vom Stammdaten-Abgleich.

Meldung „Standort … noch nicht hinterlegt"

Diese Meldung ist beim ersten Test fast immer der Fall. Unter Letzte Claims siehst du im Mapping-Ergebnis, welcher Wert bei Standort angekommen ist. Entweder den Standort in AMS Go so benennen, eine Synonymzeile in der Wert-Zuordnung anlegen, oder den Nutzer vorab in einen Standort der Organisation aufnehmen.

Umstieg von SAML

Eine Organisation mit laufender SAML-Anmeldung stellt in dieser Reihenfolge um; zu keinem Zeitpunkt ist die Anmeldung unterbrochen:

1. Teil 1 bis 3 durchführen. OpenID Connect aktiviert einschalten, Standard für Domain-Anmeldung ausgeschaltet lassen. Nutzer melden sich weiter per SAML an.
2. Mit Test-Login starten und Letzte Claims mehrere Nutzer prüfen, Mapping nachjustieren. Bestehende Nutzer werden über die E-Mail erkannt; Voraussetzung ist, dass die E-Mail in AMS Go dem email- oder upn-Anspruch in Entra entspricht.
3. Standard für Domain-Anmeldung einschalten. Ab jetzt landet die Anmeldung über „Mit Single-Sign-On anmelden" bei OIDC. Rückweg: Schalter wieder aus, SAML greift sofort wieder.
4. Mobile App auf OIDC umstellen, siehe Mobile App.
5. Wenn alles stabil läuft: OIDC erzwingen einschalten und die SAML-Unternehmensanwendung in Entra deaktivieren. Die SAML-Einstellungen in AMS Go können bleiben, sie werden nicht mehr verwendet.

Mobile App

Die Mobile App nutzt dieselbe App-Registrierung, dieselbe Organisation und dasselbe Claim-Mapping. Zusätzlich zur Web-Redirect-URI muss in Entra unter Authentifizierung → Mobile- und Desktopanwendungen die URI amscockpit://auth/callback eingetragen sein (bei einer bestehenden Registrierung ist sie bereits vorhanden).

Die Umstellung der App auf OpenID Connect erfolgt mit einem App-Update. Bis dahin verwendet die App weiterhin die Einstellungen aus dem Reiter oAuth.

Keycloak und andere Anbieter

Jeder Anbieter mit OpenID-Connect-Discovery funktioniert. Für Keycloak:

• Anbieter Keycloak, Issuer ist die Realm-URL, z. B. https://login.firma.de/realms/firma.
• Client als Public Client mit PKCE S256 (kein Secret) oder als Confidential Client mit Secret, Redirect-URI wie oben.
• E-Mail der Nutzer muss im Realm als verifiziert markiert sein, sonst wird der Login abgewiesen.
• Pro Stammdatenfeld einen Protocol Mapper „User Attribute → Token Claim" mit aktiviertem ID-Token anlegen. Die Vorlage Keycloak in AMS Go erwartet die Namen location, department, job_title, employee_id, hire_date, birthdate, gender, cost_center, shift.
• Rollen kommen aus realm_access.roles (Vorlage: ams-admin und ams-maintainer) oder aus Client-Rollen unter resource_access.<client>.roles.

Für einen generischen Anbieter wähle Generisch und trage den Issuer ein; das Mapping baust du anhand der Rohdaten unter Letzte Claims.

Fehlersuche

Meldung oder Symptom	Ursache	Lösung
Verbindung prüfen schlägt fehl	Mandanten-ID oder Issuer falsch, Anbieter nicht erreichbar	Werte mit der Übersichtsseite in Entra abgleichen
„Anmelde-Token ist ungültig (invalid_client)"	Kein oder falsches Secret bei Redirect-URI unter Plattform Web	Secret-Wert eintragen, oder URI nach „Mobile- und Desktopanwendungen" verschieben
„Anmelde-Token ist ungültig" ohne Zusatz	Signatur, Issuer oder Client-ID passen nicht; benutzerdefinierter Signaturschlüssel in Entra	Client-ID prüfen, eigenen Signaturschlüssel entfernen
„E-Mail-Domain stimmt nicht mit der Organisation überein"	Domain in AMS Go passt nicht zur E-Mail des Nutzers	Domain korrigieren oder email-Anspruch in Entra ergänzen
„Standort … noch nicht hinterlegt"	Bürostandort fehlt, kommt nicht im Token an oder passt zu keinem Standortnamen	Letzte Claims prüfen, Ansprüche in Entra ergänzen, Synonym anlegen oder Standort umbenennen
department/officeLocation fehlen in den Rohdaten	acceptMappedClaims nicht gesetzt, Anspruch in falscher App oder mit Namespace, Attribut beim Nutzer leer, gecachtes Token	Abschnitt Stammdaten ins Token holen, dann Login im privaten Fenster
groups fehlt in den Rohdaten	Gruppenanspruch nicht konfiguriert oder Nutzer in keiner passenden Gruppe	Tokenkonfiguration prüfen, Option „Sicherheitsgruppen" wählen
Nutzer wurde angelegt, aber mit falscher Rolle	Rolle wird nur beim Anlegen gesetzt	Rolle in AMS Go ändern, oder Stammdaten-Abgleich auf „bei jedem Login" stellen
„Die Anmeldung konnte nicht zugeordnet werden"	Login-Vorgang abgelaufen oder in anderem Browser gestartet	Login erneut starten
Test-Login meldet mich sofort ohne Nachfrage an	Entra verwendet die bestehende Microsoft-Sitzung	Privates Fenster verwenden