Mikrofrontend-arkitektur med Module Federation · leksjon

Autentisering og autorisasjon

Implementer robuste mekanismer for autentisering og autorisasjon på tvers av ulike Micro Frontends.

Leksjon 1 av 411 trinn

Autentisering og autorisasjon er en gratis leksjon i Mikrofrontend-arkitektur med Module Federation på CoddyKit. Dette er leksjon 1 av 4. Du kan lese hele leksjonen gratis nedenfor – og deretter øve praktisk i nettleseren med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Mikrofrontend-arkitektur med Module Federation, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Mikrofrontend-arkitektur med Module Federation inneholder totalt 4 leksjoner.

Autentisering og autorisasjon i MFE-er

Velkommen til autentisering og autorisasjon i Micro Frontends! Sikring av fødererte applikasjoner byr på unike utfordringer sammenlignet med monolittiske applikasjoner.

Vi trenger robuste metoder for å bekrefte brukeridentiteter (autentisering) og kontrollere hva brukerne kan få tilgang til (autorisasjon) på tvers av uavhengig utviklede og distribuerte Micro Frontends.

Behovet for sentralisert autentisering

I en Micro Frontend-arkitektur samhandler brukerne med flere separate applikasjoner. Hvis hver MFE håndterte autentisering uavhengig, ville brukerne bli møtt med flere innloggingsforespørsler.

Dette gir en dårlig brukeropplevelse og kompleks øktstyring. En sentralisert autentiseringsmekanisme er avgjørende for sømløs navigasjon.

Identitetsleverandører (IdP)

En vanlig løsning er å bruke en Identity Provider (IdP). Dette er en tjeneste som oppretter, vedlikeholder og administrerer identitetsinformasjon for brukere og autentiserer dem.

  • Eksempler: Auth0, Okta, Keycloak eller en egendefinert OAuth 2.0/OpenID Connect-server.
  • IdP-en håndterer innloggingsprosessen og utsteder sikkerhetstokener (for eksempel JWT-er) etter vellykket autentisering.

Oversikt over autentiseringsflyten

Her er en forenklet flyt for sentralisert autentisering:

  1. Brukeren forsøker å få tilgang til en MFE.
  2. Hvis brukeren ikke er autentisert, omdirigeres vedkommende til den sentrale IdP-ens innloggingsside.
  3. Brukeren logger inn hos IdP-en.
  4. IdP-en omdirigerer brukeren tilbake til MFE-en med et sikkerhetstoken.
  5. MFE-en lagrer dette tokenet (for eksempel i en HTTP-only-cookie eller lokal lagring).

Alle påfølgende forespørsler fra enhver MFE bruker dette tokenet.

Deling av autentiseringstilstand

Når en bruker er autentisert, må økten eller tokenet være tilgjengelig for alle Micro Frontends. Vanlige strategier for deling av tilstand:

  • HTTP-only-cookies: Sikre og sendes automatisk med forespørsler.
  • Web Storage (localStorage/sessionStorage): Tilgjengelig på tvers av domener med samme opphav.
  • Delte biblioteker/kontekst: Et delt verktøy som kapsler inn tokenhåndtering, ofte eksponert via Module Federation.

Hver metode har avveininger når det gjelder sikkerhet og hvor enkelt den er å implementere.

Autorisasjon forklart

Mens autentisering bekrefter hvem De er, avgjør autorisasjon hva De kan gjøre.

  • Etter autentisering inneholder sikkerhetstokenet ofte brukerroller eller tillatelser.
  • Hver Micro Frontend er deretter ansvarlig for å kontrollere disse tillatelsene før tilgang til bestemte funksjoner eller data gis.

Rollebasert tilgangskontroll (RBAC)

Rollebasert tilgangskontroll (RBAC) er en populær autorisasjonsstrategi. Brukere tildeles roller (for eksempel «admin», «editor» eller «viewer»), og hver rolle har bestemte tillatelser.

Micro Frontends kontrollerer ganske enkelt brukerens roller mot rollene som kreves for en bestemt handling eller komponent.

Implementering av autentiseringskontroller

Hver Micro Frontend eller backend-API-et deres kan implementere autorisasjonssjekker. Dette innebærer ofte å:

  • Dekode sikkerhetstokenet for å hente ut brukerroller/-tillatelser.
  • Sammenligne disse med tillatelsene som kreves for en bestemt handling eller et bestemt UI-element.

Her er et enkelt JavaScript-eksempel:

function hasPermission(userRoles, requiredRole) {
  if (!userRoles || !requiredRole) return false;
  return userRoles.includes(requiredRole);
}

// Imagine user roles are parsed from a JWT
const currentUserRoles = ["user", "editor"]; 

// Check if user can 'edit_post'
const canEdit = hasPermission(currentUserRoles, "editor");

// Check if user can 'delete_user'
const canDelete = hasPermission(currentUserRoles, "admin");

console.log("Can edit post?", canEdit);
console.log("Can delete user?", canDelete);

Beste praksis for sikkerhet

Det krever årvåkenhet å sikre de fødererte applikasjonene deres:

  • HTTPS: Bruk alltid HTTPS for all kommunikasjon.
  • Lagring av token: Lagre sensitive token på en sikker måte (for eksempel i HTTP-only-cookies i stedet for localStorage).
  • CORS: Konfigurer retningslinjene for Cross-Origin Resource Sharing riktig.
  • Validering av inndata: Valider alltid brukerens inndata på både klient- og serversiden.
  • Regelmessige revisjoner: Gjennomfør sikkerhetsrevisjoner og hold avhengighetene oppdatert.

Sorter autentiseringsflyten

Dra og slipp trinnene for å sette brukerens første autentiseringsflyt i riktig rekkefølge i en føderert applikasjon som bruker en Identity Provider (IdP).

Oppsummering: Sikre MFE-er

Vi har gått gjennom det grunnleggende innen autentisering og autorisasjon i Micro Frontends. Viktige punkter:

  • Sentralisert autentisering via en Identity Provider gir en sømløs brukeropplevelse.
  • Sikkerhetstoken (for eksempel JWT-er) inneholder data om autentisering og autorisasjon.
  • Strategier som HTTP-only-cookies eller delte biblioteker gjør det mulig å dele autentiseringstilstand.
  • Autorisasjon (for eksempel RBAC) bestemmer hva brukere kan gjøre, basert på rollene/tillatelsene i tokenet deres.
  • Følg alltid beste praksis for sikkerhet, som HTTPS og sikker lagring av token.

Deretter skal vi se nærmere på sikkerhetsrisikoer på tvers av applikasjoner!

Gratis å komme i gang

Lær deg JavaScript med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs
12
Leksjoner
48

Ofte stilte spørsmål

Er leksjonen «Autentisering og autorisasjon» gratis?

Ja – hele teksten i «Autentisering og autorisasjon» er gratis å lese her på nettet. For å øve interaktivt med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt, og for å låse opp resten av Mikrofrontend-arkitektur med Module Federation-kurset, kan du oppgradere til CoddyKit PRO. Kurset i Mikrofrontend-arkitektur med Module Federation inneholder totalt 4 leksjoner.

Hva lærer jeg i «Autentisering og autorisasjon»?

Implementer robuste mekanismer for autentisering og autorisasjon på tvers av ulike Micro Frontends. Du øver på Mikrofrontend-arkitektur med Module Federation med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med Mikrofrontend-arkitektur med Module Federation?

Ingen tidligere erfaring er nødvendig. Mikrofrontend-arkitektur med Module Federation på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 1 av 4.

Hvor lang tid tar leksjonen «Autentisering og autorisasjon»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

Kan jeg skrive og kjøre kode i denne Mikrofrontend-arkitektur med Module Federation-leksjonen?

Ja. Alle Mikrofrontend-arkitektur med Module Federation-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

  1. Autentisering og autorisasjon
  2. Sikkerhetsrisikoer på tvers av applikasjoner
  3. Beste praksis for sikker føderering
  4. Sikring av Module Federation-remotes
← Tilbake til Mikrofrontend-arkitektur med Module Federation