I dette scenariet logger en innbygger inn til en tjeneste, og tjenesten har behov for å hente data om den innlogga brukeren fra et API som ligger hos en 3dje-part. Man er selvsagt ikke begrenset til kun lese-operasjoner, enhver API-operasjon som API-tilbyderen tilrettelegger for at skal kunne integreres i eksterne tjenester kan realiseres med dette løsningsmønsteret.
Slike scenario realiseres i ID-porten ved den klassiske Oauth2-flyten, der innbyggeren godkjenner - enten eksplisitt eller implisitt - til at tjenesten kan bruke et API på vegne av seg selv.
Ved implisitt samtykke er det autentiseringshandlingen som i seg selv tolkes som samtykket (“Ved å logge inn i tjenesten godtar du at vi henter opplysninger om deg fra NAV”). Vi bruker derfor begrepet autentiseringsnær autorisasjon om dette løsningsmønsteret.
Ved eksplisitt samtykke er det brukeren selv som godkjenner om tjenesten får agere på dennes vegne opp mot APIet. Vi bruker derfor begrepet brukerstyrt datadeling om dette løsningsmønsteret.
For eksplisitte samtykker som skal vare “lenge” (“jeg samtykker til at Banken min kan hente inntektsopplysninger hos Skatteetaten de neste 3 årene”) henviser vi til bruk av Samtykkeløsningen i Altinn.
Hvilket API/ressurs som skal aksesseres, er styrt av scopes. Klienten må vite hvilke(t) scope som hører til den aktuelle API-operasjonen, og må forespørre dette scopet i autorisasjonsforespørselen. Dersom scopet har egenskapen requires_user_consent
satt, vil ID-porten vise en enkel godkjennings-dialog til innbygger når autentisering er fullført. Se eksempel under:
Selve autorisasjonen blir av ID-porten utlevert som et access_token (datadelingstoken). Tjenesten bruker så dette access_tokenet når den skal aksessere APIet. Dersom brukeren ikke godtar, vil det aktuelle scopet ikke bli inkludert i access_tokenet
Det er flere gode grunner for API-tilbydere til å bruke dette samhandlingsmønsteret:
Eksempler på bruk av løsningsmønsteret:
Følgende aktører inngår:
Aktør | Beskrivelse | Begrep OIDC | Begrep Oauth2 | Begrep SAML2 |
---|---|---|---|---|
Sluttbruker | Ønsker å logge inn til en tjeneste | End User | User | End User |
Nett-tjeneste | Sluttbruker-tjeneste tilbudt av en privat eller offentlig etat | Relying Party (RP) | Client | Service Provider (SP) |
ID-porten | ID-porten sin OpenID Connect provider som usteder access_token til aktuelle tjenesten | OpenID Provider (OP) | Authorization server (AS) | Identity Provider (IDP) |
API | 3.part, som tilbyr et API som sluttbrukertjenesten ønsker å benytte | - | Resource server (RS) | - |
Starten av flyten er identisk med autorisasjonskode-flyten for autentisering (se denne for detaljer), med følgende tillegg:
Forskjellen på autentisering (OpenIDConnect) og autorisasjon med “plain” Oauth2 er altså minimal:
For nærmere detaljer om innholdet i access_token, se grensesnittsdefinisjon av /token-endepunktet. Se også dokumentasjon av scopes.
© Digitaliseringsdirektoratet