A hozzáférési kulcsok alkalmazási esetei

Ez a témakör a hozzáférési kulcsok használati eseteit ismerteti.

1. használati eset: Rendszerindítás

Fiók indítása a weben.

1.1: A felhasználó hitelesítése

Ez a szakasz akkor érvényes, ha a függő entitás (RP) még nem tudja, hogy ki irányítja az ügyféleszközt. Az RP nem érhető el böngészőösszetevővel (például egy cookie-val vagy egy hitelesítő azonosítóval a helyi tárolóban), bár egyelőre feltételezzük, hogy a felhasználó rendelkezik meglévő fiókkal az RP-vel.

Egy fiók rendszerindításához egy bejelentkezési oldalt kell kiszolgálnia a felhasználónak.

Először kérje meg a felhasználótól a fiókazonosítóját; általában felhasználónév vagy e-mail-cím.

A hozzáférési kulcsok automatikus kitöltési felhasználói felületének támogatásához győződjön meg arról, hogy:

1. Adja hozzá az username és webauthn az értéket a felhasználónév beviteli mezőjében lévő meglévő automatikus kiegészítési széljegyzetekhez.

<div>
  <label for="username">Username:</label>
  <input name="username" id="loginform.username"
         autocomplete="username webauthn">
</div>

2. Az oldalbetöltéskor egy utasítással if ellenőrizze, hogy elérhető-e az automatikus kitöltési UI (feltételes közvetítés), majd hívja meg a navigator.credentials.get() a(z) mediation: "conditional" és userVerification: "preferred" paraméterekkel.

  <script>
    (async () => {
      if (
      typeof window.PublicKeyCredential !== 'undefined'
      && typeof window.PublicKeyCredential.isConditionalMediationAvailable === 'function'
      ) {
        const available = await PublicKeyCredential.isConditionalMediationAvailable();

      if (available) {
          try {
            // Retrieve authentication options for `navigator.credentials.get()`
            // from your server.
            const authOptions = await getAuthenticationOptions();
      // This call to `navigator.credentials.get()` is "set and forget."
      // The Promise will resolve only if the user successfully interacts
      // with the browser's autofill UI to select a passkey.
      const webAuthnResponse = await navigator.credentials.get({
          mediation: "conditional",
      publicKey: {
          ...authOptions,
          // See note about userVerification below.
          userVerification: "preferred",
              }
            });
      // Send the response to your server for verification, and
      // authenticate the user if the response is valid.
      await verifyAutoFillResponse(webAuthnResponse);
          } catch (err) {
          console.error('Error with conditional UI:', err);
          }
        }
      }
    })();
  </script>

A fentiek a következőket okozzák:

• Kérje le a hitelesítési beállításokat a kiszolgálóról. Adjon vissza legalább egy véletlenszerűt challenge, és társítsa ehhez a hitelesítési kérelemhez rpId-t.
• Amikor a felhasználó a felhasználónév mezővel kommunikál, a böngésző és a platform ellenőrzik, hogy létezik-e a függő entitással használható hozzáférési kulcs (a platform hitelesítőben).
• Ha ez a helyzet, akkor a hozzáférési kulcs megjelenik a felhasználónak választási lehetőségként (az automatikusan kitölthető egyéb hitelesítő adatokkal együtt, például a böngésző jelszókezelőjében tárolt felhasználónevek). A böngésző/platform az alábbihoz hasonló felhasználói felületet jeleníthet meg. Bár a pontos megjelenés és érzés az egyik platformtól vagy form factortól a másikig változik:

• Ha a felhasználó kiválasztja a jelszót, akkor a platform felhasználói felülete végigvezeti a felhasználót egy (gyakran biometrikus alapú) felhasználói ellenőrzésen.
• Ha a felhasználó sikeresen átadja a felhasználó ellenőrzését, a navigator.credentials.get() hívás sikeres lesz, és WebAuthn-választ ad vissza.
• Ha a felhasználó a hitelesítő azonosítótól eltérő hitelesítő adatot választ, akkor a böngésző/platform másik megfelelő műveletet választ (például automatikusan kitölti a felhasználónevet), és a navigator.credentials.get() hívás nem oldható fel.
• Ha a felhasználó a "Jelszó másik eszközről" lehetőséget választja (a pontos szöveg platformonként kissé eltér), akkor a böngésző/platform végigvezeti a felhasználót egy FIDO2 biztonsági kulccsal vagy az eszközközi hitelesítés (CDA) folyamattal, hogy az okostelefonról vagy táblagépről származó jelszót használva webauthn-választ adjon a navigator.credentials.get() hívásra.
• Küldje el a WebAuthn-választ a kiszolgálónak ellenőrzésre és további biztonsági ellenőrzésekre. Ha minden ellenőrzés sikeres, akkor kezdjen el hitelesített munkamenetet a felhasználó számára.

Ez az oka annak, hogy ezt a WebAuthn feltételes felhasználói felületének (vagy gyakrabban az automatikus kitöltési felhasználói felületnek) nevezzük – a platformhitelesítő felhasználói felülete, amely végigvezeti a felhasználót az ellenőrzésen vagy a telefonjukon keresztül, csak akkor jelenik meg, ha a felhasználónak van egy hozzáférési kulcsa az eszközön (vagy a "másik eszköz" lehetőséget választja).

Mint látható, ebben a módban a navigator.credentials.get() hívás vagy sikeres, vagy sikertelen marad, mert soha nem kerül megoldásra. Ha sikerül, akkor a hívás eredménye egy felhasználói azonosítót és egy aláírt WebAuthn-állítást is felfed, amelyet a függő entitás (RP) használ a felhasználó hitelesítéséhez.

Ha a hívás nem sikerül, akkor egy örökölt felhasználói hitelesítést kell végrehajtania. Erről az első oldalról szerez be egy felhasználónevet, majd a következő oldalakon a megfelelő további bejelentkezési kihívásokat (például jelszavakat, SMS-kihívásokra való válaszadást stb.) fogja kiszolgálni a felhasználónak. Ezek közé tartozhatnak a fiók-helyreállítási lépések abban az esetben, ha a felhasználó elfelejtette a jelszavát, vagy egyébként nem tudja teljesíteni a rendszeres bejelentkezési kihívásokat. Miután a felhasználó teljesítette az összes bejelentkezési kihívást, hitelesítettnek minősül, és bejelentkezettnek minősül.

Ha a felhasználó még nem rendelkezik fiókkal a függő entitással (RP), általában lehetőséget ad a felhasználónak a bejelentkezési oldalon egy fiók létrehozására. Ha a felhasználó ezt a lehetőséget választja, ön összegyűjti a szükséges adatokat egy új fiók megnyitásához. Ha sikeresen megnyitnak egy új fiókot, akkor hitelesítettnek és bejelentkezettnek is minősülnek.

Miután a felhasználó bejelentkezett, előfordulhat, hogy ideje új jelszót beállítani számukra. Tegye ezt a következő esetekben:

• A felhasználó beállította a fiókját az eszközön úgy, hogy nem passkey-alapú bejelentkezési kihívásokat teljesített (például jelszó használatával).
• A felhasználó most hozott létre egy új fiókot a függő entitásnál (RP), és emiatt úgy tekintjük, hogy be van jelentkezve.
• A felhasználó egy hozzáférési kulcsot használt, de a jelenleg használttól eltérő eszközt használt (a fenti példában látható "másik eszköz" kiválasztásával). Ezt a authenticatorAttachment attribútum vizsgálatával lehet megerősíteni a visszaadott PublicKeyCredential objektumban.

1.2: Eszközközi hitelesítés

Ha a felhasználó egy másik eszközről (például telefonról, táblagépről vagy FIDO2 biztonsági kulcsról) használt jelszót, akkor a hitelesítési válaszban (getAssertion) szereplő AuthenticatorAttachment tulajdonság értéke lesz.cross-platform

Ebben a forgatókönyvben adja meg a felhasználónak, hogy hozzon létre egy hozzáférési kulcsot a helyi eszközén. Ez a jövőben zökkenőmentesebb felhasználói élményt eredményez, mivel a felhasználónak nem kell használnia a másik eszközét.

1.3: Megjegyzés a felhasználói ellenőrzésről

Ez az útmutató a userVerificationpreferredbeállítást állítja be, ami azt jelenti, hogy a felhasználó-ellenőrzést lehetőség szerint megkísérlik.

Egyes eszközök, például az asztali számítógépek és a régebbi laptopok nem rendelkeznek biometrikus érzékelőkkel. Ezeken az eszközökön, ha a userVerification értéke be van állítva required, előfordulhat, hogy a felhasználónak meg kell adnia a rendszer bejelentkezési jelszavát minden bejelentkezéshez egy jelszókulcs használatával. És ez frusztráló lehet számukra.

Ha preferred használatban van, egyes platformhitelesítők mindig felhasználói ellenőrzést igényelnek, ha az eszköz biometrikus érzékelőkkel rendelkezik, de a nélkülük lévő eszközökön kihagyhatja a felhasználói ellenőrzést.

A felhasználó-ellenőrzési eredmény (a hitelesítő adatjelölőkben kifejezve) a tényleges felhasználói ellenőrzési eredményt tükrözi, és mindig érvényesíteni kell a kiszolgálóra vonatkozó követelményeknek megfelelően.

1.4: Vonja be a felhasználót a passkey használatába

Először ellenőrizze, hogy a felhasználó megfelelően hitelesítve van-e más bejelentkezési módszerekkel, beleértve a többtényezős hitelesítést is.

Másodszor győződjön meg arról, hogy a felhasználó eszköz- és operációsrendszer-kombinált rendszere támogatja a hozzáférési kulcsokat a következő hívással:

PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable()

Ha a hozzáférési kulcsok támogatottak, akkor az vissza fog térni true. Ha nem támogatottak, akkor az vissza fog térni false, és le kell szakítania a jelszókulcs-regisztrációs folyamatot.

Biztosítson egy beleegyezést kérő vagy "upsell" modális ablakot, közbenső oldalt vagy oldalt a felhasználónak, amely lehetőséget nyújt számukra a jelszó létrehozására.

Jótanács

Annak biztosítása érdekében, hogy a felhasználó teljes körűen tájékozott hozzájárulást adjon, fontolja meg hosszabb leírások megjelenítését (vagy csatolását) annak magyarázatára, hogy az aktuális eszköz zárolásának feloldására jogosult felhasználók hozzáférhetnek a fiókhoz a függő entitásnál (RP).

Ha a felhasználó beleegyezik, akkor hívja meg a navigator.credentials.create()-t az alábbi példában bemutatott lehetőségekkel.

navigator.credentials.create({
  publicKey: {
    rp: {
      // User-friendly name of your service.
      name: "Passkeys Developer",
      // Relying party (RP) identifier (hostname/FQDN).
      id: passkeys.contoso"
    },

    user: {
      // Persistent, unique identifier for the user account in your backend.
      id: Uint8Array.from("0525bc79-5a63-4e47-b7d1-597e25f5caba", c => c.charCodeAt(0)),
      // User-friendly identifier often displayed to the user (for example, email address).
      name: "amanda@contoso.com",
      // Human-readable display name, sometimes displayed by the client.
      displayName: "Amanda Brady"
    },
    // The challenge is a buffer of cryptographically random bytes generated on your backend,
    // and should be tightly bound to the current user session.
    challenge: Uint8Array.from("XZJscsUqtBH7ZB90t2g0EbZTZYlbSRK6lq7zlN2lJKuoYMnp7Qo2OLzD7xawL3s", c => c.charCodeAt(0)),
    pubKeyCredParams: [
      // An array of objects describing what public key types are acceptable to a server.
      {
        "type": "public-key",
        "alg": -7 // EC P256
      },
      {
        "type": "public-key",
        "alg": -257 // RSA
      }
    ],
    excludeCredentials: [
      // Array of credential IDs for existing passkeys tied to the user account.
      // This avoids creating a new passkey in an authenticator that already has 
      // a passkey tied to the user account.
      {
        // Example only.
        type: "public-key",
        id: new Uint8Array([21, 31, 56, ...]).buffer
      },
      {
        // Example only.
        type: "public-key",
        id: new Uint8Array([21, 31, 56, ...]).buffer
      }
    ],
    authenticatorSelection: {
      // Tells the authenticator to create a passkey.
      residentKey: "required",
      // Tells the client/authenticator to request user verification where possible;
      // for example, a biometric or a device PIN.
      userVerification: "preferred"
    },
    "extensions": {
      // Returns details about the passkey.
      "credProps": true
    }
  }
})

Megjegyzés:

Azt javasoljuk, hogy a legtöbb megbízó fél (RP) ne adja meg az igazolás továbbításának paraméterét attestation (ezért az alapértelmezett érték "nincs"), vagy explicit módon használja az indirect értéket. Ez biztosítja a leggördülékenyebb felhasználói élményt (a platformok valószínűleg más típusú igazolási közvetítésekhez kapnak hozzájárulást a felhasználótól, ami valószínűleg a sikertelen hitelesítő adatok létrehozásának nagyobb részét eredményezi, mivel a felhasználók megszakítják a létrehozást).

A WebAuthn-hívás feloldásakor küldje el a választ a kiszolgálónak, és társítsa a visszaadott nyilvános kulcsot és hitelesítő azonosítót a korábban hitelesített felhasználói fiókkal.

2. használati eset: Újrahitelesítés

A jelszókulcsok újbóli hitelesítéshez való használata az alábbi okok bármelyike miatt szükséges lehet:

• A felhasználó kijelentkezett, és most újra be szeretne jelentkezni.
• A felhasználói munkamenet inaktivitás miatt lejárt, és a felhasználó újra be szeretne jelentkezni.
• A felhasználó egy bizalmas műveletet fog végrehajtani, és újra meg kell erősítenie a felhasználói munkamenet feletti ellenőrzést.

A felhasználó újrahitelesítéséhez minden ilyen helyzetben az előző használati esetben beállított belépési kulcsokat fogod használni. A WebAuthn API-hívás mindhárom esetben ugyanaz, de a megadott felhasználói felületi kezelés kissé eltérő. Mivel az adott fiókot Ön adta meg, a platform nem fogja kérni a felhasználót, hogy válasszon egy másik fiókot a szolgáltatásban.

2.1: Bizalmas műveletek

Először a harmadik okból tekintsük át a felhasználói felületet – amikor egy bizalmas művelet újrahitelesítésére van szükség, ellenőrizze, hogy rendelkezik-e hitelesítő azonosítóval legalább egy hozzáférési kulcshoz a felhasználó számára.

Ha nem áll rendelkezésre ilyen hitelesítő azonosító, akkor szolgáljon ki egy hagyományos bejelentkezési feladatot, amely alkalmas az újrahitelesítésre, például:

Jótanács

Javasoljuk, hogy ezen a bejelentkezési feladatlapon a felhasználók ne módosíthassák a fiókazonosítójukat. Emellett a bejelentkezési feladatnak olyannak kell lennie, amelyet az eszköz jogosulatlan felhasználója nem tud átadni.

Ha viszont legalább egy hozzáférési kulcs hitelesítő azonosítót talál a felhasználó számára, akkor újrahitelesítéshez használhatja a hozzáférési kulcsokat.

Ha a felhasználó készen áll (a fenti példában, amikor a "Go" gombra kattint), hívja navigator.credentials.get()meg, és adja át a felhasználó hitelesítő adatainak összes azonosítóját:

navigator.credentials.get({
  publicKey: {
    challenge: ...,
    rpId: ...,
     allowCredentials: [{
      type: "public-key",      
      id: new UInt8Array([21, 31, 56, ...]).buffer,
    }, {
      type: "public-key",
      id: new UInt8Array([21, 31, 56, ...]).buffer,
    }, {
      ...
    }],
    // see note below
    userVerification: "preferred", 
  }
});

Megjegyzés:

Mindenképpen olvassa el a userVerificationre vonatkozó útmutatást az előző használati esetből.

Ha a felhasználó ehelyett a "Próbálkozzon más módon" gombra kattint, akkor ajánlott más bejelentkezési módszereket (jelszót stb.) felajánlani az újbóli hitelesítéshez (feltéve, hogy a felhasználó rendelkezik ilyen egyéb bejelentkezési módszerekkel).

2.2: Lejárt munkamenetek és kijelentkezés

Most megvizsgáljuk azt az esetet, amikor az újrahitelesítés azért aktiválódik, mert a felhasználó kijelentkezett, vagy a megbízó fél (RP) lejáratta a felhasználó munkamenetét. Ennek megkönnyítése érdekében az RP-nek meg kell őriznie a felhasználói munkamenet valamilyen állapotát, emlékeztetve őket a korábban bejelentkezett fiókra, még akkor is, ha figyelembe veszik a felhasználó kijelentkezését (ez böngészőösszetevők, például cookie-k vagy helyi tárolók használatával érhető el).

Megjegyzés:

A függő entitások (RP) dönthetnek úgy, hogy átfogó műveletként kezelik a kijelentkezést, és így törlik a felhasználó identitására mutató összes hivatkozást. Az ilyen RP-nek a fiók rendszerindításához hasonlóan kell kezelnie a későbbi bejelentkezést, és meg kell ismételnie a korábban ismertetett lépéseket.

Ön, mint RP, a következőhöz hasonló bejelentkezési oldalt szolgálhat ki:

Ha a felhasználó a "Másik fiók használata" elemre kattint, akkor meg kell adnia egy fiók rendszerindítási folyamatát – az előző használati esethez hasonlóan – megismételve az ott leírt lépéseket, ahol a platform lehetővé teszi a felhasználó számára, hogy kiválassza a használni kívánt fiókot.

Megjegyzés:

Ebben az esetben azt is lehetővé kell tenni a felhasználó számára, hogy teljesen eltávolítsa a javasolt fiókot a bejelentkezési oldalon való listából.

Ha azonban a felhasználó a "Bejelentkezés másként" gombra kattint, ellenőrizze, hogy rendelkezik-e legalább egy, a felhasználóhoz társított hitelesítőadat-azonosítóval. Ha nem áll rendelkezésre hitelesítőadat-azonosító, akkor egy olyan hagyományos bejelentkezési feladatot kell kiszolgálni, amely alkalmas az újrahitelesítésre, például:

Ha viszont legalább egy hozzáférési kulcs hitelesítő azonosítót talál a felhasználó számára, akkor újrahitelesítéshez használhatja a hozzáférési kulcsokat.

Ha a felhasználó készen áll (a fenti példában, amikor az "Ugrás" gombra kattint), hívja meg navigator.credentials.get()a már látható módon (azaz a felhasználó hitelesítő adatainak átadásával).

Ha a felhasználó ehelyett a "Próbálkozzon más módon" gombra kattint, akkor ajánlott más bejelentkezési módszereket (jelszót stb.) felajánlani az újbóli hitelesítéshez (feltéve, hogy a felhasználó rendelkezik ilyen egyéb bejelentkezési módszerekkel).

Következő lépések

Következő lépésként tekintse meg az Eszközök és kódtárak a hozzáférési kulcsokhoz című témakört.

További információk

• Bevezetés a jelszavakhoz
• Passkeys.dev
• Ismerkedés a jelszó nélküli utazásával a FIDO Alliance webhelyén