Hybrid Flow OIDC:llä

Hybrid Flow perustuu sen `response_type`-parametriin. Toisin kuin `code` (Authorization Code Flow) tai `id_token token` (Implicit Flow), Hybrid Flow käyttää yhdistelmiä.

Yleisiä Hybrid Flow -tilan `response_type`-arvoja ovat:

• code id_token
• code token
• code token id_token

Näiden avulla Authorization Serverille ilmoitetaan tarkasti, mitkä tokenit sen tulee palauttaa front-channel-vastauksessa.

Prosessi alkaa kuten muutkin OIDC-virrat. Client-sovellus ohjaa käyttäjän selaimen Authorization Serverin valtuutuspäätepisteeseen.

Pyyntö sisältää esimerkiksi seuraavat parametrit:

• client_id: Sovelluksen tunniste.
• redirect_uri: Osoite, johon käyttäjä ohjataan takaisin.
• response_type: Keskeinen hybridi-yhdistelmä, kuten code id_token.
• scope: Resurssit tai tiedot, joita haluat käyttää, kuten openid profile.
• nonce: Yksilöllinen, kertakäyttöinen arvo uudelleentoistohyökkäysten torjumiseen.
• state: Tilatiedon säilyttämiseen ja CSRF-hyökkäysten estämiseen.

Kun käyttäjä on todentanut henkilöllisyytensä ja antanut suostumuksensa, Authorization Server ohjaa käyttäjän selaimen takaisin määritettyyn redirect_uri-osoitteeseen.

On tärkeää huomata, että tämä front-channel-uudelleenohjauksen URL sisältää sekä valtuutus-code-arvon että vähintään yhden tokenin, kuten id_token- tai access_token-tokenin, suoraan URL-osoitteen fragmentissa tai kyselymerkkijonossa response_type-arvosta riippuen.

Kun käytössä on esimerkiksi response_type=code id_token, saat molemmat.

Uudelleenohjauksen vastaanotettuaan client-puolen sovellus, kuten Single-Page Application, voi poimia id_token-tokenin välittömästi URL-osoitteen fragmentista.

Tätä ID Tokenia voidaan käyttää seuraaviin tarkoituksiin:

• Käyttäjän todentamiseen paikallisesti.
• Käyttöliittymän päivittämiseen käyttäjän profiilitiedoilla.
• Välittömän sisäänkirjautumisen vaikutelman tarjoamiseen ilman uusia verkkopyyntöjä.

Myös code poimitaan myöhempää käyttöä varten.

Front-channel-vastauksessa vastaanotettua valtuutusarvoa code käytetään sitten client-sovelluksesta tehtävään suoraan ja suojattuun back-channel-pyyntöön Authorization Serverin tokenien päätepisteeseen.

Tässä pyynnössä, joka tehdään yleensä taustapalvelimelta tai suojatusta client-sovelluksesta, code vaihdetaan uuteen access_token-tokeniin ja ennen kaikkea refresh_token-tokeniin.

Näin varmistetaan, ettei refresh token päädy koskaan selaimeen.

Hybrid Flow -tilassa saatat vastaanottaa tokeneita kahdesta eri kanavasta: front-channelista (ID Token ja mahdollisesti Access Token) sekä back-channelista (Access Token ja Refresh Token).

Kaikkien vastaanotettujen tokenien validointi on erittäin tärkeää niiden aitouden, eheyden ja voimassaolon varmistamiseksi. Tähän kuuluu allekirjoitusten, vanhenemisajan, kohdeyleisön, myöntäjän ja ID Tokenien nonce-arvon tarkistaminen.

Hybrid Flow on usein suositeltava sovelluksille, jotka tarvitsevat nopeasti näkyvän sisäänkirjautumisen front-channelin ID Tokenin avulla, mutta myös refresh tokenin tarjoaman suojan pitkäkestoisia istuntoja varten back-channelissa tehtävän code-vaihdon kautta.

• Edut: Välitön käyttökokemus ja refresh tokenin suojaus.
• Haitat: Toteutus ja validointi ovat monimutkaisempia, koska tokeneita tulee useita ja eri kanavista.

Se tasapainottaa käyttökokemuksen ja refresh tokenien hankkimiseen liittyvän vahvan suojauksen.

Tänään tutustuimme OpenID Connectin Hybrid Flow -tilaan. Opimme, miten se yhdistää strategisesti Authorization Code- ja Implicit-virtojen ominaisuuksia käyttämällä tiettyjä response_type-arvoja.

Näin sovellukset voivat saada identiteettitiedot välittömästi suoraan selaimessa ja samalla säilyttää refresh tokenien back-channel-vaihtojen tarjoaman suojan. Se on tehokas väline joustavaan ja turvalliseen identiteetin hallintaan.