Innlogging

Dette kan du bygge

Innlogging med metodene biblioteksystemet tilbyr: identifikator og passord eller PIN-kode, identifikator alene, eller single sign-on gjennom en identitetsleverandør. Konfigurasjonen forteller klienten hvilke metoder og identifikatortyper den skal tilby, så innloggingsskjermen passer til biblioteket.

Typisk flyt

1. Med passord eller PIN-kode sender klienten identifikator og kode til AuthenticatePatron.
2. Uten kode sender klienten identifikatoren alene til AuthenticatePatronNoPassword.
3. Med single sign-on henter klienten innloggings-URL-en med GetPatronAuthenticationUrl, og låneren logger inn hos identitetsleverandøren.
4. Provideren returnerer code og state til CallbackPatron, og klienten veksler koden med AuthenticatePatronByCodeAndCodeVerifier.
5. Alle metodene svarer med låneren, inkludert patronId som de andre kallene om låneren bruker.

Dette leverer API-et

• patron.login i GetConfiguration angir hvilke identifierTypes, credentials og identityProviders provideren tar imot.
• patron.login.credentials forteller om låneren logger inn med password eller pin. Feltet i forespørselen heter password i begge tilfeller.
• AuthenticatePatronNoPassword er bare tilgjengelig når patron.login.allowWithoutCredential er true. Spesifikasjonen sier at den bare bør brukes når det er absolutt nødvendig.
• Single sign-on bruker PKCE: klienten sender en code_challenge og en state, og senere den tilhørende code_verifier.
• Finnes ikke låneren, men kan registreres, har callbacken can_be_registered=true, og klienten fortsetter med registrering (2.2.3).
• En mislykket single sign-on returnerer error på callbacken, for eksempel sso_login_cancelled eller provider_patron_not_found. Ved sso_access_denied og sso_consent_denied bør låneren henvises til biblioteket sitt.

Dette kan du bygge

Lånerne blir lånere uten å måtte innom biblioteket: med en identifikator eller gjennom en identitetsleverandør. De velger hvor reservasjoner skal hentes, og godtar bibliotekets samtykker som en del av registreringen.

Typisk flyt

1. Med en identifikator sjekker klienten med IsPatronRegistrationPossible at låneren kan registreres.
2. Låneren velger et hentested og godtar samtykkene. Klienten registrerer låneren med RegisterPatronByIdentifier.
3. Med single sign-on går låneren gjennom identitetsleverandøren fra GetRegisterPatronUrl. Callbacken CallbackPatron har can_be_registered og samtykkene som skal godtas.
4. Er can_be_registered true, samler klienten inn hentested og samtykker og registrerer låneren med RegisterPatronByCodeAndCodeVerifier. Ellers har provideren allerede registrert låneren, og klienten logger inn (2.2.1).
5. Svaret forteller i status hvor langt registreringen har kommet.

Dette leverer API-et

• patron.registration i GetConfiguration angir identifikatortypene og identitetsleverandørene som kan brukes til registrering.
• status er done, in_progress eller contact_the_library. Er status done, bør patronId være satt; ellers logger låneren inn igjen.
• pickupLocation er påkrevd på begge registreringskallene.
• Klienten skal sørge for at låneren har godtatt hvert samtykke i consents før forespørselen sendes.
• Samtykker fra callbacken har formen type:version, URL Base64-kodet, og alle skal med i registreringen.

Dette kan du bygge

Nyttig for en husstand som deler en enhet: hver låner logger inn én gang, og klienten bytter mellom dem uten å logge ut og inn igjen.

Typisk flyt

1. Hver låner logger inn for seg (2.2.1).
2. Klienten tar vare på patronId for hver låner som er logget inn på enheten.
3. Når låneren bytter bruker, bruker klienten den valgte lånerens patronId i kallene som følger.

Dette leverer API-et

• Spesifikasjonen har ingen egen operasjon for flere brukere. Bytte av bruker skjer i klienten.
• Å fjerne en låner fra enheten skjer i klienten og endrer ikke lånerens konto hos biblioteket.

Dette kan du bygge

Lånerne kommer selv inn på kontoen sin igjen fra innloggingsskjermen, uten å måtte kontakte biblioteket.

Typisk flyt

1. Låneren skriver inn identifikatoren sin og e-postadressen biblioteket har registrert.
2. Klienten kaller ResetPatronCredential.
3. Provideren sender en tilbakestillingslenke til adressen, og låneren velger en ny kode gjennom den.
4. Låneren logger inn med den nye koden (2.2.1).

Dette leverer API-et

• Tilby bare funksjonen når patron.credentials.resettable i GetConfiguration angir en kode. Mangler credentials, tilbys verken tilbakestilling eller endring.
• credential velger password eller pin. Mangler feltet, bestemmer provideren hvilken som tilbakestilles.
• Identifikatoren følger patron.login.identifierTypes. email er påkrevd og velger bare blant lånerens adresser: lenken sendes bare hvis adressen er knyttet til låneren og bekreftet.
• En gyldig forespørsel får alltid 202, uansett om det sendes en lenke, så kallet avslører aldri om en låner finnes.
• Lenken er providerens. Tokenet i den skal bare kunne brukes én gang og utløpe etter kort tid, og forespørselen inneholder ingen URL.