Skip to content

Latest commit

 

History

History
93 lines (61 loc) · 6.65 KB

spa_refresh.md

File metadata and controls

93 lines (61 loc) · 6.65 KB

Problem

  1. ID-porten tillet ikkje at public-klienter kan få refresh_token, sidan dei ikkje kan bevise kven dei er (klient-autentisering) ved forsøk på refresh.

  2. ID-portens støttar ikkje "silent renewal" (prompt=none), pga. begresningar i produktet som ID-porten er basert på.

  3. ID-porten støtter ikke OIDC session management og annonserer heller ikke check_session_iframe

  4. Browsere innfører strengare handtering av 3djeparts-cookies, som gjer at iframe-baserte metodar som "silent renewal" uansett ikkje vil fungere i framtida https://leastprivilege.com/2020/03/31/spas-are-dead/ :

What this basically means is, that browser are getting more and more strict with how they handle their cookies. [...] the immediate consequences will be:

  • front-channel logout notifications do not work anymore (used in pretty much every authentication protocol – like SAML, WS-Fed and OpenID Connect)
  • the OpenID Connect JavaScript session notifications don’t working anymore
  • the “silent renew” technique that was recommended so far to give your application session bound token refreshing don’t work anymore

Safari and Brave are the first browser implementing those changes. Chrome will follow in 2022 (hopefully sooner) etc…

Some things can be fixed, e.g. you can replace front-channel notifications with back-channel ones. Some people recommend replacing silent renew with refresh tokens. This is dangerous advice – even if your token service has implemented countermeasures.

Mogelege løysingar

1: Kunde må bruke backend-for-frontend arkitektur

Dominick Baier over er ganske klar på at det er dette han anbefalar...

Dvs. lage ein tynn backend mellom SPA og ID-porten. BFFen blir då ein confidential oauth-klient sett frå idporten og kan få refresh_token. Transparent ruting av API-kall gjennom BFF-en.

Kunden må jo uansett tilby eit domene som SPAen skal lastast frå, så å utvide denne med ein tynn backend burde vere overkommeleg. Fordelen er at ein får høgare sikkerheit kring tokens. Men ulempa er at det medfører behov for forvaltningsregime rundt backend, behandling av personopplysningar når API-kall går gjennom BFF - men kunden slepp vel ikkje unna dette ansvaret sjølv om ved ein "rein" SPA.

2: Utlevere refresh_token til public klienter

ID-porten endrer oppførsel slik at dersom ein klient har application_type=browser, så får den også lov til å motta eit refresh_token.

Men for å ivareta tilstrekkelig sikkerheit, bør vi innføre tilleggstiltak i tråd med oppdaterte retningslinjer fra IETF, dvs.

Potensielle tilleggstiltak:

  • rotere refresh_token Kvar gong eit refresh_token blir brukt, blir det laga eit nytt refresh_token og det gamle invalidert.
  • Rotasjon med replay-deteksjon Som over, men gamle refresh_token blir lagra i ID-porten so lenge autorisasjonen varar. Dersom gamle refresh_token blir forsøkt brukt, blir alt invalidert.
  • avsender-begrensa refresh_token Binde refresh_tokenet til avsender slik at avsender må bevise besittelse av et privatnøkkel ved bruk, anten til TLS-laget gjennom https://tools.ietf.org/html/rfc8705, eller på applikasjonslag med DPoP (https://tools.ietf.org/html/draft-ietf-oauth-dpop-02#section-5)
  • Invalidere autorisasjon ved inaktivet Dersom SPAen ikkje fornyer refresh_token innafor ein viss tid som er "rimeleg", (td. 50 ganger levetida til access_token), så blir heile autorisasjonen og tilhøyrande token invalidert av ID-porten. (Døme: autorisasjon varar 24 timar, access_token er 30 sekund, dersom refresh ikkje er brukt på 50*30 = 25 minutt, så blir autorisasjon ugyldig.). Slik oppførsel kan ein få til ved å tune levetidsparametre idag, men API-tilbder kan ikkje tvinge det, så alternativt kan ein vurdere å innføre refresh_token_max_lifetime på scopet.

Dominick meiner på https://leastprivilege.com/2020/01/21/hardening-refresh-tokens/ at ein også bør:

  • kreve samtykke-dialog til autorisasjonen før klient kan få refresh-token

3: Offline-access for å trigge refreshtoken

OIDC har definert eit eige scope for å trigge såkalla offline access. https://openid.net/specs/openid-connect-core-1_0.html#OfflineAccess

spec'messig så er det berre /userinfo-endepunktet som det er spesifisert at scopet skal gi tilgang til - gjer vi feil ved å bruke offline_access for rein oauth ?

Det er uklart for oss korleis dette heng saman med silent renewal-metodene. Bør offline_access vere det som trigger at klienten faktisk får eit refresh token ?

Det er også slik at i dei tilfella som har vore rapportert til oss, so har det alltid vore snakk om at brukaren faktisk er til stades i perioden.

Andre produkt

Auth0

ser ut til å bruke 'offline_access' for å få refresh_token. Blir berre gitt til OIDC-compliant klient. https://auth0.com/blog/achieving-a-seamless-user-experience-with-refresh-token-inactivity-lifetimes/ Dei støttar "refresh token rotatation", "refresh token inactiviy" og "refresh token replay detection"

c2id

Som vanlig ganske konfigurerbar. I utgangspunktet får alle refresh-token, men det kan globalt setjast slik at berre klienter konfigurert for å kunne bruke "grant_type=refresh" får refresh_token. Skiljer mellom short-lived og long-lived autorisasjons (usikkert på kva som trigger) Levetid mulig å sette per klient, eller bruke global setting.

curity

skumma gjennom dok, men fann ikkje noko

identityserver

https://identityserver4.readthedocs.io/en/latest/topics/refresh_tokens.html The clients needs to be explicitly authorized to request refresh tokens by setting AllowOfflineAccess to true. Klienten må sende "offline access" scope for å få refresh. Støttar rotation Set refreshtoken-lifetime per klient. Støttar replay detection (It is important to note, that a refresh token is never deleted in the database. Once it has been used, the ConsumedTime property will be set. If a token is received that has already been consumed, the default service will call a virtual method called AcceptConsumedTokenAsync.)

Azure AD

https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-permissions-and-consent#openid-connect-scopes On the Microsoft identity platform (requests made to the v2.0 endpoint), your app must explicitly request the offline_access scope, to receive refresh tokens. Viser ein scope-tekst "Access your data anytime"...