Hantering av inloggningsuppgifter i frontend: En djupdykning i API:er för lösenord och identitet

I den ständigt föränderliga världen av webbutveckling är inloggningsformuläret fortfarande en grundläggande, men ofta frustrerande, användarinteraktion. I årtionden har den enkla kombinationen av användarnamn och lösenord varit portvakten till våra digitala liv. Men detta traditionella tillvägagångssätt är fyllt av utmaningar: lösenordströtthet, säkerhetsrisker från svaga eller återanvända inloggningsuppgifter och en klumpig användarupplevelse som kan leda till höga avvisningsfrekvenser. Som utvecklare navigerar vi ständigt den känsliga balansen mellan robust säkerhet och en friktionsfri användarresa.

Lyckligtvis har webbplattformen utvecklats avsevärt. Moderna webbläsare levereras nu med en kraftfull uppsättning API:er som är utformade specifikt för att ta itu med dessa autentiseringsutmaningar. Dessa verktyg, som gemensamt faller under paraplybegreppet Credential Management (hantering av inloggningsuppgifter), gör det möjligt för oss att skapa registrerings- och inloggningsupplevelser som inte bara är säkrare utan också dramatiskt enklare för slutanvändaren. Den här artikeln är en omfattande guide för frontend-utvecklare om hur man utnyttjar dessa API:er – från det grundläggande Credential Management API till den lösenordsfria framtiden med WebAuthn och den integritetsbevarande världen av Federated Credential Management (FedCM).

Det gamla gardet: Utmaningar med traditionell formulärbaserad autentisering

Innan vi dyker in i de moderna lösningarna är det avgörande att förstå problemen de löser. Det klassiska <form> med fält för e-post och lösenord har tjänat webben i åratal, men dess begränsningar är tydligare än någonsin i en värld av ökade säkerhetshot och användarförväntningar.

• Dålig användarupplevelse (UX): Användare måste komma ihåg unika, komplexa lösenord för dussintals tjänster. Detta leder till att de glömmer sina uppgifter, vilket resulterar i frustrerande flöden för lösenordsåterställning. På mobila enheter är det ännu krångligare att skriva in komplexa lösenord.
• Säkerhetsrisker: För att hantera lösenordskomplexitet tar användare ofta till osäkra metoder som att använda enkla, lätta att gissa lösenord, återanvända samma lösenord på flera webbplatser eller skriva ner dem. Detta gör dem sårbara för credential stuffing-attacker, där angripare använder listor med stulna inloggningsuppgifter för att få obehörig åtkomst till andra tjänster.
• Sårbarheter för nätfiske (phishing): Även kunniga användare kan luras av sofistikerade nätfiskesidor som efterliknar legitima inloggningssidor för att stjäla deras uppgifter. Traditionella lösenord erbjuder lite eller inget skydd mot detta.
• Höga utvecklingskostnader: Att bygga säkra autentiseringsflöden från grunden är komplext. Utvecklare måste hantera hashning och saltning av lösenord, implementera multifaktorautentisering (MFA), hantera tokens för lösenordsåterställning och skydda sig mot olika attacker som brute-force och timing-attacker.

Dessa utmaningar belyser ett tydligt behov av ett bättre sätt – ett system där webbläsaren och operativsystemet kan agera som betrodda medlare, vilket förenklar processen för användaren samtidigt som säkerheten för applikationen stärks.

Den moderna lösningen: Credential Management API

Credential Management API är hörnstenen i modern frontend-autentisering. Det tillhandahåller ett standardiserat, programmatiskt gränssnitt för webbplatser att interagera med webbläsarens lager för inloggningsuppgifter. Detta lager kan vara webbläsarens inbyggda lösenordshanterare eller till och med ett anslutet valv på operativsystemsnivå. Istället för att enbart förlita sig på HTML-formulärs heuristik för automatisk ifyllning, tillåter detta API utvecklare att direkt begära, skapa och lagra användaruppgifter.

API:et är tillgängligt via objektet navigator.credentials i JavaScript och kretsar kring tre nyckelmetoder: get(), create() och store().

Viktiga fördelar med Credential Management API

• Inloggning med ett klick: För återkommande användare möjliggör API:et en nästan omedelbar inloggningsupplevelse. Webbläsaren kan uppmana användaren att välja ett sparat konto, och med ett enda tryck eller klick tillhandahålls uppgifterna till webbplatsen.
• Smidigare registrering: Vid registrering hjälper API:et till genom att automatiskt fylla i känd information och, efter en lyckad registrering, smidigt uppmana användaren att spara sina nya inloggningsuppgifter.
• Stöd för flera typer av inloggningsuppgifter: Detta är kanske dess mest kraftfulla funktion. API:et är utformat för att vara utbyggbart och stöder inte bara traditionella lösenord (PasswordCredential), utan även federerade identiteter (FederatedCredential) och public-key-uppgifter som används av WebAuthn (PublicKeyCredential).
• Förbättrad säkerhet: Genom att medla interaktionen hjälper webbläsaren till att minska säkerhetsrisker. Till exempel säkerställer den att inloggningsuppgifter endast är tillgängliga för den origin (domän) för vilken de sparades, vilket ger ett inbyggt skydd mot många nätfiskeattacker.

Praktisk implementering: Logga in användare med `navigator.credentials.get()`

Metoden get() används för att hämta en användares inloggningsuppgifter för inloggning. Du kan specificera vilka typer av uppgifter din applikation stöder.

Föreställ dig att en användare landar på din inloggningssida. Istället för att de behöver skriva något kan du omedelbart kontrollera om de har en sparad inloggningsuppgift.

            async function handleSignIn() {
  try {
    // Check if the API is available
    if (!navigator.credentials) {
      console.log('Credential Management API not supported.');
      // Fallback to showing the traditional form
      return;
    }

    const cred = await navigator.credentials.get({
      // We are requesting a password-based credential
      password: true,
      // You can also request other types, which we'll cover later
    });

    if (cred) {
      // A credential was selected by the user
      console.log('Credential received:', cred);
      // Now, send the credential to your server for verification
      await serverLogin(cred.id, cred.password);
    } else {
      // The user dismissed the prompt or has no saved credentials
      console.log('No credential selected.');
    }
  } catch (err) {
    console.error('Error getting credential:', err);
    // Handle errors, e.g., show the traditional form
  }
}

async function serverLogin(username, password) {
  // This is a mock function. In a real app, you would send
  // this to your backend via a POST request.
  const response = await fetch('/api/login', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ username, password }),
  });

  if (response.ok) {
    window.location.href = '/dashboard'; // Redirect on success
  } else {
    // Handle login failure
    console.error('Login failed on the server.');
  }
}

            

              
                Copy
              
            
          

I detta exempel utlöser anropet navigator.credentials.get({ password: true }) webbläsaren att visa ett native gränssnitt (ofta en kontoväljare) som listar alla sparade inloggningsuppgifter för den aktuella domänen. Om användaren väljer en, löses promise-objektet med ett PasswordCredential-objekt som innehåller id (användarnamn) och password. Din applikation kan sedan skicka denna information till servern för att slutföra autentiseringsprocessen.

Praktisk implementering: Lagra inloggningsuppgifter med `navigator.credentials.store()`

Efter att en användare har registrerat sig eller loggat in med ett traditionellt formulär (kanske som en reservlösning), bör du erbjuda att spara deras uppgifter för framtida bruk. Metoden store() gör detta smidigt.

            async function handleSuccessfulSignUp(username, password) {
  try {
    // Create a new PasswordCredential object
    const newCredential = new PasswordCredential({
      id: username,
      password: password,
      name: 'User display name' // Optional: for the account chooser
    });

    // Store the credential
    await navigator.credentials.store(newCredential);
    console.log('Credential stored successfully!');

    // Proceed to redirect the user or update the UI
    window.location.href = '/welcome';
  } catch (err) {
    console.error('Error storing credential:', err);
  }
}

            

              
                Copy
              
            
          

När denna kod körs kommer webbläsaren att visa en diskret uppmaning som frågar användaren om de vill spara lösenordet. Detta är en mycket bättre användarupplevelse än att förlita sig på webbläsarens ibland oförutsägbara heuristik för att upptäcka en lyckad inloggning och erbjuda att spara lösenordet.

Nästa gräns: Lösenordsfri autentisering med WebAuthn och Passkeys

Medan Credential Management API dramatiskt förbättrar upplevelsen kring lösenord, är det ultimata målet för många att eliminera lösenord helt och hållet. Det är här Web Authentication API (WebAuthn) kommer in. WebAuthn är en W3C-standard som möjliggör lösenordsfri, nätfiskesäker autentisering med hjälp av public-key-kryptografi.

Du kanske har hört termen Passkeys (säkerhetsnycklar) nyligen. Passkeys är den användarvänliga implementeringen av standarden bakom WebAuthn. En passkey är en digital inloggningsuppgift som lagras på en användares enhet (som en telefon, dator eller hårdvarusäkerhetsnyckel). Den används för att logga in på webbplatser och appar utan lösenord. De synkroniseras ofta över en användares enheter via molntjänster (som iCloud Keychain eller Google Password Manager), vilket gör dem otroligt bekväma.

Varför WebAuthn är en säkerhetsrevolution

• Nätfiskesäker: En passkey är kryptografiskt bunden till webbplatsens origin där den skapades. Det betyder att en passkey skapad för my-bank.com inte kan användas för att logga in på en nätfiskesida som my-bank-login.com. Webbläsaren tillåter det helt enkelt inte.
• Inga delade hemligheter: Med WebAuthn genererar användarens enhet ett par med en publik och en privat nyckel. Den privata nyckeln lämnar aldrig användarens säkra enhet (autentiseraren). Endast den publika nyckeln skickas till servern. Även om din servers databas skulle utsättas för ett intrång, kommer angripare inte att hitta några lösenord att stjäla.
• Stark multifaktorautentisering: En passkey kombinerar i sig självt vad användaren har (enheten med den privata nyckeln) och vad användaren är (deras fingeravtryck/ansikte) eller vet (deras enhets-PIN). Detta uppfyller ofta MFA-krav i ett enda, enkelt steg.

WebAuthn-flödet via Credential Management API

WebAuthn hanteras också via objektet navigator.credentials, med hjälp av typen PublicKeyCredential. Processen innefattar två huvudsteg: registrering och autentisering.

1. Registrering (Skapa en passkey)

Detta är en förenklad översikt. Den faktiska implementeringen kräver noggrann hantering av kryptografiska utmaningar på serversidan.

1. Klienten begär att få registrera sig: Användaren indikerar att de vill skapa en passkey.
2. Servern skickar en utmaning: Din server genererar en unik, slumpmässig utmaning och några konfigurationsalternativ (ett publicKeyCreationOptions-objekt).
3. Klienten anropar `navigator.credentials.create()`: Din frontend-kod skickar alternativen från servern till denna metod.

            const creationOptions = await fetch('/api/webauthn/register-options').then(r => r.json());

// Important: The server-generated challenge must be decoded from Base64URL to a BufferSource
creationOptions.challenge = bufferDecode(creationOptions.challenge);
creationOptions.user.id = bufferDecode(creationations.user.id);

const credential = await navigator.credentials.create({ publicKey: creationOptions });

            

              
                Copy
              
            
          

4. Användaren godkänner: Webbläsaren/OS uppmanar användaren att skapa en passkey med sin enhets autentiserare (t.ex. Face ID, Windows Hello eller en fingeravtrycksläsare). Autentiseraren skapar ett nytt par med en publik och en privat nyckel.
5. Klienten skickar den publika nyckeln till servern: Den resulterande inloggningsuppgiften, som inkluderar den nya publika nyckeln och en signerad attestering, skickas tillbaka till din server för verifiering och lagring.

2. Autentisering (Logga in med en passkey)

1. Klienten begär att få logga in: Användaren vill logga in med sin passkey.
2. Servern skickar en utmaning: Din server genererar en ny slumpmässig utmaning och skickar den till klienten (inuti ett publicKeyRequestOptions-objekt).
3. Klienten anropar `navigator.credentials.get()`: Den här gången använder du alternativet publicKey.

            const requestOptions = await fetch('/api/webauthn/login-options').then(r => r.json());
requestOptions.challenge = bufferDecode(requestOptions.challenge);

const credential = await navigator.credentials.get({ publicKey: requestOptions });

            

              
                Copy
              
            
          

4. Användaren godkänner: Användaren autentiserar sig med sin enhet. Enhetens autentiserare använder den lagrade privata nyckeln för att signera utmaningen från servern.
5. Klienten skickar assertionen till servern: Den signerade utmaningen (kallad en assertion) skickas tillbaka till din server. Servern verifierar signaturen med hjälp av den lagrade publika nyckeln. Om den är giltig loggas användaren in.

Notera: Råa WebAuthn API medför betydande komplexitet, särskilt kring kodning/avkodning av data (som ArrayBuffers och Base64URL). Det rekommenderas starkt att använda ett beprövat bibliotek som SimpleWebAuthn eller en tjänsteleverantör för att hantera de lågnivådetaljer på både klient- och serversidan.

Integritetsfokuserad inloggning: Federated Credential Management (FedCM)

I åratal har 'Logga in med Google/Facebook/GitHub' varit ett populärt sätt att minska friktionen vid registrering. Denna modell kallas Federerad Identitet. Historiskt sett har den i hög grad förlitat sig på mekanismer som omdirigeringar, popup-fönster och tredjepartscookies för att spåra inloggningsstatus över olika webbplatser. I takt med att webbläsare går mot att fasa ut tredjepartscookies för att förbättra användarnas integritet, riskerar dessa traditionella flöden att sluta fungera.

Federated Credential Management API (FedCM) är ett nytt förslag utformat för att fortsätta stödja användningsfall för federerad identitet på ett integritetsbevarande sätt, utan att förlita sig på tredjepartscookies.

Huvudmål med FedCM

• Bevara federerade inloggningar: Tillåta användare att fortsätta använda sina föredragna identitetsleverantörer (IdP:er) för att enkelt logga in på beroende parter (RP:er, din webbplats).
• Förbättra integriteten: Förhindra att IdP:er passivt spårar användare över webben utan deras uttryckliga samtycke.
• Förbättra användarupplevelse och säkerhet: Tillhandahålla ett webbläsarmedierat, standardiserat gränssnitt för federerade inloggningar, vilket ger användarna mer transparens och kontroll över vilken data som delas. Detta hjälper också till att förhindra nätfiskeattacker baserade på användargränssnitt.

Hur FedCM fungerar (övergripande)

Med FedCM orkestrerar webbläsaren själv inloggningsflödet och agerar som en betrodd mellanhand mellan din webbplats (RP) och identitetsleverantören (IdP).

1. RP begär en inloggningsuppgift: Din webbplats anropar navigator.credentials.get(), denna gång specificeras en federated-leverantör.

            async function handleFedCMLogin() {
  try {
    const cred = await navigator.credentials.get({
      federated: {
        providers: ['https://accounts.google.com', 'https://facebook.com'], // Example IdPs
        // The browser will look for a well-known manifest file on these domains
      }
    });

    // If successful, the credential object contains a token
    if (cred) {
      console.log('Received token:', cred.token);
      // Send the token to your server for validation and login
      await serverLoginWithToken(cred.token, cred.provider);
    }
  } catch (err) {
    console.error('FedCM Error:', err);
  }
}

            

              
                Copy
              
            
          

2. Webbläsaren hämtar manifest: Webbläsaren gör sandlåde-förfrågningar till en /.well-known/web-identity-fil på IdP:ns domän. Denna fil talar om för webbläsaren var den kan hitta de nödvändiga slutpunkterna för att hämta kontolistor och utfärda tokens.
3. Webbläsaren visar en kontoväljare: Om användaren är inloggad hos IdP:n, visar webbläsaren sitt eget native gränssnitt (t.ex. en rullgardinsmeny i skärmens övre högra hörn) som visar användarens tillgängliga konton. RP-sidans innehåll döljs aldrig.
4. Användaren ger sitt samtycke: Användaren väljer ett konto och samtycker till att logga in.
5. Webbläsaren hämtar en token: Webbläsaren gör en sista förfrågan till IdP:ns token-slutpunkt för att få en ID-token.
6. RP tar emot token: Promise-objektet från get() löses och returnerar ett FederatedCredential-objekt som innehåller token. Din webbplats skickar denna token till din backend, som måste validera den med IdP:n innan en session skapas för användaren.

FedCM är fortfarande ett relativt nytt API, och webbläsarstödet utvecklas, men det representerar den framtida riktningen för tredjepartsinloggningar på webben.

En enhetlig strategi: Progressiv förbättring för autentisering

Med tre olika typer av inloggningsuppgifter tillgängliga, hur ska du strukturera din frontend-kod? Den bästa metoden är progressiv förbättring (progressive enhancement). Du bör sträva efter att erbjuda den mest moderna och säkra upplevelsen som möjligt, samtidigt som du elegant faller tillbaka på äldre metoder när det är nödvändigt.

Credential Management API är utformat för detta. Du kan begära alla stödda typer av inloggningsuppgifter i ett enda get()-anrop, och webbläsaren kommer att prioritera och presentera det bästa alternativet för användaren.

Det rekommenderade autentiseringsflödet

1. Prioritera Passkeys (om tillgängligt): För den säkraste och smidigaste upplevelsen, kontrollera först om användaren har en passkey. Du kan använda PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable() för funktionsdetektering för att villkorligt visa en 'Logga in med Passkey'-knapp.
2. Använd ett enhetligt `get()`-anrop: Gör ett enda anrop till navigator.credentials.get() som inkluderar alternativ för publicKey, password och _potentiellt_ federated. Webbläsaren är smart med detta; den visar till exempel inte en lösenordsfråga om en passkey är tillgänglig och föredras.
3. Hantera den returnerade inloggningsuppgiften: Kontrollera typen på det returnerade uppgiftsobjektet med instanceof och bearbeta det därefter.
4. Elegant reservlösning: Om användaren avbryter dialogrutan eller om API-anropet misslyckas av någon anledning (t.ex. i en webbläsare som inte stöds), då och endast då bör du visa det fullständiga, traditionella formuläret för användarnamn/lösenord.

Exempel: Ett enhetligt `get()`-anrop

            async function unifiedSignIn() {
  try {
    // Note: These `publicKey` and `federated` options would come from your server
    const publicKeyOptions = await fetch('/api/webauthn/login-options').then(r => r.json());
    // ... (buffer decoding logic here) ...

    const cred = await navigator.credentials.get({
      password: true,
      publicKey: publicKeyOptions,
      federated: {
        providers: ['https://idp.example.com']
      },
      // 'optional' prevents an error if the user has no credentials
      mediation: 'optional' 
    });

    if (!cred) {
      console.log('User cancelled or no credentials. Showing form.');
      showTraditionalLoginForm();
      return;
    }

    // Handle the credential based on its type
    if (cred instanceof PasswordCredential) {
      console.log('Handling password credential...');
      await serverLogin(cred.id, cred.password);
    } else if (cred instanceof PublicKeyCredential) {
      console.log('Handling PublicKeyCredential (Passkey)...');
      await serverLoginWithPasskey(cred);
    } else if (cred instanceof FederatedCredential) {
      console.log('Handling FederatedCredential (FedCM)...');
      await serverLoginWithToken(cred.token, cred.provider);
    }

  } catch (err) {
    console.error('Unified sign-in error:', err);
    showTraditionalLoginForm(); // Fallback on any error
  }
}

            

              
                Copy
              
            
          

Globala överväganden och bästa praxis

När du implementerar dessa moderna autentiseringsflöden för en global publik, tänk på följande:

• Webbläsarstöd: Kontrollera alltid webbläsarkompatibilitet för varje API på webbplatser som caniuse.com. Tillhandahåll robusta reservlösningar för användare på äldre webbläsare för att säkerställa att ingen blir utelåst.
• Validering på serversidan är icke-förhandlingsbar: Frontend är en opålitlig miljö. Alla inloggningsuppgifter, tokens och assertioner som tas emot från klienten måste valideras rigoröst på servern innan en session skapas. Dessa API:er förbättrar UX i frontend; de ersätter inte säkerheten i backend.
• Användarutbildning: Koncept som passkeys är nya för många användare. Använd ett tydligt och enkelt språk. Överväg att lägga till verktygstips eller länkar till korta förklaringar (t.ex. 'Vad är en passkey?') för att vägleda användarna genom processen och bygga förtroende.
• Internationalisering (i18n): Medan de webbläsar-nativa gränssnitten vanligtvis lokaliseras av webbläsarleverantören, måste all anpassad text, felmeddelanden eller instruktioner som du lägger till översättas korrekt för dina målgrupper.
• Tillgänglighet (a11y): Om du bygger anpassade UI-element för att utlösa dessa flöden (som anpassade knappar), se till att de är fullt tillgängliga, med korrekta ARIA-attribut, fokustillstånd och stöd för tangentbordsnavigering.

Slutsats: Framtiden är här

Tiden då vi enbart förlitade oss på krångliga och osäkra lösenordsformulär närmar sig sitt slut. Som frontend-utvecklare är vi nu utrustade med en kraftfull uppsättning webbläsar-API:er som gör att vi kan bygga autentiseringsupplevelser som är samtidigt säkrare, mer privata och oerhört mycket mer användarvänliga.

Genom att anamma Credential Management API som en enhetlig ingångspunkt kan vi successivt förbättra våra applikationer. Vi kan erbjuda bekvämligheten med ett-klicks-lösenordsinloggningar, den pansarsäkra säkerheten hos WebAuthn och passkeys, och den integritetsfokuserade enkelheten hos FedCM. Resan bort från lösenord är ett maraton, inte en sprint, men verktygen för att börja bygga den framtiden är tillgängliga för oss idag. Genom att anamma dessa moderna standarder kan vi inte bara glädja våra användare utan också göra webben till en säkrare plats för alla.