Altinn anbefaling for innlogging (OAuth autentisering)
Anbefalingen fra Altinn i 2016 var å bruke «redirect» metoden for innlogging for å bruke REST APIet for sluttbrukersystemer: https://tt02.altinn.no/Pages/ExternalAuthentication/Redirect.aspx?returnUrl=https://fellesbygg.dibk.no/Skjema
Denne metoden er nå “legacy”: https://altinn.github.io/docs/api/rest/kom-i-gang/idporten-legacy/#4-autentisering-ved-integrasjon-i-andre-portaler
Nå anbefaler Altinn å bruke OIDC/OAuth2-basert autentisering:
De fleste nettlesere nå inn kraftig på hvordan tredjepartscookies benyttes, og dette påvirker også den cookie-baserte autentiseringsmekansimen Altinn tilbyr for nettleser-baserte integrasjoner.
Som en konsekvens av dette er nå denne mekanismen ansett som legacy, og vi anbefaler å migrere over på OIDC/OAuth2-basert autentisering med ID-porten. Dette erstatter cookien med et bearer-token, som gjør det mulig å lage både backend- og frontend-baserte integrasjoner som ikke rammes av disse restriksjonene.
Les mer om dette på https://altinn.github.io/docs/api/rest/kom-i-gang/ (under seksjonen "Autentisering med ID-porten"), samt https://altinn.github.io/docs/api/rest/kom-i-gang/scopes/#sluttbruker-api for en liste over hvilke scopes REST-API-et er delt opp i. Dette vil også kreve tilgang til samarbeidsportalen til ID-porten for å opprette disse integrasjonene. Dette er kostnadsfritt. Det vil fortsatt kreves en API-nøkkel utstedt fra Altinn, men dere kan fortsette å bruke den dere bruker i dag.
De fleste scopene som krever en autentisert person innebærer at sluttbrukeren fremvises en dialog hvor han/hun må godkjenne at applikasjonen skal få tilgang. For å lette jobben med å migrere fra legacy-integrasjoner, har vi imidlertid et scope "altinn:endusernoconsent" tilgjengelig for Altinn-tjenesteeiere (som DIBK). Dette gjør det mulig å hente ut et bearer-token uten brukerinteraksjon, slik at dette kan tas i bruk uten at brukerflyten i eksisterende integrasjoner må endres. Man kan fortsatt ksessere Altinn-API-ene fra frontend (nettleser) via en såkalt "public client", se mer om dette på https://difi.github.io/felleslosninger/oidc_auth_spa.html.
Altinn og DiBK anbefaler at stønadssystemene tar en kikk på denne anbefalingen. Det er ikke sikkert at den cookie baserte innloggingen vi bruker i dag vil fungerer smertefritt framover.
Oppdateringer/klareringer:
Sluttbrukersystemene (konsumentene) må selv tegne en avtale med ID-porten/Digdir og få tilgang til Samarbeidsportalen for å opprette sine klienter. Onboardingen for private virksomheter er for ID-porten dessverre ikke helt på plass, men https://samarbeid.digdir.no/id-porten/ta-i-bruk-id-porten/94 har mer informasjon om dette – ellers kan de kontakte servicedesk@digdir.no
Når tilgang er på plass, må altså konsumenten registrere en klient (herunder konfigurere autentiseringsmetode, f.eks. client_secret, og provisjonere scopes). Les mer om dette på https://difi.github.io/felleslosninger/oidc_func_clientreg.html. Dette gjøres typisk direkte i administrasjonsgrensesnittet i Samarbeidsportalen. Så:
Client_secret / client_id blir tildelt ifm opprettelse av klienten. API-key i Altinn er uavhengig av dette.
Scopes knyttes til klienten.
Statehåndtering:
Hvis man med «klienten» her mener sluttbrukers nettleser, så ja er det mulig. Dette er da såkalt public klienter i OAuth2, og har en annen trusselmodell en må sette seg inn i. Se mer på https://difi.github.io/felleslosninger/oidc_auth_spa.html
Altinn tillater bruk av public klienter for sine API-er.
Merk at scopet «altinn:endusernoconsent» ikke er tilgjengelig for andre enn tjenesteeiere i Altinn, og heller ikke for nye integrasjoner. Dette er kun et scope som tilbys eksisterende legacy cookie-baserte implementasjoner som et hjelpemiddel ifm migrering til OIDC/OAuth2.
Får å få tilgang til dette scopet må søknadsystement få spesiell tilgang fra Altinn sentralforvaltning. Dette starter med en Service Desk sak til DiBK.
Andre relevante lenker:
https://difi.github.io/felleslosninger/oidc_guide_idporten.html
https://difi.github.io/felleslosninger/oidc_auth_spa.html
https://difi.github.io/felleslosninger/oidc_auth_spa.html
Oppdateringer:
Testing av autentisering.
https://docs.digdir.no/idporten_verifikasjonstester.html
Søknadssystemet tester dette selv. Fra DigDir: Testene skal sørge for at innlogging og utlogging fungerer som det skal. Vi sjekker ikke opp om kundene gjør dette.