Hjem  >  idporten  >  oidc  >  releaser

20-11 OIDC

Forbetringar i tilgangsdialog for “brukerstyrt datadeling”

Releasen vart produksjonssatt Dec 10, 2020

Ny funksjonalitet:

Forbedringer for brukerstyrt datadeling (Ready to ship)

Tekstene i tilgangsdialogen (samtykkedialogen) for brukerstyrt datadeling blir tydeligere og fokuserer på tilganger til applikasjoner og nettsteder. Brukeren får nå også se hvor lenge tilgangen som gis til applikasjonen vil vare.

API-tilbyder kan registere en Markdown-formattert long_description som kan brukes for å gi brukerene en lengre forklaring på hvilke tilganger som applikasjonen ber om.

API-tilbyder får også mulighet til å spesifisere en authorization_max_lifetime som begrenser levetid på selve autorisasjonen. Dette betyr at en tilbyder nå kan kontrollere levetid både på access_tokens og på hele autorisasjonen.

Scope-beskrivelser kan også nå angis med oversettelser til de samme språkene som ID-porten støtter (nynorsk, engelsk, samisk). Dersom oversettelser ikke angis, er det fallback til default som er bokmål.

API-tilbyder kan kreve psedonymisering (Shipped)

En API-tilbyder kan nå sette flagget requires_pseudonymous_tokens på et scope. Det vil medføre at både id_token og access_token som klientene mottar aldri vil inneholde personidentifikator (pid). Tilbyder er derfor ikke lenger avhengig av manuelle rutiner hos Digdir for å få satt no_pid-funksjonalitet på klienter.

Klienter med samme orgno som eier scopet vil få utlevert pid ved token-introspection.

Forbetringar:

OIDC provider skal ikke lenger akseptere Base64 padding i PKCE code_challenge (PBLEID-21272)

Innførere strengere valideringe i OIDC-provider slik at Base64 padding-teikn (=) på slutten av code_challenge-parameter ikke lenger blir akseptert på token-endepunkt.

OIDC provider skal akseptere token-endepunktets URL som audience for klientautentisering med JWT (PBLEID-20928)

Ved klientautentisering med JWT mot endepunkter som krever klientautentisering, skal tokenendepunktets URL aksepteres som audience-verdi i tillegg til vår issuer.

Ref spec: https://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication:

“The Audience SHOULD be the URL of the Authorization Server’s Token Endpoint.”

Feilrettingar:

ikkje mulig å bruke delegering saman med accessible_for_all scope (PBLEID-21170)

Dersom scope er accessible_for_all, er det idag ikkje mogeleg å bruke delegering i Altinn gjennom Maskinporten. Dette er en unødig begrensning. Det finst gyldige scenario der ein kunde ønsker å eksplisitt seie at ein leverandør skal få opptre på sine vegne, også opp mot eit accessible-for-all API. Tilgangstyring og API-respons (dataminimering) kan til dømes vere avhengig av kven som er juridisk konsument.

Vi løyse dette ved å tillate delegering ogso for accessible-for-all scopes.