Single Sign-On (SSO) med OpenID Connect (OIDC) gör det möjligt för er organisation att autentisera användare via en central identitetsleverantör (IdP), medan Tagd fungerar som förlitande part (relying party). Er identitetsleverantör ansvarar för autentiseringen, inklusive multifaktorautentisering och villkorsstyrd åtkomst, och Tagd ser aldrig något lösenord.
Förutsättning: En identitetsleverantör som stöder OpenID Connect med authorization code-flödet och ett publicerat discovery-dokument (till exempel Microsoft Entra ID (Azure AD), Okta eller Google Workspace).
Viktigt: Tagd autentiserar mot er token-endpoint med client_secret_post. client_secret_basic, som är standard i de flesta identitetsleverantörer, stöds inte. Om er identitetsleverantör inte kan använda client_secret_post, använd SAML 2.0 i stället.
Följande uppgifter behövs när ni konfigurerar er identitetsleverantör:
Parameter | Värde |
Sign-in redirect URI | https://tagd-prod-platform.auth.eu-north-1.amazoncognito.com/oauth2/idpresponse |
Grant type | Authorization code |
Scopes | openid email profile |
Klientautentisering | client_secret_post |
Signering av ID-token | RS256, ES256 eller HS256, med ett kid publicerat i er JWKS-endpoint |
Skapa en applikation i er identitetsleverantör:
Skapa en ny OpenID Connect-applikation av typen Web Application, en konfidentiell klient med en klienthemlighet (client secret). En applikation av typen single-page eller native/mobil fungerar inte
Sätt grant type till Authorization Code och ange sign-in redirect URI från tabellen ovan
Sätt klientautentisering till client_secret_post
Konfigurera de claims som ska skickas med i ID-token
email (Obligatoriskt, ges av scopet email)
given_name (förnamn, ges av scopet profile)
family_name (efternamn, ges av scopet profile)
groups (Obligatoriskt, minst en grupp krävs). Om groups finns under scopes_supported i ert discovery-dokument (https://<er-issuer>/.well-known/openid-configuration) behöver inget konfigureras. Lägg annars till ett groups-claim i applikationen. Claimet måste skickas i ID-token eller i userinfo-svaret, inte enbart i access-token. Gruppnamn får endast innehålla bokstäver, siffror och . - * _ (till exempel Acme-Legal, inte Acme Legal)
Tilldela testanvändare till både applikationen och gruppen. En användare som inte är tilldelad kan inte logga in
Välj en utloggnings-URL (Obligatoriskt). Antingen er identitetsleverantörs utloggningsadress, som även loggar ut användaren från identitetsleverantören, eller en landningssida, till exempel ert intranät. Adressen måste börja med https://. Lägg även till den bland applikationens sign-out redirect URIs
Välj önskat inloggningsalias, till exempel "foretaget". Er inloggningslänk blir då https://prod.tagd.ai/api/v1/auth/login?org=foretaget. Använd endast gemener (a–z), siffror och bindestreck
Skicka följande uppgifter till [email protected]
Issuer URL, exakt som den anges i ert discovery-dokument (https://, utan avslutande snedstreck)
Client ID
Client secret, skickad via en säker kanal, till exempel en delningslänk från en lösenordshanterare. Inte i själva e-postmeddelandet eller i en chatt
Bekräftelse på att klientautentiseringen är satt till client_secret_post
Utloggnings-URL
Önskat inloggningsalias
Testanvändarens e-postadress
Namn på de grupper som ska synkroniseras, stavade exakt som i groups-claimet
Claim-namn, om de skiljer sig från email, given_name, family_name och groups
Valfritt: en grupp som ska ge rollen Administratör i Tagd
Namn och e-postadress till en teknisk kontaktperson för driftsättningen
Skicka aldrig användarlösenord, privata nycklar eller API-nycklar för er identitetsleverantör. När uppgifterna har tagits emot konfigurerar vårt team OpenID Connect-autentiseringen för er organisation.
Innan SSO rullas ut till alla användare testas konfigurationen tillsammans med någon från vårt team.
Öppna inloggningslänken och kontrollera att den leder direkt till er identitetsleverantör
Gör en testinloggning med ett användarkonto i identitetsleverantören, inklusive eventuellt multifaktorsteg
Kontrollera att användarens namn och e-postadress visas korrekt i Tagd
Kontrollera att användaren läggs till i rätt grupp i Tagd och har förväntad roll
Kontrollera att utloggning avslutar sessionen i Tagd och leder till er utloggnings-URL
Kontrollera att en användare som inte är tilldelad applikationen inte kan logga in
Vi rekommenderar starkt att ni först testar med en begränsad grupp användare. Rapportera eventuella problem till [email protected]
Samordna driftsättningen av SSO-integrationen tillsammans med er kontaktperson hos oss:
Bestäm datum för driftsättning och se till att er tekniska kontaktperson är nåbar under driftsättningen.
Tilldela användare till Tagd-applikationen i er identitetsleverantör. När en användare loggar in via SSO för första gången skapas kontot automatiskt eller kopplas till ett befintligt konto utifrån e-postadressen. Gruppmedlemskap från er identitetsleverantör lägger till användaren i motsvarande grupper i Tagd.
Informera era användare om förändringen och dela inloggningslänken. Användarna loggar in med sina vanliga jobbuppgifter och behöver inget separat lösenord till Tagd.