Skriv kundernes virkelige adgangsforløb ned
Begynd med tre personer: en almindelig medarbejder, en kundeadministrator og en ekstern konsulent. Beskriv, hvem der inviterer dem, hvordan de finder den rigtige kunde, og hvem der kan fjerne adgangen. Aftal også, om brugerne må oprette egne arbejdsområder, eller om hvert område skal være knyttet til en godkendt kundeaftale.
SSO betyder, at kunden bruger sit eget fælles login, eksempelvis gennem sin IT-afdeling. MFA er et ekstra godkendelsestrin ud over den første loginfaktor. Kravene kan være forskellige fra kunde til kunde. Derfor bør demonstrationen omfatte både et almindeligt login og et skift til en kunde med strengere krav.
Auth0: at finde virksomheden er ikke at få adgang
Hvis en bruger kun kender sin arbejdsmail, kan det være besværligt først at skulle skrive et internt navn på kundens arbejdsområde. Auth0s dokumentation beskriver både forløb, der starter med brugerens login, og forløb, der først vælger organisation. Domænegenkendelse kan hjælpe med at finde den relevante organisation eller loginforbindelse.
Dokumentationen siger samtidig, at Organization Domain Discovery ikke begrænser, hvem der kan registrere sig eller logge ind. Den forskel er vigtig: at systemet genkender virksomhedens maildomæne, må ikke forveksles med jeres beslutning om medlemskab og rettigheder. En konsulent med eget domæne skal desuden kunne få en bevidst tildelt adgang uden at blive presset ind i medarbejdernes standardforløb.
Bed om en demonstration med to kunder, der deler domæne, og en inviteret ekstern bruger. Kontrollér, hvor kunden vælges, og hvad der sker uden et match. Vi har ikke valideret en konkret Auth0-opsætning; tilgængelige forløb og medlemsregler skal afklares for jeres løsning.
Clerk: to faner kan betyde to forskellige kunder
En administrator kan have kundens faktura åben i én fane og en anden kundes rapport i en anden. Clerk beskriver i organisationsvejledningen, at hver fane har sin egen aktive organisation, mens browserens fælles sessionscookie kan afspejle den senest aktive kontekst. Baggrundskald må derfor ikke ukritisk stole på den fælles cookie; vejledningen beskriver brug af et token med den relevante organisationskontekst.
For køberen betyder det, at demonstrationen skal fortsætte efter selve kundeskiftet. Lad udvikleren skifte kunde i den ene fane og derefter genindlæse og udføre en ufarlig testhandling i den anden. Det synlige kundenavn, de viste data og den gemte handling skal stadig høre sammen. Prøv også et direkte link til en kunde, som testbrugeren ikke har adgang til.
Clerks rettighedsvejledning skelner desuden mellem systemrettigheder og egne rettigheder til serverkontrol. Det er en integrationsopgave at få jeres app til at kontrollere adgang korrekt. Vi har ikke udført en sikkerhedstest af Clerk eller jeres app; prøven er et foreslået acceptkriterium.
WorkOS: et kundeskift kan kræve nyt login
En bruger kan være medlem af flere kunders arbejdsområder, uden at de har samme sikkerhedskrav. WorkOS' organisationsvælger beskriver skift mellem tilgængelige organisationer og omdirigering til fornyet godkendelse, hvis den nye organisation kræver SSO eller MFA.
Det er relevant, når en ekstern rådgiver går fra en mindre kunde til en kunde med centralt styret login. Skiftet bør opleves som en forståelig overgang: brugeren skal vide, hvorfor der kommer et ekstra trin, og hvor vedkommende ender bagefter. Ellers risikerer support at behandle en tilsigtet kontrol som en loginfejl.
Få vist et gennemført og et afbrudt skift. Den gamle kundes data må ikke fremstå som den nye kundes, mens godkendelsen mangler. Dokumentationen viser en komponent og integrationsmuligheder; den beviser ikke, at jeres egen datalagring eller brugergrænseflade håndterer skiftet korrekt.
Bed om en prøve på fjernelse af adgang
Et vellykket førstegangslogin er kun begyndelsen. Opret en testbruger, giv adgang til to arbejdsområder og fjern medlemskabet af det ene. Prøv igen fra en allerede åben fane og efter et nyt login. Aftal på forhånd, hvor hurtigt fjernelsen skal slå igennem, og hvordan I kan se resultatet.
Brug kun ufarlige testdata i et afgrænset miljø. Kontrollen bør omfatte direkte links og forespørgsler til appens server, så en skjult knap ikke bliver det eneste bevis. Jeres udviklingspartner skal kunne forklare, hvordan medlemskab, rolle og den konkrete handling kontrolleres sammen.
Hvad tilbuddet skal indeholde
Bed leverandør og udviklingspartner adskille platformens funktioner fra integrationsarbejdet. Få blandt andet kundernes SSO-forbindelser, aktive brugere, organisationer, support og eventuelle tilkøb opgjort i tilbuddet. Afklar også eksport og flytning af brugere, hvis I senere skifter platform; en liste over mailadresser er ikke nødvendigvis en flytbar loginløsning.
Vælg efter de forløb, jeres kunder faktisk kræver. Har I eksterne rådgivere og flere kundepolitikker, er organisationsskift og tilbagekaldelse af adgang væsentlige. Har alle brugere kun én kunde, kan en enklere brugeroplevelse være tilstrækkelig, men serverens adgangskontrol skal stadig være konkret.
Kilder og metode
Dokumentationen fra Auth0, Clerk og WorkOS er læst 29. oktober 2026. Vi har ikke fastslået entydige udgivelsesdatoer for siderne. Guiden sammenligner dokumenterede arbejdsgange og vores forslag til evaluering, ikke målte sikkerhedsresultater. Der gives ingen garanti for en færdig apps sikkerhed eller for bestemte funktioner i en ukendt abonnementsplan.