Siirry sisältöön

Miten se toimii

tunnuspalvelu toteuttaa OpenID Connectin Authorization Code -flowin PKCE-laajennuksella. Alla kuvaus siitä, mitä tapahtuu, kun käyttäjä kirjautuu sovellukseesi tunnuspalvelun kautta.

Sovellus tunnuspalvelu (tenant) Käyttäjä
| | |
| 1. GET /authorize?... -----------> | |
| | 2. tunnistaa tenantin |
| | Host-headerista, tarkistaa |
| | clientin, redirect_uri:n, |
| | scopet ja PKCE:n |
| | 3. ei voimassaolevaa sessiota |
| | -> näyttää kirjautumissivun |
| | ---------------------------> |
| | 4. tunnistautuu |
| | (magic link / passkey |
| | / Google) |
| | <--------------------------- |
| | 5. tarvittaessa consent-sivu |
| | (ei first-party clientille) |
| | 6. luo kertakäyttöisen coden |
| <--- redirect + code -------------- | |
| 7. POST /token (code + verifier) -> | |
| <--- access token + ID token ------ | |
| 8. GET /userinfo (valinnainen) ---> | |
| <--- käyttäjätiedot --------------- | |
  1. Sovelluksesi ohjaa käyttäjän tenantin /authorize-endpointiin mukana client_id, redirect_uri, scope, code_challenge (PKCE) ja muut OIDC-parametrit.
  2. tunnuspalvelu tunnistaa kohteena olevan tenantin pyynnön Host-headerista ja validoi clientin, redirect URI:n, pyydetyt scopet ja PKCE-parametrit.
  3. Jos käyttäjällä ei ole voimassaolevaa sessiota tällä tenantilla, hänet ohjataan kirjautumissivulle. Näkyvät kirjautumistavat riippuvat tenantin auth-policysta — ks. Kirjautumistavat.
  4. Käyttäjä tunnistautuu valitsemallaan tavalla (magic link, passkey tai Google, tenantin sallimien menetelmien mukaan).
  5. Jos client ei ole tenantin oma ensimmäisen osapuolen sovellus eikä käyttäjä ole aiemmin hyväksynyt pyydettyjä scopeja, näytetään consent-sivu.
  6. tunnuspalvelu luo kertakäyttöisen authorization coden ja ohjaa käyttäjän takaisin sovelluksesi redirect_uri-osoitteeseen.
  7. Sovelluksesi vaihtaa coden /token-endpointissa access- ja ID-tokeniin — ja refresh tokeniin, jos pyydetty scope sisälsi offline_access.
  8. Sovelluksesi voi lukea käyttäjätiedot suoraan ID-tokenin claimeista, tai hakea ne /userinfo-endpointista access tokenilla.

Tarkempi tokenien, claimien ja PKCE:n kuvaus: Web-sovelluksen kirjautuminen ja Tokenit ja claimit.

Onnistuneen kirjautumisen jälkeen tunnuspalvelu asettaa selainistuntoevästeen, joka on sidottu tenantin domainiin. Kun käyttäjä palaa samalla tenantilla toiseen samaan tenanttiin liitettyyn sovellukseen, hän ei joudu kirjautumaan uudelleen — ainoastaan consent kysytään tarvittaessa uudelleen sovelluskohtaisesti. Eri tenantit eivät jaa istuntoa keskenään, koska kullakin tenantilla on oma domain ja oma istuntoeväste.

Käyttäjä voi tarkastella ja perua aktiiviset istuntonsa omasta tilinhallinnastaan (/account/sessions).

Tili luodaan automaattisesti ensimmäisellä kirjautumisella

Osio nimeltä “Tili luodaan automaattisesti ensimmäisellä kirjautumisella”

tunnuspalvelussa ei ole erillistä rekisteröitymislomaketta. Kun käyttäjä kirjautuu ensimmäistä kertaa magic linkillä tai Google-kirjautumisella, tunnuspalvelu luo käyttäjätilin automaattisesti tunnistetulla sähköpostiosoitteella. Passkey lisätään yleensä olemassa olevalle tilille ensimmäisen kirjautumisen jälkeen omasta tilinhallinnasta.

GET /logout toteuttaa OIDC:n RP-Initiated Logout -mekanismin: sovellus ohjaa käyttäjän tähän endpointiin, istunto mitätöidään, ja käyttäjä ohjataan takaisin sovelluksen rekisteröityyn post_logout_redirect_uri-osoitteeseen. Jos sovellus on rekisteröinyt back-channel logout -osoitteen, tunnuspalvelu ilmoittaa uloskirjautumisesta myös muille sovelluksille, joille käyttäjä on antanut suostumuksen samalla istunnolla — käyttäjän ei tarvitse kirjautua ulos jokaisesta sovelluksesta erikseen.