Microsoft SSO: opret en app registration i kundens tenant

Hvad opretter I egentlig?

En app registration beskriver, hvilken app Microsoft må logge brugeren ind i, hvem der må bruge den, og hvilke URL'er Microsoft må sende brugeren tilbage til. Registreringen opretter også en enterprise application — appens lokale service principal i tenant'en.

Før I åbner Entra-portalen

De vigtigste valg bør være aftalt, før registreringen oprettes. Ellers ender produktion, localhost og kundeadgang let i én uklar opsætning.

• Hvem ejer registreringen? For en intern kundeapp bør den normalt ligge i kundens tenant med mindst to navngivne ejere.
• Hvem må logge ind? Kun kundens tenant, udvalgte gæster eller brugere fra mange virksomheder?
• Hvilken app-type? En browserbaseret React/Vue-app er typisk en SPA; en server-renderet app er en Web application.
• Hvilke miljøer? Udvikling og produktion bør have separate app registrations og redirect URI'er.
• Behøver appen Microsoft Graph? Almindeligt login kræver ikke adgang til brugerens mail, filer eller kalender.

Single-tenant eller multi-tenant?

Valget under Supported account types afgør, hvilke Microsoft-konti der kan logge ind.

Single-tenant

Kun brugere og gæster i den tenant, hvor appen er registreret. Det er normalt det sikreste og enkleste valg til et internt værktøj for én virksomhed.

Multi-tenant

Arbejdskonti fra andre Microsoft Entra-tenants kan logge ind. Det passer til en SaaS-løsning for flere virksomheder, men kræver consent, tenant-onboarding og korrekt validering af issuer og tenant-ID i backend.

1. Opret app registration

1. 1. Log ind på Microsoft Entra admin center med mindst rollen Application Developer.
2. 2. Kontrollér tenantnavnet øverst, især hvis kontoen har adgang til flere virksomheder.
3. 3. Gå til Entra ID → App registrations → New registration.
4. 4. Giv registreringen et tydeligt navn med app og miljø, fx Ordreportal – Produktion.
5. 5. Vælg normalt Accounts in this organizational directory only til en intern app.
6. 6. Vælg Register.

Gem Application (client) ID og Directory (tenant) ID. De identificerer registreringen og tenant'en og bruges i appens konfiguration. De er ikke adgangskoder.

2. Vælg platform og redirect URI

Gå til Authentication → Add a platform. Platformstypen er et sikkerhedsvalg, ikke bare en beskrivelse.

• Single-page application: Vælg denne til React, Vue eller anden JavaScript-app, hvor login håndteres i browseren.
• Web: Vælg denne til en fortrolig serverapp, hvor backend håndterer authorization code og credentials.
• Produktions-URI: Brug den præcise HTTPS-adresse, fx https://app.example.dk/auth/callback.
• Lokal udvikling: Tilføj den præcise localhost-adresse separat, fx http://localhost:5173/auth/callback.

Redirect URI'en i koden skal matche en registreret værdi. Brug ikke brede wildcard-domæner, og efterlad ikke gamle preview- eller localhost-adresser i produktionsregistreringen.

3. Giv kun de nødvendige API-rettigheder

Login og API-adgang er to forskellige behov. En app, der kun skal kende den indloggede bruger, bør ikke bede om adgang til mail, filer, grupper eller hele virksomhedens directory.

• Start med OpenID Connect-scopes som openid, profile og eventuelt email.
• Tilføj kun Microsoft Graph-permissions, når et konkret brugerflow kræver dem.
• Vælg delegated permissions, når appen arbejder på vegne af en indlogget bruger.
• Brug application permissions med stor forsigtighed; de kan give adgang uden en bruger og kræver typisk admin consent.
• Dokumentér hvorfor hver tilladelse findes, og fjern den igen, hvis funktionen udgår.

4. Forbind en React-app med MSAL

Microsoft anbefaler et understøttet bibliotek frem for at bygge OAuth-flowet selv. Til en React-SPA bruges normalt@azure/msal-browsersammen med @azure/msal-react.

import { PublicClientApplication } from "@azure/msal-browser";

const msalConfig = {
  auth: {
    clientId: ({}).VITE_ENTRA_CLIENT_ID,
    authority:
      `https://login.microsoftonline.com/${({}).VITE_ENTRA_TENANT_ID}`,
    redirectUri: `${window.location.origin}/auth/callback`,
    postLogoutRedirectUri: window.location.origin,
  },
  cache: {
    cacheLocation: "sessionStorage",
  },
};

export const msalInstance = new PublicClientApplication(msalConfig);

const loginRequest = {
  scopes: ["openid", "profile", "email"],
};

await msalInstance.loginRedirect(loginRequest);

En SPA skal bruge authorization code flow med PKCE. Client ID og tenant ID må gerne være synlige i browseren. Et client secret må aldrig findes i en SPA, frontendkode eller en variabel, der bundtes med VITE_.

5. Beskyt backend og data

En skjult React-route er ikke adgangskontrol. Hvis appen kalder en backend eller database, skal serveren validere tokenet og derefter kontrollere, hvad brugeren må.

• Backend validerer signatur, issuer, audience og tokenets levetid med et anerkendt Microsoft-kompatibelt bibliotek.
• En single-tenant app accepterer kun tokens fra den aftalte tenant.
• En multi-tenant app validerer hver tenant og kobler tid til den korrekte kundekonto.
• ID-token bruges til at identificere brugeren i klienten; et access token med korrekt audience bruges til et beskyttet API.
• Roller, medlemskab og rettigheder håndhæves på serveren — ikke ud fra tekst gemt i browseren.

6. Begræns hvem der kan bruge appen

Single-tenant betyder ikke nødvendigvis, at alle medarbejdere skal have adgang. Under Enterprise applications kan en administrator kræve tildeling og tildele konkrete brugere eller grupper.

Gruppebaseret tildeling kan afhænge af virksomhedens Entra-licens. Uanset model bør processen for oprettelse, rolleændring og fratrædelse være dokumenteret, og appens egen backend skal stadig håndhæve funktionelle rettigheder.

Secrets, certifikater og managed identity

En ren browser-SPA har ikke et client secret. En fortrolig serverapp eller integration kan have brug for en credential, men Microsoft anbefaler stærkere alternativer end langlivede secrets.

1. 1. Managed identity: Foretrækkes, når backend kører i Azure og scenariet understøttes.
2. 2. Federated credential: Kan bruges fra en betroet ekstern identitetsplatform uden gemt secret.
3. 3. Certifikat: Foretrækkes frem for et client secret, når managed identity ikke passer.
4. 4. Client secret: Sidste udvej; gemmes server-side i en secret store med ejer, udløb og rotationsplan.

Typiske fejl

• Forkert tenant: Appen registreres i udviklerens egen tenant i stedet for kundens.
• Multi-tenant uden behov: Loginfladen åbnes for flere organisationer, selv om appen kun er intern.
• Web vælges til en SPA: Redirecttypen passer ikke til browserflowet og PKCE.
• Client secret i frontend: Hemmeligheden kan hentes af alle, der åbner appen.
• For brede Graph-permissions: Appen beder om mail-, fil- eller directoryadgang, den ikke bruger.
• Tokenet dekodes, men valideres ikke: Backend kontrollerer ikke signatur, issuer og audience.
• Kun én ejer: Appen bliver vanskelig at vedligeholde, når personen skifter rolle eller forlader virksomheden.

Tjekliste før medarbejderne får adgang

• □ App registration ligger i den aftalte tenant og har mindst to relevante ejere.
• □ Single-tenant eller multi-tenant er valgt ud fra et dokumenteret behov.
• □ Udvikling og produktion har separate registreringer og præcise redirect URI'er.
• □ SPA eller Web-platform matcher appens faktiske arkitektur.
• □ Appen anmoder kun om de scopes og API-permissions, den bruger.
• □ Ingen client secrets findes i frontend, GitHub eller buildoutput.
• □ Backend validerer tokens og håndhæver tenant, roller og dataadgang.
• □ Login, logout, udløbet session, afvist bruger og forkert tenant er testet.
• □ Ejerskab, credential-udløb og adgangsreview har en ansvarlig person.

Relaterede guides

Microsoft SSO kan bruges med mange forskellige stacks. Vælg kun de øvrige guides, der passer til projektets backend, database og deployment.