Sikre brugerinvitationer til medarbejdere og kunder

Se invitationen som en adgangsbeslutning

Login beviser, hvem brugeren er. Invitationen afgør, om netop den identitet må blive medlem af en bestemt virksomhed i appen, og med hvilke rettigheder. De to kontroller skal mødes på serveren, før medlemskabet oprettes. Et gyldigt login alene giver ikke ret til at vælge en virksomhed, og et invitationslink alene bør ikke blive en permanent session til hele appen.

Gem en ventende invitation før emailen sendes

Opret invitationen som en selvstændig post i databasen. Den er endnu ikke en bruger eller et medlemskab. Den beskriver blot den adgang, som en autoriseret administrator har tilbudt en bestemt modtager. Så kan appen vise, tilbagekalde, udløbe og revidere ventende invitationer uden at oprette aktive konti på forhånd.

• Fastlæg omfanget: Gem virksomhed, tiltænkt rolle, inviteret email eller identitetsreference samt hvem der inviterede.
• Gem livscyklussen: Oprettelsestid, udløb, indløst tidspunkt, tilbagekaldelse og den bruger, der faktisk accepterede.
• Adskil status: En sendt email, en gyldig invitation og et aktivt medlemskab er tre forskellige tilstande.
• Forebyg dubletter: Beslut hvad der sker, hvis personen allerede er medlem, eller hvis en tilsvarende invitation allerede venter.

Lad aldrig browseren vælge virksomhed eller rolle

Formularen må gerne vise mulige roller, men serveren skal kontrollere, at den inviterende bruger stadig må administrere den valgte virksomhed og højst må tildele den valgte rolle. Det gælder både når invitationen oprettes, og når den accepteres. OWASP anbefaler som udgangspunkt at afvise adgang og kontrollere rettigheder ved hver request; skjulte felter og værdier i et link er stadig brugerinput.

Behandl invitationslinket som en kortlivet nøgle

Den, der får fat i linket, kan forsøge at bruge det. Følg derfor samme grundprincipper som ved andre følsomme emaillinks: Tokenet skal være uforudsigeligt, knyttet til én invitation, opbevares sikkert, have et passende udløb og kun kunne bruges én gang. Selve linket skal bruge HTTPS og et fast, godkendt domæne.

• Gem ikke den brugbare hemmelighed i klartekst: Ved en egen løsning kan serveren gemme en hash af et kryptografisk tilfældigt token og sammenligne ved indløsning.
• Udløb og tilbagekald: En genudsendelse bør oprette en ny gyldig invitation eller et nyt token og gøre den tidligere vej ubrugelig.
• Begræns lækage: Skriv ikke hele linket eller tokenet i logs, analyseværktøjer, supportsager eller revisionsspor.
• Beskyt endpointet: Sæt grænser for oprettelse, genudsendelse og forsøg på indløsning, så funktionen ikke bliver spam- eller gætteværktøj.

Bind linket til den identitet, der blev inviteret

Efter klik skal modtageren logge ind eller oprette sig gennem appens normale identitetsløsning. Hvis invitationen er sendt til en bestemt emailadresse, skal appen eller identitetsudbyderen kontrollere, at den verificerede identitet matcher denne adresse. Firebase kræver eksempelvis den oprindelige email ved afslutning af login med emaillink og fraråder at genbruge en email fra redirect-parametre, fordi det kan åbne for session injection. Auth0s organisationsinvitationer kræver tilsvarende login eller oprettelse med den inviterede email.

1. Vis tilbuddet tydeligt. Fortæl hvilken virksomhed der inviterer, hvilken adgang der gives, og lad brugeren acceptere eller afvise.
2. Godkend identiteten. Brug den valgte loginleverandørs verificerede identitet frem for en email eller et bruger-id fra browseren.
3. Hent invitationen igen. Kontrollér på serveren token, udløb, tilbagekaldelse, modtager, virksomhed og rolle mod den aktuelle database.
4. Opret medlemskabet atomisk. Markér invitationen som brugt og opret højst ét medlemskab i samme transaktion eller tilsvarende atomiske operation.
5. Start en normal session. Efter accept skal alle senere requests stadig gennem appens almindelige adgangskontrol.

Vælg ansvar efter jeres loginplatform

Den rigtige løsning afhænger af den stack, appen allerede bruger. En identitetsplatform kan håndtere link, login og indløsning, men appens egne dataregler skal stadig afgøre, hvad medlemskabet giver adgang til.

Gør fejl og genudsendelse forståelige

Invitationen kan være udløbet, tilbagekaldt, allerede brugt eller åbnet med en anden konto. Vis en rolig status uden at afsløre unødvendige kontooplysninger. En administrator kan have en kontrolleret funktion til at tilbagekalde eller sende en ny invitation, mens modtageren bør få én sikker vej til hjælp frem for at kunne gætte sig frem til, hvilke emails der allerede har konto.

Gem revisionshændelser for oprettelse, genudsendelse, tilbagekaldelse, afvisning og accept med aktør, virksomhed, tiltænkt rolle og resultat. Gem ikke det aktive token.

Test hele forløbet – også de forkerte veje

• En bruger uden administrationsret forsøger at invitere, og en administrator forsøger at tildele en rolle over sit eget niveau.
• Virksomheds-id, rolle, email og redirect ændres i browseren eller i invitationslinket.
• Linket åbnes med den rigtige konto, en forkert konto, en uverificeret email og på en anden enhed.
• Det samme link klikkes to gange eller næsten samtidigt fra to browsere.
• Invitationen er udløbet, tilbagekaldt, genudsendt eller allerede accepteret.
• Modtageren er allerede medlem, har en ventende invitation eller findes med en anden loginmetode.
• Emailen kan ikke leveres, og en genudsendelse sker flere gange hurtigt.
• Efter accept prøver brugeren at læse eller ændre data i en anden virksomhed og med en højere rolle.
• Administrator tilbagekalder medlemskabet, hvorefter aktive sessioner og følsomme handlinger kontrolleres igen.

Typiske fejl

• Invitationen opretter straks en aktiv bruger: En forkert email eller uleveret besked efterlader en konto med adgang.
• Rollen ligger kun i linket: En parameter ændres, eller et gammelt link giver adgang efter en rolleændring.
• Enhver indlogget konto kan acceptere: Et videresendt link binder den forkerte person til virksomheden.
• Linket kan bruges igen: Genafspilning eller to samtidige klik opretter dubletter eller uventede medlemskaber.
• Genudsendelse genbruger hemmeligheden: Den gamle email forbliver en gyldig adgangsvej.
• Emaillevering forveksles med accept: Appen viser personen som medlem, før identitet og tilbud er godkendt.
• Kun den gode vej testes: Forkert virksomhed, rolle, konto, timing og udløb bliver aldrig afprøvet.

Tjekliste før invitationer åbnes for rigtige brugere

• ☐ Serveren kontrollerer, hvem der må invitere til hver virksomhed og rolle.
• ☐ En invitation er adskilt fra både brugerkonto og aktivt medlemskab.
• ☐ Virksomhed, rolle, modtager, afsender, status og udløb gemmes på serveren.
• ☐ Tokenet er uforudsigeligt, opbevares sikkert, udløber og kan kun bruges én gang.
• ☐ Linket bruger HTTPS og et fast, godkendt domæne og holdes ude af logs og analyse.
• ☐ Den accepterende identitet matcher den inviterede efter den valgte platforms regler.
• ☐ Accept genkontrollerer invitationen og opretter højst ét medlemskab atomisk.
• ☐ Gensendelse, udløb, tilbagekaldelse, dubletter og eksisterende konti har tydelig adfærd.
• ☐ Revisionssporet viser hændelser og resultat uden at gemme brugbare tokens.
• ☐ Negative tests dækker forkert konto, virksomhed, rolle, status og samtidighed.
• ☐ Medlemskab og sessioner kan fjernes igen ved fejl eller fratrædelse.

Relaterede guides

Officielle kilder

Guiden samler generelle sikkerhedsprincipper og officielle leverandørflows. Den konkrete løsning skal tilpasses appens identitetsudbyder, datamodel og regler for medlemskab; brug altid den aktuelle dokumentation for den valgte platform.

• OWASP: Forgot Password Cheat Sheet om sikre engangslinks
• OWASP: Authorization Cheat Sheet
• Firebase: login med emaillink og beskyttelse mod session injection
• Auth0: invitationer til medlemmer af en organisation
• Microsoft Entra External ID: sådan indløses en B2B-invitation