Tilsvarende Single-page applikasjoner, så kan ikke en mobil-app beskytte hemlighetene sine på en tilfredstillende måte. Den er altså en Oauth2 public klient, og kalles ofte native app i oauth2-dokumentasjonen.
I OAuth 2.0 for Native Apps er det gitt anbefalinger for hvordan bruke Oauth2/OpenID Connect på mobil-app’er. Vi anbefaler kunder å studere dette dokumentet nøye. Vi vil trekke frem følgende:
En mobil-app vil typisk integerere med kundens eget API (“app backend”). Det er opp til kunden om han vil bruke ID-porten sine access_token til sikring av dette APIet direkte, eller omsette ID-portens token til sine egne tokens.
Vanligvis er det backend-en som er registrert som klient i ID-porten, ikke selve app’en.
Digitaliseringsdirektoratet krever at kunder som omsetter punkt-autentiseringen fra ID-porten til en langt-levende innlogging, oppfyller følgende krav:
Oversikt over innlogginger med revokasjonsmulighet for innlogget innbygger er også tilgjengelig på et eget API, slik at kunden kan velge å også tilby slik funksjonalitet integrert i egen selvbetjeningsløsning.
Den enkleste måten å håndtere kravene ovenfor, er å bruke et langt-levende access_token som manifestasjon av den lange innloggingen. I praksis vil dette medføre:
Alternativt kan kunden bruke en variant med kort-levde access_token i kombinasjon med refresh_tokens.
Flyten er identisk som for autorisasjonskode-flyten, men med bruk av PKCE:
I tilegg må kunden forespørre eget scope som hører til den langt-levende innloggingen og behandle dette som forklart i forrige avsnitt.
ID-tokenet er identisk som ved bruk av autorisasjonskode-flyten. Selv om det er access_tokenet som skal benyttes videre, må kunden først validere id_tokenet ihht vanlig beste praksis for OIDC.
Access_tokenet vil inneholde fødseslnummer på innbyggeren, scopet som er registrert, og utløpstiden på tokenet.
© Digitaliseringsdirektoratet