@ksvedal/docs 0.1.0

package/dist/search-index.json

@@ -0,0 +1,450 @@
+[
+  {
+    "id": "en-start-Starthjelp",
+    "title": "Startup guide",
+    "content": "# Startup guide\n\nKlare yourself",
+    "lang": "en",
+    "path": "/en/start/Starthjelp"
+  },
+  {
+    "id": "en-start-faq",
+    "title": "Frequently stilted quastions",
+    "content": "# Frequently stilted quastions\n\n## How do i create pannekaker?\n\nYou Dont",
+    "lang": "en",
+    "path": "/en/start/faq"
+  },
+  {
+    "id": "en-start-oidc-access_token_lifetime",
+    "title": "Access token lifetime",
+    "content": "# Access token lifetime\n\n## Purpose\n\nAccess token lifetime specifies how long an access token remains valid.\n\nWhen the lifetime expires, the token can no longer be used against protected resources.\n\n## Technical behavior\n\nAn access token represents time-limited access to APIs and resources within the granted scopes and permissions. The lifetime determines how long this access can be used without renewal.\n\n### Trade-off\n\nA short lifetime improves security because a leaked token can be misused for a shorter period of time.\n\nA longer lifetime reduces how often tokens must be renewed and can simplify client logic, but it also increases the impact if the token is compromised.\n\n## Use in OIDC clients\n\n### ID-porten and Ansattporten\n\nFor user-facing OIDC clients, access token lifetime should be considered together with whether refresh tokens are used. A short access token lifetime combined with controlled renewal is a common pattern.\n\n### Maskinporten\n\nMaskinporten also relies on time-limited tokens, and lifetime is equally important there to balance security and operational use.\n",
+    "lang": "en",
+    "path": "/en/start/oidc/access_token_lifetime"
+  },
+  {
+    "id": "en-start-oidc-allowed_grant_types",
+    "title": "Allowed grant types",
+    "content": "# Allowed grant types\n\n## Purpose\n\nAllowed grant types define which OAuth 2.0 flows a client is permitted to use.\n\nA grant type describes how the client obtains tokens, and is therefore an important part of the client's security and integration profile.\n\n## Technical behavior\n\nEach grant type represents a specific authorization pattern. Restricting which grant types are allowed also restricts which token flows the client can use.\n\nThis is important in order to:\n\n- reduce the attack surface\n- prevent unintended use of unwanted flows\n- make the client configuration more predictable\n\n### Security principle\n\nA client should only have access to the grant types it actually needs. Unnecessary flows should not be enabled.\n\n## authorization_code\n\n`authorization_code` is a grant type where a client first sends the user to the authorization server for authentication, and then receives an authorization code that is exchanged for tokens.\n\nThis is the most common and recommended flow for browser-based sign-in in OIDC.\n\n### Technical behavior\n\nThe flow typically consists of these steps:\n\n1. The client sends the user to the authorization endpoint.\n2. The user authenticates.\n3. The authorization server returns the user to the client's redirect URI with an authorization code.\n4. The client sends the authorization code to the token endpoint.\n5. The client receives an access token, and optionally an ID token and refresh token.\n\n#### Why this flow is considered secure\n\nIn this flow, tokens are not returned directly through the browser. Instead, a short-lived code is returned, which the client must exchange server-to-server. This reduces the risk of leakage compared with less robust patterns.\n\n#### PKCE\n\n`authorization_code` is often used together with PKCE. PKCE protects against the authorization code being intercepted and misused by someone other than the client that started the flow.\n\n## Use in OIDC clients\n\n### ID-porten\n\nThis is the central grant type for regular OIDC logins against ID-porten.\n\n### Ansattporten\n\nAnsattporten uses the same basic pattern for user authentication and token exchange, so `authorization_code` is equally relevant there.\n\n### Maskinporten\n\nThis grant type is normally not used for Maskinporten, since Maskinporten is not based on interactive user login in a browser.\n\n## Refresh token\n\nA refresh token allows a client to obtain new access tokens without requiring the user to authenticate again every time an access token expires.\n\nThis is used to maintain long-lived sessions or access over time.\n\n### Technical behavior\n\nWhen a client receives both an access token and a refresh token, the flow can look like this:\n\n1. The access token is used against protected APIs.\n2. When the access token expires, the client sends the refresh token to the token endpoint.\n3. The authorization server issues a new access token if the refresh token is still valid.\n\n### Security significance\n\nA refresh token is often more sensitive than an access token, because it can be used to issue new tokens over time. It must therefore be stored and handled with a high degree of protection.\n\n## Use in OIDC clients\n\n### ID-porten and Ansattporten\n\nFor clients that need persistent user sessions, refresh tokens can be relevant. This must be evaluated against actual need, security level, and how the client stores tokens.\n\n### Maskinporten\n\nRefresh tokens are normally not part of the common pattern in Maskinporten, since Maskinporten typically does not represent user sessions in the same way as OIDC clients for end users.\n\n## Use in OIDC clients\n\n### ID-porten and Ansattporten\n\nFor end-user-facing OIDC clients, `authorization_code` is the most relevant grant type. It is used when a user authenticates through a browser and the client then obtains tokens from the token endpoint.\n\n### Maskinporten\n\nMaskinporten is normally used for machine-to-machine authorization and follows different patterns than regular user login. Documentation that discusses OIDC clients will therefore usually be most relevant for ID-porten and Ansattporten.\n",
+    "lang": "en",
+    "path": "/en/start/oidc/allowed_grant_types"
+  },
+  {
+    "id": "en-start-oidc-ansattporten-entraid-entraid",
+    "title": "Generelt om EntraID",
+    "content": "# Generelt om EntraID\n\nMicrosoft ",
+    "lang": "en",
+    "path": "/en/start/oidc/ansattporten/entraid/entraid"
+  },
+  {
+    "id": "en-start-oidc-ansattporten-general",
+    "title": "Generelt om ansattporten",
+    "content": "# Generelt om ansattporten\nAnsattporten er en egen innloggingtjeneste med funksjonalitet som er tilpasset bruk som ansatt eller i andre situasjoner der en nett-tjeneste eller et API har behov for at sluttbruker må opptre i et representasjonsforhold på vegne av virksomheter.\n\n```mermaid\ngraph LR\n  I(ID-porten)\n  A(Ansattporten)\n  IRP(Tjeneste for innbygger)\n  ARP(Tjeneste for ansatte)\n\n  eid[\"Privat eID-leverandør \n  (MinID, BankID, etc... )\"]\n  ak[(\"Autorativ kilde\n(Altinn Autorisasjon)\")]\n  aid[\"Ansatt-eid\n(pilot: Microsoft Entra ID)\"]\n\n  IRP -. integrert mot .- I \n  I -. videreformidler innlogging fra  .- eid\n\n  ARP -. integrert mot .-\u003e A\n  A -. videreformidler innlogging fra .-\u003e eid \n  A -.-\u003e |henter representasjon fra | ak\n\n  A -...- | videreformidler innlogging og representasjon fra | aid\n```\n\nDisse viktigste egenskapene ved Ansattporten er som følger:\n\n### Egen \"port\"\n\nAnsattporten er en selvstendig tjeneste som er uavhengig av ID-porten.  Det betyr at tjenester i ID-porten ikke er mulig å nå fra Ansattporten og vice versa. \n\nSamtidig så deler ID-porten og Ansattporten samme kildekode-base, så det er i praksis bare litt konfigurasjon og tilpasset funksjonalitet som skiller de to portene teknisk.  Som hovedregel vil oppdateringer, feilrettinger og ny funksjonalitet bli rullet ut mer eller mindre samtidig til begge portene. Ansattporten tilbyr også de samme elektroniske ID'ene som er tilbudt av ID-porten, dvs. MinID, BankID, Buypass og Commfides.\n\nProtokollmessig sier vi at Ansattporten er en egen Oauth2 autorisasjonsserver / OpenID Provider, identifisert ved sin `issuer`-verdi.\n\n\n### Ingen SSO-funksjonalitet mellom tjenester\n\nSom forklart ovenfor, så er ID-porten og Ansattporten isolert fra hverandre som separate OpenID providere. Det er derfor ikke mulig å få single-sign on (SSO) mellom ansatt-tjenester i Ansattporten til innbygger-tjenester i ID-porten.  \n\nMen til forskjell fra ID-porten så tilbyr ikke Ansattporten SSO mellom de ulike tjenestene heller.  Dette er realisert ved at alle klienter får tvangs-satt flagget som aktiverer funksjonaliteten [isolert sso-sesjon](../../docs/idporten/oidc/oidc_func_nosso.html).\n\n### Autorative kilder for representasjon\n\nAnsattporten kan brukes enten til ordinær punktinnlogging, eller til å kreve at innlogga bruker må ha et bestemt representasjonsforhold for en virksomhet.   Ansattporten har ikke - og vil aldri få - sin egen database/register over roller/rettigheter, men baserer seg på eksterne, autorative kilder for representasjonsforhold.\n\nDersom tjenesten krever representasjon, vil Ansattporten vise en organisasjonsvelger til brukeren, som er forhåndspopulert basert den autorative kilden.\n\nI dag er det kun Altinn Autorisasjon som er støttet som autorativ kilde. \n\n\n# Hvem kan bruke Ansattporten ?\n\nAlle kunder som har inngått Digdir sine bruksvilkår for fellesløsninger kan bruke Ansattporten til ordinær punkt-autentisering på samme måte som de gjør i ID-porten idag.\n\nMen bare kunder som også er tjenesteeier i Altinn, kan bruke funksjonaliteten med organisasjonsvelger og tilgangstyring basert på representasjonsforhold i Altinn Autorisasjon.\n\n\n# Hva koster Ansattporten ?\n\nP.t. har Ansattporten samme finansieringsmodell som ID-porten.  200.000-innnloggingskvoten er felles for de to portene.\n\nMerk at finansieringsmodell trolig vil endres i fremtiden.\n\n\n# Hvordan administrerer jeg Ansattporten ?\n\nPå akkurat samme måte som for ID-porten, men du må passe på at integrasjonene du opprette i selvbetjening har `integration_type` satt til `ansattporten`.\n\n\n# Er Ansattporten fremdeles i pilot-status? \n\nFra 2025 går Ansattporten over i mer ordinær drift.  SLA i form av oppetid vil være den samme som for ID-porten, og feilrettinger vil bli prioritert ihht de ordinære rutinene rundt fellesløsningene.\n\nSe [artikkel på Samarbeidsportalen](https://samarbeid.digdir.no/ansattporten/ansattporten-er-no-i-produksjon-som-ei-fullverdig-fellesloysing/2969).\n\n# Hvilken bruk-scenario støttes ? \n\nAnsattporten tilbyr per nå tre brukerreiser:\n\n* [Vanlig innlogging (med isolert SSO)](ansattporten_guide.html)\n* [Innlogging på vegne av virksomhet](ansattporten_representasjon.html)\n* [Datadeling på vegne av virksomhet](ansattporten_datadeling.html)\n",
+    "lang": "en",
+    "path": "/en/start/oidc/ansattporten/general"
+  },
+  {
+    "id": "en-start-oidc-ansattporten-integration_guide",
+    "title": "Integrasjonsguide",
+    "content": "# Integrasjonsguide\n\nSitronkake og mozell",
+    "lang": "en",
+    "path": "/en/start/oidc/ansattporten/integration_guide"
+  },
+  {
+    "id": "en-start-oidc-application_type",
+    "title": "Application types",
+    "content": "# Application types\n\n## Web Application\n\nA web application is software that runs on a remote server and is accessed through a web browser. Nothing is installed locally by the user.\n\n### Characteristics\n- Accessed via URL  \n- Runs in a browser  \n- Platform-independent  \n- Centrally maintained and updated  \n\n## Browser Application\n\nA browser application is a web application that runs directly inside the browser environment using technologies such as HTML, CSS, and JavaScript.\n\n### Characteristics\n- Executes inside the browser engine  \n- No local installation required  \n- Uses browser APIs  \n- Dependent on browser capabilities  \n\nNote: “Web app” and “browser app” are often used interchangeably, but “browser application” emphasizes execution inside the browser.\n\n## Native Application\n\nA native application is installed directly on a device and runs on the operating system rather than inside a browser.\n\n### Characteristics\n- Requires installation  \n- Built for a specific operating system  \n- Direct access to hardware and system resources  \n- Typically higher performance  ",
+    "lang": "en",
+    "path": "/en/start/oidc/application_type"
+  },
+  {
+    "id": "en-start-oidc-authentication_method",
+    "title": "Authentication method",
+    "content": "# Authentication method\n\n## Purpose\n\nThe authentication method specifies how a client identifies and authenticates itself to the authorization server when calling endpoints that require client authentication, typically the token endpoint.\n\nThis is particularly relevant for confidential clients, meaning clients that can protect keys or secrets in a responsible way.\n\n## Technical behavior\n\nThe selected method determines which mechanism the client must use to prove its identity. Common mechanisms include:\n\n- client secret\n- signed client assertion\n- other supported methods for client authentication\n\nWhen `private_key_jwt` is used, the client authenticates itself by sending a signed JWT assertion. The authorization server validates the signature against the client's registered public key or corresponding key material.\n\n### Why `private_key_jwt` is used\n\n`private_key_jwt` is often used when stronger client authentication is desired than a shared secret can provide. This is a good fit for integrations where:\n\n- key material can be managed securely\n- key rotation is important\n- a clearer separation is desired between client identity and shared password-based authentication\n\n## Use in OIDC clients\n\n### ID-porten\n\nFor OIDC clients against ID-porten, this is used to authenticate the client to the token endpoint after an authorization code has been received.\n\n### Ansattporten\n\nFor OIDC clients against Ansattporten, the same principle applies as for ID-porten: the client must authenticate securely when exchanging a code for a token.\n\n### Maskinporten\n\nMaskinporten is normally not an end-user-based OIDC flow, but the same principle of strong client authentication is central there as well, especially when signing with organizational keys in machine-to-machine scenarios.\n",
+    "lang": "en",
+    "path": "/en/start/oidc/authentication_method"
+  },
+  {
+    "id": "en-start-oidc-authorization_lifetime",
+    "title": "Authorization lifetime",
+    "content": "# Authorization lifetime\n\n## Purpose\n\nAuthorization lifetime describes how long an authorization or authorization-related state is considered valid.\n\nThe exact meaning may vary between implementations, but it normally concerns the lifetime of an approval, consent state, or authorization context.\n\n## Technical behavior\n\nIn an authorization flow there can be several time-limited states, for example that:\n\n- a user has given consent\n- a client has established an authorized relationship\n- an ongoing authorization process is still valid\n\nAuthorization lifetime determines how long such a state can continue before a new authorization or a new assessment is required.\n\n### Important distinction\n\nThis is not necessarily the same as:\n\n- the lifetime of an access token\n- the lifetime of a refresh token\n- the length of a sign-in session\n\n## Use in OIDC clients\n\n### ID-porten and Ansattporten\n\nThis can be relevant in clients where consent, authorization decisions, or relationships between client and user should have a defined duration.\n\n### Maskinporten\n\nIn a Maskinporten context, similar considerations will often be more closely related to delegation, access basis, and token issuance than to end-user-based consent.\n",
+    "lang": "en",
+    "path": "/en/start/oidc/authorization_lifetime"
+  },
+  {
+    "id": "en-start-oidc-backchannel_logout_uri",
+    "title": "Backchannel logout URI",
+    "content": "# Backchannel logout URI\n\n## Purpose\n\nBackchannel logout URI is the address an authorization server uses to notify a client directly that a central session has ended.\n\nThis happens server-to-server, without involving the user's browser.\n\n## Technical behavior\n\nAt logout, the authorization server can send a logout message to the client's backend. The client can then:\n\n- identify the affected local session\n- invalidate session state\n- clean up the security context\n\n### Why this is useful\n\nBackchannel logout is often more robust than browser-based logout because it does not depend on browser policies, cookies, or iframe behavior.\n\n## Use in OIDC clients\n\n### ID-porten and Ansattporten\n\nThis is relevant for clients that maintain server-side sessions and need reliable coordinated logout.\n\n### Maskinporten\n\nThis is normally not relevant in Maskinporten, since there is no interactive end-user session to coordinate.\n",
+    "lang": "en",
+    "path": "/en/start/oidc/backchannel_logout_uri"
+  },
+  {
+    "id": "en-start-oidc-frontchannel_logout_uri",
+    "title": "Frontchannel logout URI",
+    "content": "# Frontchannel logout URI\n\n## Purpose\n\nFrontchannel logout URI is the address used when logout is coordinated through the user's browser.\n\nThis makes it possible to inform the client that the central session has ended, so the local session can also be terminated.\n\n## Technical behavior\n\nWith frontchannel logout, the authorization server loads the client's registered URI in the browser. The client must then handle this in a way that clears the local session.\n\n### Limitations\n\nSince this mechanism goes through the browser, it is affected by factors such as:\n\n- cookie rules\n- browser policies\n- iframe support\n- timing and loading patterns\n\nFor that reason, frontchannel logout is often less robust than backchannel logout for clients with extensive server-side session state.\n\n## Use in OIDC clients\n\n### ID-porten and Ansattporten\n\nThis is relevant when coordinated logout is needed in browser-based end-user flows.\n\n### Maskinporten\n\nThis is normally not relevant in Maskinporten, since there is no corresponding browser-based user session.\n",
+    "lang": "en",
+    "path": "/en/start/oidc/frontchannel_logout_uri"
+  },
+  {
+    "id": "en-start-oidc-idporten-general",
+    "title": "Generelt om idporten",
+    "content": "# Generelt om idporten\nID-porten gjør innlogging til digitale tjenester trygt for innbyggere.  Se [produktsida for ID-porten på Samarbeidsportalen ](https://vg.no) for overordnet informasjon om hva ID-porten er, hva den koster og hvordan inngå bruksvilkår for å kunne ta den i bruk.\n\n## Introduksjon\n\nID-porten tilbyr følgende bruksområder til kundene:\n\n* hei\n* [**API-sikring** i kontekst av en innlogget bruker]({{site.baseurl}}/docs/idporten/oidc/oidc_auth_oauth2), populært kalt brukerstyrt datadeling.\n* [Innlogging **på vegne av andre**]({{site.baseurl}}/docs/idporten/oidc/oidc_auth_fullmakt)\n\n\n## Arkitektur\n\n\nArkitekturen for ID-porten ser slik ut:\n\nSelve ID-porten er basert på en moderne Oauth2/OIDC autorisasjonsserver fra Connect2ID.\n\n[SAML-grensesnittet]({{site.baseurl}}/docs/idporten/oidc/oidc_func_saml) er basert på en enkel proxy som oversetter kundens SAML-meldinger til OIDC-protokollen.\n\nBemyndigede ansatte eller systemer bruker [Digdirs felles selvbetjeningsløsning på web eller over API](https://docs.digdir.no/docs/Maskinporten/maskinporten_sjolvbetjening_web)\n til å registrere og vedlikeholde kundens integrasjoner.\n\nFølgende aktører inngår i løsningen:\n\n| Aktører | Beskrivelse |\n| ---- | ---- |\n| Sluttbruker | Innbygger med eID |\n| ID-porten | *ID-porten* er et tillitsanker for offentlige virksomheter. ID-porten knytter de offentlige virksomhetene og e-ID-leverandørene sammen. |\n| Kunde | Offentlig virksomhet som har akseptert bruksvilkår |\n| Tjenesteleverandør | Leverandør som leverer tjenester til en offentlig virksomhet |\n| API-tilbyder | Kunde som tilbyr APIer sikret med ID-porten. |\n| e-ID-leverandør | En av de 4 e-ID-aktørene som er tilgjengelige i ID-porten: MinID, Commfides, Buypass, BankID |\n| MinID | *MinID* er en offentlig utstedt e-ID på nivå betydelig, som tilbyr autentisering basert på engangskoder på sms eller app. |\n| Sertifikatutsteder | Sertifikatutsteder som oppfyller kravene for virksomhetssertifikater i henhold til Lov om Tillitstjenester. |\n\n| Felt | Krav |\n| ---- | ---- |\n| Filformat | .png .jpg eller .gif |\n| Størrelse | Maksimal høyde 90 pixel ... |\n| Farge | Bakgrunnsfargen på ID-porten ... |\n\n## Autentisering av sluttbruker\nID-portens tjenestetilbud for autentisering kan funksjonelt oppsummeres slik:\n\n#### Støttede protokoller\n* OpenID Connect\n* SAML2 er kun tilgjengelig for de som ikke kan benytte OpenID Connect\n\n#### Føderering / SSO\n\nDersom sluttbruker er innlogget hos tjenesteeier A og velger å gå videre til en tjenesteeier B uten å logge ut, vil bruker automatisk logges inn uten at bruker må autentisere seg på nytt.\n\n#### Sesjonsoppgradering\n\nDet er mulig for en sluttbruker å gjennomføre en autentisering på nivå 3 og seinere gå til en tjeneste som krever et høyere sikkerhetsnivå. I dette tilfellet vil ID-porten be brukeren om å oppgradere sikkerhetsnivå.\n\n#### Utenlandske brukere\n\nID-porten har støtte for at ulike kategorier av [utenlandske brukere]({{site.baseurl}}/docs/idporten/oidc/oidc_func_utanlandske_brukarar) kan logge seg på norske tjenester. \n\n\n## Brukerstyrt datadeling\n\nID-porten kan også [styre tilgang til APIer hos 3dje.part]({{site.baseurl}}/docs/idporten/oidc/oidc_auth_oauth2)\n\nAPI-tilgangen kan være innloggingsbasert (implisitt samtykke) eller brukerstyrt (eksplisitt samtykke).  I begge tilfeller  gjelder autorisasjonen kun for en enkelt innbygger, ulikt [Maskinporten]({{site.baseurl}}/docs/Maskinporten/maskinporten_overordnet) som er tiltenkt hjemmelsbasert datadeling.\n\nAPI-tilganger i ID-porten er modellert som Oauth2 scopes. For tilgangsstyrte scopes er det et organisasjonummer (=API-konsument) som blir gitt tilgang av API-tilbyder.  API-konsument må så aktivt selv registrere det tildelte scopet på en av sine integrasjoner.\n\n\n## Hvordan få tilgang til ID-porten\n\nFølg prosessen på [Samarbeidsportalen](https://samarbeid.digdir.no/id-porten/ta-i-bruk-id-porten/94) for å integrere mot ID-porten.\n\n#### Bruk selvbetjening til å registere integrasjonen din\n\nKunden bruker selvbetjeningsløsningen til å registrere påkrevd informasjon om integrasjonen sin. Dette er nærmere beskrevet under [klientregistrering]({{site.baseurl}}/docs/idporten/oidc/oidc_func_clientreg)\n\n#### Send oss logoen din\n\nKunde må sende oss egen logo som blir brukt i innloggingsbildet. Logoen for tjenesten må oppfylle følgende krav:\n\n| --- | --- |\n| Filformat | .png .jpg eller .gif |\n| Størrelse | Maksimal høyde 90 pixel og en bredde som ikke bør overskride 135 pixel. |\n| Farge | Bakgrunnsfargen på ID-porten er #f3f4f4, så logoen bør enten ha denne bakgrunnsfargen eller eventuelt ha transparent bakgrunn. |\n\n#### Test din egen løsning\n\nKunden må utføre en rekke verifikasjonstester for å bekrefte at integrasjonen oppfyller ID-portens krav.\n\n[Verifikasjonstester finner du her]({{site.baseurl}}/docs/idporten/idporten/idporten_verifikasjonstester).\n\n[Testbrukere finner du her]({{site.baseurl}}/docs/idporten/idporten/idporten_testbrukere).\n\n#### Åpne for IP-adresser\n\nDersom kunden har utgående brannmur, må det [åpnes for ID-portens IP-adresse]({{site.baseurl}}/docs/general/IP).\n\n#### Sørg for tilstrekkelig egen logging\n\nDet anbefales at kunden logger følgende informasjon om forsøk på autentisering:\n* Dato og tidspunkt\n* Hvilken handling som ble forsøkt\n* Resultatet av handlingen\n* Brukerens IP-adresse  \n* SessionIndex / sid\n* Fødselsnummer\n\nKunden sitt konkrete behov for logging opp mot personvernbetraktninger må vurderes av den enkelte kunde selv.\n\n#### Etabler gode IT-sikkerhetsrutiner i virksomheten\n\nDet er viktig at Kunden beskytter integrasjonen sin og etablerer rutiner slik at kun bemyndiget personell har tilgang til den. Se f.eks [anbefalinger for sertifikatbehandling, logging og sporing fra Veileder for virksomhetsautentisering](https://www.digdir.no/datadeling/sertifikatbehandling-logging-og-sporing/2438)\n\nKunden skal også gjøre en risikovurdering av egen løsning, her anbefaler vi [avsnittet om valg av sikkerhetsnivå fra Veileder for identifikasjon og sporbarhet i elektronisk kommunikasjon med og i offentlig sektor](https://www.digdir.no/digital-samhandling/veileder-identifikasjon-og-sporbarhet-i-elektronisk-kommunikasjon-med-og-i-offentlig-sektor/2992#veiledning_for_valg_av_sikkerhetsniv_for_identifikasjon)\n\n\n\n\n#### Sørg for sikker håndtering av nøkler\n\nDet er sentralt for sikkerheten i løsningen at tjenesteleverandør planlegger og designer prosedyrer for god nøkkelhåndtering (Key management, uansett om dette er statiske hemmeligheter (client_secret), egne-generete asymmetriske nøkler eller virksomhetssertifikat.  \n\nHvis en nøkkel kompromitteres, kan en angriper utgi seg for å være kunde i dialogen med ID-porten og dekryptere persondata sendt fra ID-porten. Slike sikkerhetsbrudd vil formodentlig i særlig grad ramme tilliten til kunden, men kan også tenkes å svekke tilliten til hele føderasjonen.\n\nFølgende punkter er det viktig at man tenker gjennom i forbindelse med nøkkelhåndtering:\n* Hvor oppbevares private nøkler, og hvordan sikres adgang til dem? For optimal beskyttelse kan en nøkkel oppbevares i kryptografisk hardware (HSM – hardware security module), men ofte benyttes krypterte filer som et billig, men mindre sikkert alternativ.\n* Hvordan håndteres backup av nøkler og hvordan gjenetableres disse ved behov?\n* Hvilket personell har tilgang til servere med private nøkler, og hvem har eventuelt tilgang til passord som kan benyttes til å dekryptere nøklene slik at de opptrer i klartekst? Kan enkeltpersoner skaffe seg adgang til private nøkler? Ligger passord for tilgang til nøkkellager ubeskyttet i konfigurasjonsfiler?\n* Hvordan håndteres fornyelse av nøkler når tilhørende sertifikater utløper? Hvis en tjenesteleverandør ikke fornyer nøkler/sertifikater innen de utløper, kan tjenester for tjenesteeier plutselig slutte å virke.\n* Hva er prosedyren om en privat nøkkel kompromitteres, eller om det er mistanke om at så har skjedd?\n* Hvordan loggføres nøkkelhåndteringsprosessen hos tjenesteleverandør?\n\nEn kunde bør analysere disse problemstillingene nøye, og utarbeide passende driftsprosedyrer som implementerer organisasjonens IT sikkerhetspolitikk.\n\n\n#### Bruk av virksomhetssertifikat\n\nVi anbefaler at kunder bruker virksomhetssertifikat til oppkobling mot ID-porten. For kunder som har mange integrasjoner, bør man heller vurdere å bruke virksomhetssertifikatet til å  automatisere integrasjonsvedlikeholdet slik at hver enkelt-integrasjon istedet bruker en assymetrisk nøkkel til oppkobling og denne blir rotert hyppig.\n\nMerk at sertifikatutstedere av virksomhetssertifikat har noe bestillingstid. Tjenesteleverandører oppfordres til å bestille sertifikat i god tid.\n\n\n## Problemer ?\n\nOm du opplever problemer med integrasjonen din: Kontakt servicedesk@digdir.no oppgi client_id og miljø og forklar problemet.",
+    "lang": "en",
+    "path": "/en/start/oidc/idporten/general"
+  },
+  {
+    "id": "en-start-oidc-idporten-integration_guide",
+    "title": "Integrasjonsguide",
+    "content": "# Integrasjonsguide\n\nID-porten tilbyr funksjonalitet for autentisering av sluttbrukere basert på autorisasjonskode-flyten, slik den er spesifisert i OpenID Connect Core 1.0 spesifikasjonen.\n\n**Dette er den foretrukne flyten for de aller fleste tjenester** som skal bruke ID-porten som autentiseringstjeneste. Det kan finnes unntak, som for eksempel [mobilapp'er](oidc_auth_app.html) eller [javascript-applikasjoner](oidc_auth_spa.html), som vil ha en litt annen måte å bruke denne flyten på.\n\n## Overordna beskrivelse av bruksområdet\n\nID-porten tilbyr autentisering av brukere til sluttbrukertjenester. Autentiseringen blir utført av en OpenID Connect provider som utsteder ID-token til den aktuelle tjenesten.\n\n```mermaid\ngraph LR\n  end_user(Sluttbruker)\n  OP(ID-porten)\n  RP(Nett-tjeneste)\n  end_user -. autentiserer seg hos .-\u003e OP\n  OP -. utsteder id_token .-\u003e RP\n  end_user -. logger inn i  .-\u003e RP\n```\n\nFølgende aktører inngår:\n\n| Aktør | Beskrivelse | Begrep OIDC |\n| -|-|-|\n| Sluttbruker | Ønsker å logge inn til en offentlig tjeneste | End User |\n| Nett-tjeneste | Sluttbruker-tjeneste tilbudt av en offentlig etat | Relying Party (RP) / Client (=klient) |\n| ID-porten | ID-porten sin autentiseringstjeneste som usteder *ID-Token* til aktuelle tjenesten| OpenID Provider (OP) |\n\n## Beskrivelse av autorisasjonskode-flyten\n\n```mermaid\nsequenceDiagram\n  Sluttbruker -\u003e\u003e Relying Party: Klikker login-knapp\n  Relying Party -\u003e\u003e Sluttbruker: Redirect med autentiseringsforespørsel\n  Sluttbruker -\u003e\u003e OpenID Provider: følg redirect...\n  note over Sluttbruker,OpenID Provider: Sluttbruker autentiserer seg (og evt. samtykker til forespurte scopes)\n  OpenID Provider -\u003e\u003e Sluttbruker: Redirect med autorisasjonscode\n  Sluttbruker -\u003e\u003e Relying Party: følg redirect...\n  Relying Party -\u003e\u003e OpenID Provider: forespørre token (/token)\n  OpenID Provider -\u003e\u003e Relying Party: id_token (evt. flere tokens)\n  note over Sluttbruker,Relying Party: Innlogget i tjenesten\n```\n\n* Flyten starter med at en sluttbruker prøver å aksessere en gitt tjeneste ( Relying Party )\n* Tjenesten krever innlogging og en redirect url til OpenID Connect provideren blir generert og returnert til sluttbrukeren. Denne redirecten representerer en [**autentiseringsforespørsel**]({{site.baseurl}}/docs/idporten/oidc/oidc_protocol_authorize.html), og har parametere som identifiserer den aktuelle tjenesten for provideren.\n* Sluttbrukers browser kommer til **autorisasjonsendepunktet** hos provideren hvor forespørselen blir validert (f.eks. gyldig tjeneste og gyldig redirect_uri tilbake til tjenesten).\n* Brukeren gjennomfører **innlogging i provideren**\n* Provideren redirect'er brukeren tilbake til tjenestens forhåndsregistrere redirect url med en **autorisasjonskode**.\n* Tjenesten bruker den mottatte autorisasjonskoden til å gjøre et direkteoppslag mot providerens [**token-endepunkt**]({{site.baseurl}}/docs/idporten/oidc/oidc_protocol_token.html). Tjenesten må autentisere seg mot token-endepunktet, såkalt *klient-autentisering* (enten med client_secret eller en signert forespørsel)\n* Dersom klient-autentiseringen var velykket, valideres den mottatte autorisasjonskoden og et **ID-token** blir returnert til tjenesten.\n* Tjenesten omsetter normalt ID-tokenet til en egen, lokal sesjon.\n* Brukeren er nå autentisert for tjenesten og ønsket handling kan utføres\n\nMerk: OpenID Connect bygger på OAuth2, og denne flyten er derfinert i OAuth2-spesifikasjonen. Siden *autentisering* ikke er et begrep i OAuth2 vil en ofte se at begrepet *autorisasjon* blir brukt selv om man egentlig snakker om *autentisering*\n\n\n## Sesjonshåndtering\n\nMerk: Kunde og ID-porten holder egne sesjoner mot sluttbruker som ikke er avhengig av hverandre. Men Digitaliseringsdirektoratet anbefaler at kundene bruker samme sesjonstider som ID-porten.\n\n\n### Levetid for SSO-sesjonen i ID-porten\n\nI ID-porten måles maksimum sesjonstid for en brukers SSO-sesjon og denne settes til 120 minutter fra første autentisering.\n\nVed inaktivitet over 30 minutter, vil SSO-sesjonen utløpe.  Inaktivet måles som tiden mellom to autentiseringsforespørsler mot ID-porten.\n\nMerk at ved passivt utløp av sesjon så vil det ikke bli sendt noen kall til kundens tjeneste.\n\nMerk: id_tokenet returnert fra ID-porten vil inneholde en \"expire (exp)\" verdi. Denne verdien angir kun levetid for selve tokenet, dvs. en klient skal ikke akseptere et id_token etter at det utløpt. Denne verdien er ikke koblet mot den SSO-sesjonen hos ID-porten og gir ingen indikasjon på levetid på denne.\n\n### Levetid for kundens lokale sesjon\n\nI en føderasjon skal medlemmene konfigurere systemene slik at sesjoner utløper ved inaktivitet etter høyst 30 minutter.\n\nDet er valgfritt om timeout-perioden nullstilles hver gang brukerens nettleser forespør en av kundens tjeneste, eller om den er uavhengig av brukeraktivitet (fast timeout periode).\n\nEtter lokal timeout hos en kunde, skal brukerens nettleser ved neste http-forespørsel sendes over til ID-porten med en autentiseringsforespørsel.\n\nDet må bemerkes at lokal timeout hos en kunde ikke nødvendigvis medfører at brukeren blir tvunget til å logge på ID-porten. Hvis brukeren har en aktiv SSO-sesjon hos ID-porten, kan denne svare på forespørselen fra kunde uten brukerdialog (dvs. foreta single sign-on). Brukeren vil dermed ikke oppdage at sesjonen blir fornyet (bortsett fra at hans nettleser muligens ”blinker” et kort øyeblikk).\n\n### Tvungen re-autentisering\n\nHvis en tjenesteleverandør av sikkerhetsmessige grunner vil sikre seg at brukeren blir tvunget til aktiv pålogging i ID-porten, kan man sette parameteren prompt=login i autentiseringsforespørselen til ID-porten.  \n\nDet er også mulig å konfigurere tjenesten sin slik at den ikke deltar i felles SSO-sesjon (se [Isolert SSO-sesjon]({{site.baseurl}}/docs/idporten/oidc/oidc_func_nosso.html)).\n\n\n### Krav til utlogging\n\nID-porten tilbyr single signon-funksjonalitet (SSO) mellom alle integrerte tjenester.  **Derfor må alle tjenester også implementere støtte for single logout (SLO).**\n\n\n**En feilkonfigurert logout-håndtering hos én kunde kan ødelegge for utlogging hos andre kunder, og gjøre innbygger sårbar for angrep.**\n\nKlienten må håndtere to forskjellige utloggings-scenarier:\n\n1. **Brukeren logger ut fra din tjeneste:**  Du må redirecte brukeren til /endsession-endepunktet til ID-porten.  ID-porten sørger for å logge brukeren ut av alle andre tjenester, og redirecter til slutt brukeren tilbake til deg.\n\n2. **Brukeren logger ut fra annen tjeneste:** Du vil motta en front_channel_logout-melding med en sesjonsidentifikator `sid` som du tidligere har mottatt i id_token. Basert på denne må du finne lokal brukersesjon og invalidere denne.\n\n\n[Se full dokumentasjon om utlogging her]({{site.baseurl}}/docs/idporten/oidc/oidc_func_sso).\n\n\n## 1: Autentiseringsforespørsel til autorisasjons-endepunktet\n\nTjenesten/klienten sender en autentiseringsforespørsel ved å redirecte sluttbrukeren til autorisasjonsendepunktet.\n\nSe [detaljert dokumentasjon for autorisasjonsendepunktet]({{site.baseurl}}/docs/idporten/oidc/oidc_protocol_authorize) for valgmuligheter.\n\nKlienten må være forhåndsregistrert i ID-porten, se [klient-registrering]({{site.baseurl}}/docs/idporten/oidc/oidc_func_clientreg).\n\n\n### Eksempel på forespørsel\n\n```\n\nGET https://login.idporten.no/authorize?\n\n  client_id=min_tjeneste\u0026\n  redirect_uri=https%3A%2F%2Fmin.tjeneste.no%2Flogin_callback\u0026\n\n  scope=openid+profile\u0026\n  acr_values=idporten-loa-substantial\u0026\n  response_type=code\u0026\n  ui_locales=nb\u0026\n\n  state=sV-423vokts9_CZdO9KZSV9xb35mlgzj_7BPTt-_khQ\u0026\n  nonce=S6tRrJ3tWsilRZl7hqySoORosHDDq4l6du3dxDhXoWc\u0026\n  code_challenge=HC9NRzz4QUaVMvl2TUYrWg_L54PBleKON4hapcIOydk\n  code_challenge_method=S256\u0026\n\n```\n\nAlle tjenester må bruke [PKCE]({{site.baseurl}}/docs/idporten/oidc/oidc_func_pkce), og blir sterkt anbefalt å bruke state og nonce i kallet.\n\nFor tjenester med høye krav til sikkerhet bør en i tillegg vurdere å bruke [PAR]({{site.baseurl}}/docs/idporten/oidc/oidc_protocol_par) til å første POSTe autentiseringsparametrene direkte til ID-porten før en redirecter, slik at disse parametrene ikke blir eksponert for manipulasjon av brukers browser.\n\n## 2: Bruker autentiserer seg\n\nBruker vil så autentisere seg mot ID-porten.  ID-portens språk prioriteres slik:\n\n- Bokmål er standardspråk dersom ingenting er oppgitt\n- Dersom klient har oppgitt `ui_locales`, så vil dette språket bli brukt\n- Dersom cookien IDPORTEN_SELECTED_LANGUAGE-cookien er satt, vil dette overstyre andre valg. Cookien blir satt kun for brukere som aktiv endrer språk i ID-portens GUI.\n\n## 3: Redirect tilbake til tjenesten\n\nEtter at brukeren har logget inn vil det sendes en redirect tilbake til klienten til den forhåndsregistrerte `redirect_uri`.  Redirecten vil vil inneholde et autorisasjonskode-parameter `code` som  brukes til oppslag for å hente tokens.  Koden er base64-enkoda og URL-safe.\n\n\n\n### Eksempel på respons: {#authresponse}\n\n```\nGET https://min.tjeneste.no/login_callback?code=1JzjKYcPh4MIPP9YWxRfL-IivWblfKdiRLJkZtJFMT0\u0026state=min_egendefinerte_state_verdi\n```\nI testmiljø tillater vi redirect tilbake til localhost.\n\n## 4: Utstedelse av token fra token-endepunktet\n\nToken-endepunktet brukes for utstedelse av tokens.\n\n\nBruk av endepunktet varierer litt med hvilken klient-autentiseringsmetode som benyttes. Følgende autentiseringsmetoder fra [OIDC kap. 9](http://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication) støttes:\n\n* **client_secret_basic** / **client_secret_post** - Klientautentisering basert på client_secret\n* **private_key_jwt** - Klientautentisering basert på JWT'er signert med virksomhetssertifikater\n\nSistnevnte metode er anbefalt for klienter med høye krav til sikkerhet.\n\n##### Eksempel på forespørsel:\n\n\n```\nPOST /token\nContent-Type: application/x-www-form-urlencoded\nAuthorization: Basic bWluX3RqZW5lc3RlOnBhc3N3b3Jk\n\ngrant_type=authorization_code\u0026\n  redirect_uri=https%3A%2F%2Fmin.tjeneste.no%2Flogin_callback\u0026\n  code=1JzjKYcPh4MIPP9YWxRfL-IivWblfKdiRLJkZtJFMT0%3D\u0026\n  code_verifier=gEVARFlOi5LNYfVGSMHvhZCXoG_TPzdmXQQGqzKJkz0\n```\n\nSe [detaljert dokumentasjon for token-endepunktet]({{site.baseurl}}/docs/idporten/oidc/oidc_protocol_token) for alle valgmuligheter.  \n\nDersom forespørselen blir validert som gyldig, vil det returneres et eller flere token:\n\n* **id_token**: Autentiseringsbevis,  \"hvem brukeren er\"\n* **access_token**: Tilgangs-token, forteller \"hva brukeren kan få tilgang til\"\n* **refresh_token**: Brukes av klienten til å fornye access_token uten brukerinteraksjon (så lenge som autorisasjonen er gyldig)\n\n\n```\n{\n  \"access_token\" : \"eyJ4NWMiOlsiTUlJQ3NqQ0NBWnFnQXdJQkFnSUVZbSt1L3pBTkJna3Foa2lHOXcwQkFRc0ZBREFiTVJrd0Z3WURWUVFEREJCcFpIQnZjblJsYmkxemVYTjBaWE4wTUI0WERUSXlNRFV3TWpFd01UUXlNMW9YRFRJek1EVXdNakV3TVRReU0xb3dHekVaTUJjR0ExVUVBd3dRYVdSd2IzSjBaVzR0YzNsemRHVnpkRENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFMZTVuN3lXNFh2Y1J0d3RMazFVUEllakN5U3RmMUQ1akhCNnNQaUpSK3haR3JmejR4dXJJRlA4ekorbnI1OXRoblQrdVpuaFQwNzNwVUlNdkJsRCt1bjFiTWxENm9TZjJ6UTZpWmhFQ0V3bTBxdUk3RHpRcW93dGxGSUdxUTgzQ2Y4NEZjZDBVbVJiT0ZOUnJicDg3QkY2dkZzL3JsM0x0RHo4dXlWbVFXaGhubS9jR3F5ZGkxQWhXWi92YTVYdzR1SFoxYVNDOTgzK1EySllkSFZYRU45SXV4bWIvZVdlVmhzTVRXQ0FPbU4xMklvWVZHODFFOXMvMzJQZy82cFEyMkFNWjRqZzgwdGVMZTBZeWZGS2ppbUtWQnJkRTBnUXJmWThnemlBR3kwYnhhQTRBNTlneUZmcldKRTNhOE5tSHZxTHhhTE4yQ0hzcXhsQVhuRkNZd2NDQXdFQUFUQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFqY3NOVk43T0R2K1VDdlhGSVdnck0xQll4TGR0QTkvZ0QvU3ZzcGdIcjY5dUlPcHRxVTY1cklrMmllMDhPcjZRZXpTVnVRdkJ5a1U3cXgrZVFmV1N1OG1rWDRZa0VWcXBzYnh6Q0hneWEvTXJINzd2ZmV2UlhNRkk1QUlaVDU4TDdjSGovOWFYelpsRXhEVGo5bE5makFjcktCNm5kRS9rZVErUkUrdGdvM0c1Q0srVktINkJaMFJtOXQySDZBKzZxbEFZS0FCTFZ2dGFjekdKU3BQNUxrcGw0T1BscE5pY2M3MDVuQnpzYnBvMGd1WThNQjdqQnlKVWJRcXd6MCtkd3NNMWNQNkNTbFNUc3FNUWJaVjAzd1lCT014Si93dUt1Nnlyc0ZUV21sUi8rSGhvU3VkNUVBSnJHSGwvbnR6RmNBTExIcUk0dG92UFRkcGJTTVlnOXc9PSJdLCJraWQiOiJ1clFQU1pDU1hYSkhiTm9XMFZFbmtCcWJOZDFDeXdmT1RJZGNxQlRISk9FIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJFUklGdnBEN3BNNmo2WHZybnowbWw1M1YtTF9XNVpEU3Mza1lNczZkVFZjIiwiYWNyIjoiaWRwb3J0ZW4tbG9hLXN1YnN0YW50aWFsIiwic2NvcGUiOiJvcGVuaWQgcHJvZmlsZSIsImlzcyI6Imh0dHBzOi8vaWRwb3J0ZW4uZGV2IiwiY2xpZW50X2FtciI6ImNsaWVudF9zZWNyZXRfYmFzaWMiLCJwaWQiOiIyMTg3OTQ5ODAxMiIsImV4cCI6MTY3ODM3NjA5MiwiaWF0IjoxNjc4Mzc1NDkyLCJqdGkiOiJVUHc4YTYtdUtHbyIsImNsaWVudF9pZCI6ImRlbW9jbGllbnRfaWRwb3J0ZW5fc3lzdGVzdCIsImNvbnN1bWVyIjp7ImF1dGhvcml0eSI6ImlzbzY1MjMtYWN0b3JpZC11cGlzIiwiSUQiOiIwMTkyOjk5MTgyNTgyNyJ9fQ.CD2j7-F3GCggX0Owh_dm-hZzLxq8RIj2Ry51B2-KrIBD4QzmsHQ9KrsNgtL9YFBLajcUqEm2QPTniTo8_JZqP_DyjiaOFV0mati84ifoIEziuHH9MXb0MiFtO0hlpFdic-i_zoiO7IBal0htCkt2kTrSKokYMp2U4dnuMkw32aK45HCHt2h1P2HWuI4EBk_KAFsOEdO2wCAJHS9jH4WTf7Q-Xx1TyzEbnsb8LuvJ8vOxKCzHgPkR5LCgdXq7gYUOxSuORYa_9MEhAnLi0riRTAMxngB3pk8ZvrrJTscC0zE0a5-xjqA0BJ9bqaHrobP13LKXRR-ol1WHTb4QHH1-qg\",\n  \"refresh_token\" : \"eyJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiYWxnIjoiZGlyIn0..WES9oML4Je5S3qxXSPZOXg.5dJtItCTk7920ihGtylDL3ytHmA-yjaN1F0FDa2zn560A6RPga5R9BUYDEZDCVzAHtaewsdg4W_b79daTjVinTY5wqSfi5fb4JnwATx1ecxu2Pjo4QronnfZrBSD3ezCrvgcxtAFJ1w9uJymYhCbWc8rqL7X7H5wdHmNTbUzaT_WGL1Ymvqe4KDgF2XLuvpxs81sWJtgW5P1vaTrf58sA_oDUJZC9qZHNrIgW4JNp7E9au0cX5H0kF1wrGnkgiALAPVYqRJsd9IDc0kLnUKvtVKKRAja098CgpmPRSs61KVz-nPmtNvVMZJXmqsQnvW9qimkxPtnTUnxyFtKiHdB-wc2Q8Gv5bUC3w7BZR5-F_DfCVzcxlraay2fSN1gWpSdR7nFqsJI4TQNBUcPEKvV3wKxdAcQgrxgYtP0jQnZ14NvaNzO5eVE1DILXznWICZ5LGpzXb7vd7Sfk23kXX7xs7beGQ5dqRnnK9hH5NEBsW1rbDOlbPES5fDrWII0n9i9-aKWBVBbi34qkQL-nKtl-WxH1bJD2FhPZw3LEfuKk_XUDkMFGfP2uoFtf7KUjb7pfqFf9d8R_ZswFH6jYDd-ohzS6p-04GC71Sw8uWCpTraYtNNkOhkqVapOKN-K2U_6oquqqJXInrXZ0Ng-PL4UOdA75I_ccGTtKd-9jjnzwoxF3wDLRy0OwwkHPdvMSYo-KEK4fBcaOFQXCu7wU-IbzF96vOESDtPi4Xho2iuTsb-NSl2WpW4P7rVxFhJsjH0g7a64278vgYx5b9nvpQkjnh-42B-xgvcQsfATnW4cffa4xGQ-QpnxI2U9FRSWBcI_7vdkdVPpilum39ub-8Qv5V-cDje6cuOLj-izJDhHtT8GisRxOAzUlkBkkonmMyxgJaCR4L0QjSBpQpemD44sKQxIOYFNjT7AcAOR5EsHwiABzAgiJIe1erZpno8Zrbh2RWg7mUs4__Kvhzpxr8hjqbldUJI4okhg9SrWpFqoJoa7syNKv_lfm8twCDGAUmfRlk8TTdXrkhEr1bXpS3Q54kLtfVbKfkGWdHVanv1aIeTFCGbN2PXGk29Q2B6yAvyVoHFLm7gniZJKmZByYDtCvF5qwbVkmPi3vNOOQma9kOo_y8Gx--FVoZ0l5ST2MJx0T3FadspcR75HCP5WEARyktuYlJG2PxvPtNBNf7E6Tak3yS8p3pQzyeeVwYgNFkGpMdmax7aCAQEAm-5x7uXmX_1b6S7SX94uqh4pxYWvy0eLHmD3mtmfzfSQBgLEr7VSZVskM8MPHsUrO4wIhwXWjyV_NTRN9Jeofb3Zvmw1jsqK3vxVdHhc6iZwpRrbyWkQdb-MN9uv3cR4Dki1yXo3p50xL21BZMJB1SH_eHwTpWMJhZ1MjMV2VTRooJ3Nh4MiMMkZ7UTRPjLsI9UwsaonzexM1ApE7eT2UxxGUZNUd5JE0--7WDcowp45E0Hb2r6EFH2wLrFOAPuzhsYG3d88x_-VySUhvnzGV8C-9bjGZKoH1cdvq_ToqejytTpYzZ9QwOSwaPIypOauSGX6W7ruCKy9YbZgIngD8z0uxlXmQzm8v6jIVAZmLktVjHfY5gUm94hNF7HckDahlmtz2izYhSaVZA3vsaNPDDTmqNAalyD2zuelD-084_UdoKBRoSBFf1WaDBO1c0-SBqeBDFfM45EaYsAUZaYb133XM78W-MYA0xLGGQ1yLsqB7GQjlPRIK9HtO9YfpXIeSJ2culmPIopSBwkrvhCFOi5lZdkj2_Q.h25pAv8_-iKYQgxPtcF5iQ\",\n  \"scope\" : \"openid profile\",\n  \"id_token\" : \"eyJ4NWMiOlsiTUlJQ3NqQ0NBWnFnQXdJQkFnSUVZbSt1L3pBTkJna3Foa2lHOXcwQkFRc0ZBREFiTVJrd0Z3WURWUVFEREJCcFpIQnZjblJsYmkxemVYTjBaWE4wTUI0WERUSXlNRFV3TWpFd01UUXlNMW9YRFRJek1EVXdNakV3TVRReU0xb3dHekVaTUJjR0ExVUVBd3dRYVdSd2IzSjBaVzR0YzNsemRHVnpkRENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFMZTVuN3lXNFh2Y1J0d3RMazFVUEllakN5U3RmMUQ1akhCNnNQaUpSK3haR3JmejR4dXJJRlA4ekorbnI1OXRoblQrdVpuaFQwNzNwVUlNdkJsRCt1bjFiTWxENm9TZjJ6UTZpWmhFQ0V3bTBxdUk3RHpRcW93dGxGSUdxUTgzQ2Y4NEZjZDBVbVJiT0ZOUnJicDg3QkY2dkZzL3JsM0x0RHo4dXlWbVFXaGhubS9jR3F5ZGkxQWhXWi92YTVYdzR1SFoxYVNDOTgzK1EySllkSFZYRU45SXV4bWIvZVdlVmhzTVRXQ0FPbU4xMklvWVZHODFFOXMvMzJQZy82cFEyMkFNWjRqZzgwdGVMZTBZeWZGS2ppbUtWQnJkRTBnUXJmWThnemlBR3kwYnhhQTRBNTlneUZmcldKRTNhOE5tSHZxTHhhTE4yQ0hzcXhsQVhuRkNZd2NDQXdFQUFUQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFqY3NOVk43T0R2K1VDdlhGSVdnck0xQll4TGR0QTkvZ0QvU3ZzcGdIcjY5dUlPcHRxVTY1cklrMmllMDhPcjZRZXpTVnVRdkJ5a1U3cXgrZVFmV1N1OG1rWDRZa0VWcXBzYnh6Q0hneWEvTXJINzd2ZmV2UlhNRkk1QUlaVDU4TDdjSGovOWFYelpsRXhEVGo5bE5makFjcktCNm5kRS9rZVErUkUrdGdvM0c1Q0srVktINkJaMFJtOXQySDZBKzZxbEFZS0FCTFZ2dGFjekdKU3BQNUxrcGw0T1BscE5pY2M3MDVuQnpzYnBvMGd1WThNQjdqQnlKVWJRcXd6MCtkd3NNMWNQNkNTbFNUc3FNUWJaVjAzd1lCT014Si93dUt1Nnlyc0ZUV21sUi8rSGhvU3VkNUVBSnJHSGwvbnR6RmNBTExIcUk0dG92UFRkcGJTTVlnOXc9PSJdLCJraWQiOiJ1clFQU1pDU1hYSkhiTm9XMFZFbmtCcWJOZDFDeXdmT1RJZGNxQlRISk9FIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJFUklGdnBEN3BNNmo2WHZybnowbWw1M1YtTF9XNVpEU3Mza1lNczZkVFZjIiwiYW1yIjpbIlRlc3RJRCJdLCJpc3MiOiJodHRwczovL2lkcG9ydGVuLmRldiIsInBpZCI6IjIxODc5NDk4MDEyIiwibG9jYWxlIjoibmIiLCJub25jZSI6IlM2dFJySjN0V3NpbFJabDdocXlTb09Sb3NIRERxNGw2ZHUzZHhEaFhvV2MiLCJzaWQiOiJpWlpicC1hX3dTVWZmT1N3bW4xV2VvOUVvYXV5eVFMNnBxdjBfLThiUkhrIiwiYXVkIjoiZGVtb2NsaWVudF9pZHBvcnRlbl9zeXN0ZXN0IiwiYWNyIjoiaWRwb3J0ZW4tbG9hLXN1YnN0YW50aWFsIiwiYXV0aF90aW1lIjoxNjc4Mzc1NDkxLCJleHAiOjE2NzgzNzU2MTIsImlhdCI6MTY3ODM3NTQ5MiwianRpIjoicHJrUW91Y1FKZjgifQ.rRaBSFextSifr-VsClfaJzHW9Eb5eg_BKw5OLf6MOvAU8S4C1sqz-R0y7eCPk4zPbj6H2ZLB5MVbFEa-vy1Io9COqU9-9Uh1gi0Qg58ECoMjb5tXyWA5_Vg9IiGhiAC3EfqF5L1gyMd84KNbkNF22Bx-atI1IZq2hsW6FkfK5fn2tWHfYdofOL8oiQRlwU78JaoMxRq_buc3jKf8pc0fB08VGT-RDJKlEr6ha7Z3K5Q7i-EUwLmlqRoW1Hi-PQhSgPYEVjSJ1FcB1V-R24AGCu6NF6Ax3F24Su4WLw_cEWYDu6FAbefvQrg6lBVdpN029-O1OZlLduembjOB96UgMg\",\n  \"token_type\" : \"Bearer\",\n  \"expires_in\" : 600\n}\n```\n\n\n\n### id_token\n\nid_tokenet inneholder identiteten til den autentiserte brukeren - det forteller det hvem brukeren er, men ikke hvilke tilganger brukeren har.\n\nNormal bruker tjenesten id_tokenet kun til å opprette en egen, lokal sesjon.  Id_tokenet har derfor en ganske kort gyldighetsperiode.\n\n#### Eksempel:\n```\n{\n  \"sub\": \"ERIFvpD7pM6j6Xvrnz0ml53V-L_W5ZDSs3kYMs6dTVc\",\n  \"amr\": [\n    \"TestID\"\n  ],\n  \"iss\": \"https://idporten.no\",\n  \"pid\": \"21879498012\",\n  \"locale\": \"nb\",\n  \"nonce\": \"S6tRrJ3tWsilRZl7hqySoORosHDDq4l6du3dxDhXoWc\",\n  \"sid\": \"iZZbp-a_wSUffOSwmn1Weo9EoauyyQL6pqv0_-8bRHk\",\n  \"aud\": \"min_tjeneste\",\n  \"acr\": \"idporten-loa-substantial\",\n  \"auth_time\": 1678375491,\n  \"exp\": 1678375612,\n  \"iat\": 1678375492,\n  \"jti\": \"prkQoucQJf8\"\n}\n```\n\n\n**Korrekt validering av id_token** av klienten er kritisk for sikkerheten i løsningen. Det er spesielt viktig å validere at faktisk brukt sikkerhetsnivå `acr` er ihenhold til forespurt nivå.\n\nTjenesteleverandører som tar i bruk tjenesten må utføre validering i henhold til kapittel [3.1.3.7 - ID Token Validation i OpenID Connect Core 1.0 spesifikasjonen](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation).\n\n[Klikk her for full dokumentasjon av id_token i ID-porten]({{site.baseurl}}/docs/idporten/oidc/oidc_protocol_id_token).\n\n\n\n### access_token\n\nAccess_tokenet (tilgangstoken) gir klienten [tilgang til APIer hos tredjepart]({{site.baseurl}}/docs/idporten/oidc/oidc_auth_oauth2) på vegne av den autentiserte brukeren.  \n\nLevetiden på aksess_tokenet er som oftest relativt kort (typisk 120 sekunder). Dersom tokenet er utløpt, kan klienten forespørre nytt acess_token ved å bruke refresh_tokenet. Det gjennomføres da en klient-autentisering, for å sikre at tokens ikke blir utlevert til feil part.\n\nLevetider kan også tilpasses per klient. Men merk at dette kan overstyres av API-tilbyder alt etter [hvilke oauth2 scopes]({{site.baseurl}}/docs/idporten/oidc/oidc_protocol_scope) som er i tokenet. \n\nDet er viktig å være klar over at access_token+refresh_token er **uavhengig** av innlogginga og tilhørende SSO-sesjon i ID-porten.  Selv om brukeren gjennomfører en utlogging, eller sso-sesjonen timer ut, så vil normalt autorisasjonen med tilhørende access_token og refresh_token være gyldige fram til deres levetider utløper.   \n\nMerk til slutt at en enkelt bruker bare kan ha en autorisasjon mot samme klient om gangen. Dersom klienten har en gyldig autorisasjon med gitte scopes, og så utfører en ny autorisasjon med andre scopes, så vil ny access_token kun inneholde scopene fra den nyeste autorisasjonen. ID-porten \"husker\" altså ikke samtykkede scopes over flere autorisasjoner. \n\n[Klikk her for full dokumentasjon av access_token-formatet til ID-porten]({{site.baseurl}}/docs/idporten/oidc/oidc_protocol_access_token).\n\n\n\n## 5: Userinfo-endepunkt\n\nVed å forespørre scopet *profile* vil klienttjenesten sammen med id tokenet også få utstedt et access_token (og evnt. refresh_token) som kan benyttes mot providerens userinfo-endepunkt.\n\nDette endepunktet kan i henhold til standarden benyttes for å hente ytterligere data om brukeren enn det som blir eksponert via ID tokenet. Da ID-porten generelt har lite data om sluttbrukeren har dette endepunktet begrenset verdi i de fleste tilfeller. Personnummer og valgt språk under innlogging er de\ndataene som vil bli eksponert her.\n\n\n```\nGET https://\u003c\u003cmiljø\u003e\u003e/idporten-oidc-provider/userinfo\nAuthorization: Bearer eyJA...\n\nRespons:\n{\n  \"sub\" : \"NR8vTTPrM3T7rWf8dXxeWLZpxEMsug4E7pxqJuh9wIM=\",\n  \"pid\" : \"23079421936\",\n  \"locale\" : \"nb\"\n}\n```\n\n\n## 6: Kontaktopplysninger fra Kontakt- og Reservasjonsregisteret\n\nKontakt-opplysninger knyttet til innlogget bruker, er [tilgjengelig på et eget endepunkt]({{site.baseurl}}/docs/Kontaktregisteret/Brukerspesifikt-oppslag_rest) dersom access_token inneholder `krr:user/kontaktinformasjon.read`-scopet.\n\n\n\n## Om OpenID Connect\n\nOpenID Connect er en protokoll for autentisering basert på OAuth2. Se [http://openid.net/connect/faq/](http://openid.net/connect/faq/) for mer informasjon.\n\nDe implementerte tjenestene bygger på (deler av) følgende standarder og spesifikasjoner:\n\n* OpenID Connect Core 1.0 - [http://openid.net/specs/openid-connect-core-1_0.html](http://openid.net/specs/openid-connect-core-1_0.html)\n* OpenID Connect Discovery\n[http://openid.net/specs/openid-connect-discovery-1_0.html](http://openid.net/specs/openid-connect-discovery-1_0.html)\n\n* OpenID Connect Session Management\n[http://openid.net/specs/openid-connect-session-1_0.html](http://openid.net/specs/openid-connect-session-1_0.html)\n* OpenID Connect Front-Channel Logout\n[http://openid.net/specs/openid-connect-frontchannel-1_0.html](http://openid.net/specs/openid-connect-frontchannel-1_0.html)\n* OAuth 2.0 Form Post Response Mode\n[http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html](http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html)\n* OAuth 2.0 Token Introspection\n[https://tools.ietf.org/html/rfc7662](https://tools.ietf.org/html/rfc7662)\n* Proof Key for Code Exchange by OAuth Public Clients\n[https://tools.ietf.org/html/rfc7636](https://tools.ietf.org/html/rfc7636)\n\n* IETF RFC6749 The OAuth 2.0 Authorization Framework - [https://tools.ietf.org/html/rfc6749](https://tools.ietf.org/html/rfc6749)\n* IETF RFC7523 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants - [https://tools.ietf.org/html/rfc7523](https://tools.ietf.org/html/rfc7523)",
+    "lang": "en",
+    "path": "/en/start/oidc/idporten/integration_guide"
+  },
+  {
+    "id": "en-start-oidc-maskinporten-general",
+    "title": "Generelt om maskinporten",
+    "content": "# Generelt om maskinporten\n\n## Overordnet arkitekturbeskrivelse\n\nMaskinporten er en tjeneste som tilbyr en enkel modell for API-sikring basert på OAuth2 protokollen og bruk av JWT-bearer grants, inspirert av [Google sine system-kontoer](https://developers.google.com/identity/protocols/OAuth2ServiceAccount).\n\nMaskinporten lar API-tilbydere definere tilganger til sine API, modellert som scopes, basert på konsumenten sine organisasjonsnummer.\nDette kan gjøres via Maskinporten sine selvbetjeningsAPI eller webløsning.\n\n```mermaid\ngraph LR\n  subgraph API-tilbyder\n    API[API manager]\n  end\n  subgraph Digdir\n    MP[Maskinporten]\n  end\n\n  API --\u003e|Gir tilgang til scope for API-konsument|MP\n\n```\n\nForutsatt at de riktige tilgangene er gitt, kan API-konsumenter nå opprette sine API-klientregistreringer med de tildelte scopene:\n\n```mermaid\ngraph LR\nsubgraph Digdir\n  MP[Maskinporten]\nend\n  subgraph API-konsument\n    client[Administrasjonsklient]\n  end\n\n  client --\u003e|opprette / endre klient med tildelte scopes |MP\n  MP --\u003e|ny / endret klientregistrering|client\n```\n\nNår klientene er registrert kan disse brukes for å få tildelt token og gjennomføre api-kallene.\n\n```mermaid\ngraph LR\n  subgraph API-tilbyder\n    API\n  end\n  subgraph Digdir\n    Maskinporten[Maskinporten]\n  end\n  subgraph API-konsument\n     ny[Klient]\n  end\n  Maskinporten --\u003e|2.utsteder token med tildelt scope|ny\n  ny --\u003e|1.forspør tilgang til scope|Maskinporten\n  ny --\u003e|3.bruker token mot|API\n```\n\nAPI-konsumenter kan selv administrere sine klientkonfigurasjoner og registrere disse med tildelte scopes fra tilbyderene.\n\nAPI-tilbydere og konsumenter kan bruke denne tjenesten for å styre tilgang i de tilfellene der informasjonsverdiene APIet tilbyr er regulert av lovhjemmel, og ikke krever samtykke av brukeren.\n\nBruk av Maskinporten krever at begge aktørene bruker Maskinporten sin selvbetjeningsfunksjonalitet, enten gjennom webløsningen eller selvbetjeningsAPIet.",
+    "lang": "en",
+    "path": "/en/start/oidc/maskinporten/general"
+  },
+  {
+    "id": "en-start-oidc-maskinporten-integration_guide",
+    "title": "Integrasjonsguide",
+    "content": "# Integrasjonsguide\n\nFor maskinporten \n",
+    "lang": "en",
+    "path": "/en/start/oidc/maskinporten/integration_guide"
+  },
+  {
+    "id": "en-start-oidc-on_behalf_of",
+    "title": "OnBehalfOf",
+    "content": "# OnBehalfOf\n\n## Om funksjonaliteten\n\n*Onbehalfof* gjer det mogleg for tjenesteleverandørar å tilby tjenester til ulike kunder over same integrasjon.\n\n* Gir mulighet til å ha ulike navn, logo og tilbake-url\n* Statistikk / fakturering går til riktig tjenesteeier\n\nMerk at en onbehalfof-integrasjon IKKE gir tilgang til scopes som egen kunde har fått tilgang til.\n\n## Bruk\n\nAutentiseringsrequest må inneholde ekstra parameter ```onbehalfof```:\n\n```\nhttps:/…./authorize?client_id=test_client\u0026onbehalfof=leikanger_kommune\u0026...\n```\n\nReturnert ID-token vil då innehalde eit nytt claim ```client_onbehalfof```:\n\n```\n{\n  …\n  aud: \"test_client\"\n  aud_onbehalfof: \"leikanger_kommune\"\n  …\n}\n```\n\nKlient må validere at returnert \"client_onbehalfof\" stemmer overens med forespurt onbehalfof-verdi.\n\nKombinasjonen av client og client_onbehalfof må vere pre-registrert hjå ID-porten.",
+    "lang": "en",
+    "path": "/en/start/oidc/on_behalf_of"
+  },
+  {
+    "id": "en-start-oidc-pkce",
+    "title": "PKCE",
+    "content": "# PKCE\n\n## About the functionality\n\nPKCE, Proof Key for Code Exchange, (pronounced \"pixy\") is a method that protects public clients using the authorization code flow, typically mobile apps, against theft of the authorization code, and also against CSRF attacks.\n\nPKCE is defined in [RFC7636](https://tools.ietf.org/html/rfc7636), and we refer to that specification for detailed documentation of the functionality.\n\nThe method is based on the following steps:\n\n1. The client generates a secret `code_verifier` for each login.\n2. In the `/authorize` call, a hashed version of the secret, `code_challenge`, is sent as part of the request.\n3. In the `/token` call, `code_verifier` must be sent. A potential attacker who has intercepted the authorization code does not know the secret and will therefore not receive tokens.\n\nWe only support `code_challenge_method=S256`.\n\n**Note that `code_verifier` must be at least 43 characters long, and no longer than 128.**\n\nIf `code_verifier` is `xyo94uhy3zKvgB0NJwLms86SwcjtWviEOpkBnGgaLlo`, the calculated `code_challenge` becomes `b7elB7ZyxIXgFyvBznKvxl7wOB-H17Pz0a3B62NIMFI`. The code challenge must not use padding.\n\n[Here is a tool for calculating challenges:](https://gist.github.com/tonyxu-io/21eb57ab2a4aeb2a3ee10f77542abe64)\n\n### PKCE is generally required\n\nUpdated security recommendations from the IETF are clear that using PKCE is best practice, and it is required by the OAuth 2.1 standard.\n\nTherefore, all clients in ID-porten must use PKCE. As a general rule, ID-porten will reject the authentication request if PKCE is not used.\n\nHowever, for customers with less mature integration software that does not yet support PKCE, it is possible to use [self-service]({{site.baseurl}}/docs/idporten/oidc/oidc_func_clientreg.html) to **downgrade** the client so it bypasses ID-porten's enforced PKCE validation. This is done by setting `code_challenge_method` on the client to `none`.\n",
+    "lang": "en",
+    "path": "/en/start/oidc/pkce"
+  },
+  {
+    "id": "en-start-oidc-post_logout_redirect_uri",
+    "title": "Post logout redirect URIs",
+    "content": "# Post logout redirect URIs\n\n## Purpose\n\nPost logout redirect URIs are addresses the user can be sent to after a central logout process has completed.\n\nThis is used to provide a controlled end to the user journey after logout.\n\n## Technical behavior\n\nWhen the user logs out at the authorization server, they can be redirected back to a registered address at the client. This address can be used to:\n\n- show logout confirmation\n- offer a new login\n- send the user to a front page or another defined landing page\n\n### Security\n\nAs with redirect URIs, these addresses must also be pre-registered in order to avoid open redirects and unwanted forwarding.\n\n## Use in OIDC clients\n\n### ID-porten and Ansattporten\n\nThis is relevant for clients that participate in central logout and want to control where the user ends up after logging out.\n\n### Maskinporten\n\nThis is normally not relevant in Maskinporten, since there is no end-user-based browser session to terminate.\n",
+    "lang": "en",
+    "path": "/en/start/oidc/post_logout_redirect_uri"
+  },
+  {
+    "id": "en-start-oidc-redirect_uri",
+    "title": "Redirect URIs",
+    "content": "# Redirect URIs\n\n## Purpose\n\nRedirect URIs are addresses the authorization server is allowed to send the user back to after an authorization or authentication process.\n\nThis is a fundamental security mechanism in OAuth 2.0 and OpenID Connect.\n\n## Technical behavior\n\nIn a typical `authorization_code` flow, this works as follows:\n\n1. The client sends an authorization request with the desired redirect URI.\n2. The authorization server verifies that the URI is registered for the client.\n3. After successful authentication, the user is returned to this address.\n4. The response typically contains an authorization code.\n\n### Why exact registration matters\n\nRedirect URIs normally have to match exactly what the client uses in the request. This reduces the risk of the authorization code or other parameters being sent to the wrong recipient.\n\n## Use in OIDC clients\n\n### ID-porten\n\nRedirect URIs are a central part of login through ID-porten, since the authorization code is returned to the client's registered address.\n\n### Ansattporten\n\nThe same applies to Ansattporten, where correct registration is necessary for the authorization flow to work and remain secure.\n\n### Maskinporten\n\nRedirect URIs are normally not relevant in classic Maskinporten flows, since those are not based on browser redirects and interactive user login.\n",
+    "lang": "en",
+    "path": "/en/start/oidc/redirect_uri"
+  },
+  {
+    "id": "en-start-oidc-refresh_token_lifetime",
+    "title": "Refresh token lifetime",
+    "content": "# Refresh token lifetime\n\n## Purpose\n\nRefresh token lifetime specifies how long a refresh token can be used to obtain new access tokens.\n\nThis sets an upper limit on how long a client can continue access without new authentication.\n\n## Technical behavior\n\nAs long as the refresh token is valid and has not been revoked or invalidated, the client can use it to obtain newly issued access tokens.\n\n### Security considerations\n\nThe longer lifetime a refresh token has, the more valuable it becomes if it is exposed. A long lifetime should therefore be combined with measures such as:\n\n- secure storage\n- rotation\n- revocation\n- monitoring of suspicious use\n\n## Use in OIDC clients\n\n### ID-porten and Ansattporten\n\nThis is relevant for clients that want long-lived user sessions, but it must be balanced against security requirements and how sensitive the data is that the client provides access to.\n\n### Maskinporten\n\nRefresh token lifetime is normally not a central parameter in classic Maskinporten scenarios.\n",
+    "lang": "en",
+    "path": "/en/start/oidc/refresh_token_lifetime"
+  },
+  {
+    "id": "en-start-oidc-refresh_token_usage",
+    "title": "Refresh token usage",
+    "content": "# Refresh token usage\n\n## Purpose\n\nRefresh token usage describes how refresh tokens are handled in practice, beyond simply whether they are allowed or not.\n\nThis can include rules for issuance, reuse, rotation, and invalidation.\n\n## Technical behavior\n\nIn a simple model, the same refresh token can be used multiple times as long as it is valid. In a stricter model, each use can result in:\n\n- a new refresh token being issued\n- the old one being invalidated\n- misuse being easier to detect\n\n### Security significance\n\nThe chosen model affects how robust the solution is against token leakage and replay. The more long-lived and reusable a refresh token is, the more important strong protection becomes.\n\n## Use in OIDC clients\n\n### ID-porten and Ansattporten\n\nFor clients that need persistent user sessions, refresh token usage should be considered together with token storage, token lifetimes, and any requirements for rotation.\n\n### Maskinporten\n\nThis is normally not a central topic in Maskinporten integrations, since the pattern there is usually not built around refresh-token-based user sessions.\n",
+    "lang": "en",
+    "path": "/en/start/oidc/refresh_token_usage"
+  },
+  {
+    "id": "en-start-oidc-sso",
+    "title": "SSO",
+    "content": "# SSO\n\n## Om funksjonaliteten på engelsk\nID-porten har siden oppstarten tilbudt single-signon (SSO), ved at alle tjenestene i føderasjonen tilhører samme Circle-of-Trust (CoT). Dette er en viktig funksjonalitet for å at innbygger skal ha en friksjonsfri opplevelse ved bruk av offentlige digitale tjenester, ved at man slipper hyppig re-autentisering.  Spesielt for samensatte tjenester, for eksempel såkalte lenketjenester, der innbygger \"hopper\" mellom ulike etater som del av en komplett tjenesteleveranse, er SSO en nøkkelfunksjonalitet.\n\nLike viktig som single signon er single logout.  Det er vesentlig for sikkerheten til innbygger at hen blir logget ut av alle tjenester når hen klikker logout. **En feilkonfigurert logout-håndtering hos én kunde kan ødelegge for utlogging hos andre kunder, og gjøre innbygger sårbar for angrep.**\n\n## Single Signon (SSO)\nSSO-sesjonen er felles for både OIDC- og SAML-baserte tjenester, og er fra nov. 2023 styrt av Nye ID-porten (OIDC). Sesjonslevetid er felles for alle tjenester uavhengig av sikkerhetsnivå, og denne er 30 minutter, men kan forlenges uten brukerinteraksjon inntil maksimalt 120 minutter, ved å sende en ny autentiseringsforespørsel.\n\nAlle tjenester er i utgangspunktet med i samme circle-of-trust, men tjenester kan tvinge frem re-autentisering ved å sette attributten *prompt* til `login` i [autentiseringsforespørselen](http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest) (tilsvarende *forceAuth* i SAML2).  Det er i ny løsning også mulig å konfigurere en integrasjon til å bruke [isolert SSO-sesjon]({{site.baseurl}}/docs/idporten/oidc/oidc_func_nosso).\n\nMerk at levetiden på SSO-sesjonen ikke har noen sammenheng med levetiden på utstedte access-token og evt. refresh-tokens.\n\n## Single Logout (SLO)\nAlle OIDC-integrasjoner mot ID-porten må implementere støtte for følgende to utloggings-scenario:\n\n* Utlogging initiert fra egen tjeneste (endsession)\n* Utlogging initiert fra andre tjenester (front-channel logout)\n\nMerk at klienter som utfører endsession OGSÅ vil selv motta et frontkanal-utloggingskall dersom klienten har registrert en `frontchannel_logout_uri`.\n\nMerk at ID-porten nå støtter [back-channel logout]({{site.baseurl}}/docs/idporten/oidc/oidc_func_backchannel_logout).\n\n\nFor SAML-baserte tjenester må også begge utloggingsscenarioene støttes, men oppførselen er ulik - der OIDC sender frontkanalskallene fra iframer på en idporten-styrt side, så vil SAML foreta en kjede av redirects fra tjeneste til tjeneste. SAML-varianten er defor mer sårbar.\n\n### 1: Utlogging fra egen tjeneste (/logout)\n\nNår brukeren vil logge ut fra din tjeneste, må du sende en redirect (fortrinnsvis POSTe den) til ID-portens endsession-endepunkt `end_session_endpoint`. Se [detaljert grensesnittsdefinisjon her](oidc_protocol_logout.html).\n\n\nEksempel:\n```\nPOST https://idporten.no/logout\n\nid_token_hint=eyJraWQiOiJpZ2I1Q3lGT...\npost_logout_redirect_uri=\u003cmin registrerte post-logout uri \u003e\nstate=\u003ctilstand_jeg_kan_bruke_i_redirect_tilbake_til_meg_pluss_csrf_beskyttelse\u003e\n\n```\nENGLISH ENGLISH\nVed mottak av endsession-redirect, vil ID-porten logge brukeren ut av alle andre tjenester i aktiv SSO-sesjon, både OIDC og SAML. Til slutt vil ID-porten redirecte brukeren til *post_logout_redirect_uri* er oppgitt i request dersom denne er angitt og definert for klient, og *id_token_hint* er inkludert.  Dersom disse mangler, vil brukeren ende opp i ID-porten.\n\nUtlogging fra egen tjeneste er basert på [OIDC Session Management](http://openid.net/specs/openid-connect-session-1_0.html)-spesifikasjonen.\n\n#### Samspill mellom sesjoner og tokens ved utlogging\n\nID-porten vil også invalidere alle tokens som tilhører rene innlogginger (dvs. som kun har scopene \"openid\" og/eller \"profile\"). Merk at dette betyr at tokens som inneholder ytterligere scopes, fremdeles vil være aktive etter utlogging.  Motivasjonen bak denne oppførselen er at en utlogging fra netttjeneste tilhørende virksomhet A, ikke naturlig skal føre til at langt-levende app-tilgang tilhørende virksomhet B skal trekkes tilbake, om disse to tilfeldigvis ble utstedt med utgangspunkt i samme sso-sesjon.\n\n\n\n### 2: Håndtere utlogging fra ID-porten (front-channel logout)\n\nDersom brukeren logger ut fra en annen tjeneste, vil ID-porten trigge utlogging fra alle andre tjenester, dvs. både OIDC-tjenester som er konfigurert med støtte for Front Channel Logout, og SAML-tjenester. \n\nID-porten samler opp informasjon om hvilke tjenester en bruker benytter innenfor en sesjon.  For OIDC-klienter som støtter Front Channel Logout, sender ID-porten en GET-forespørsel til klientens *frontchannel_logout_uri*.  Parameterne *iss* og *sid* inkluderes for klienter som krever *frontchannel_logout_session_required*.  *sid* har samme verdi som claim *sid* i id_token.  ID-porten lager en dynamisk side der hver innlogget OIDC-klient får sin egen iframe og blir sendt et front-channel logout-kall i parallell.\n\nMerk at siden browser-aktørene stadig strammer inn på tilgangen til 3djeparts-cookies, kan man ikke lenger forvente at egen cookie følger med i front_channel_logout-kallet. Bruk av `sid`er derfor eneste fremtidsrettede løsning for å finne igjen egen, lokale brukersesjon.\n\nMerk også at klienten som starter utlogging med kall på endsession-endepunktet, også vil motta kall på front channel logout.\n\nEksempel på kall fra ID-porten til klient:\n```\nGET https://client.example.com/myapp/logout\n     ?iss=https://idporten.no/\n     \u0026sid=D8Fgz-jEXG7JXP_VAORmAm1sKB0LjZyA3wAy-rVyMYc=\n```\n`sid` er brukerens sesjons-id som klienten  mottok som claim i id-tokenet.\n\n\nFront-channel logout i ID-porten er basert på  [OIDC Front Channel Logout](http://openid.net/specs/openid-connect-frontchannel-1_0.html)-spesifikasjonen.\n\n\nDersom en klient ikke er konfigurert med Front Channel Logout, vil klienten ikke motta utloggingsforespørsel fra ID-porten dersom brukeren logger ut fra en annen tjeneste i circle-of-trust og id-tokenet vil heller ikke inneholde `sid`.  ",
+    "lang": "en",
+    "path": "/en/start/oidc/sso"
+  },
+  {
+    "id": "en-start-scopes-access_policy",
+    "title": "Access policy",
+    "content": "# Access policy\n\n## What does \"Available to everyone\" mean?\n\nThe option `Tilgjengelig for alle (Krever ingen godkjenning)` normally means that clients can request access without an extra manual or explicit approval step from the provider.\n\n## Benefits\n\nThis can provide fast onboarding and a low barrier to use. It is often best suited for open or standardized API access where the risk of misuse is limited.\n\n## Drawbacks\n\nWhen no approval is required, you lose an important control point. For more sensitive APIs, or for access that depends on legal or organizational clarification, stricter access control is often a better fit.\n",
+    "lang": "en",
+    "path": "/en/start/scopes/access_policy"
+  },
+  {
+    "id": "en-start-scopes-client_types",
+    "title": "Client types",
+    "content": "# Client types\n\n## What does this mean?\n\nChoices like `Ansattporten`, `API-klient`, and `Maskinporten` describe what kind of integration or usage scenario the scope belongs to. This often affects which other fields are relevant and how access should be interpreted.\n\n## Typical interpretation\n\n`API-klient` is usually relevant when a client obtains tokens and calls an API directly. `Maskinporten` often points to machine-to-machine scenarios where organizations act on their own behalf. `Ansattporten` is more relevant when an end user acts in a work context or on behalf of an organization.\n\n## Why it matters\n\nThe client type helps set expectations for authentication, token content, delegation, and user involvement. It should therefore reflect the real usage pattern, not only the technology being used.\n",
+    "lang": "en",
+    "path": "/en/start/scopes/client_types"
+  },
+  {
+    "id": "en-start-scopes-delegation_source",
+    "title": "Delegation source",
+    "content": "# Delegation source\n\n## What is a delegation source?\n\nThe delegation source states where a right or representation relationship comes from. In the screenshot, `altinn` is an example of such a source.\n\n## Why does it matter?\n\nWhen access depends on delegation, it is not enough to know who the client is. You also need to know where the authority comes from, and which rule set determines whether the client may act on behalf of someone else.\n\n## Example\n\nIf an organization has granted another party the right to perform an action in Altinn, that delegation may be the basis for using the scope. In that case, the delegation source becomes an important part of the authorization model.\n",
+    "lang": "en",
+    "path": "/en/start/scopes/delegation_source"
+  },
+  {
+    "id": "en-start-scopes-overview",
+    "title": "Scope overview",
+    "content": "# Scope overview\n\n## What is this?\n\nThis section describes fields and choices that are commonly used when defining a scope or API access. The goal is not to document every detail, but to provide short explanations that make the different settings easier to understand in practice.\n\n## Typical topics\n\n- which client or product type the scope belongs to\n- whether the scope is public or private\n- how access is approved and delegated\n- how tokens are shaped and how long they live\n- whether the end user must be involved\n\n## How to use these pages\n\nEach page explains one concept, when it is typically used, and which trade-offs come with it. That makes the folder useful as realistic example content under `scopes`.\n",
+    "lang": "en",
+    "path": "/en/start/scopes/overview"
+  },
+  {
+    "id": "en-start-scopes-pseudonymous_login",
+    "title": "Pseudonymous login",
+    "content": "# Pseudonymous login\n\n## What does it mean?\n\nPseudonymous login means that the identity shared with the client or API is limited, so the end user is not necessarily exposed through full or direct identification.\n\n## When is it useful?\n\nThis can be relevant when a service needs to recognize the same user over time, but does not need a full national identity number or other strong identifiers in every call.\n\n## What should be considered?\n\nPseudonymization reduces data sharing, but it can also make some forms of linking and case handling harder. It should therefore be used when it is actually sufficient for the purpose.\n",
+    "lang": "en",
+    "path": "/en/start/scopes/pseudonymous_login"
+  },
+  {
+    "id": "en-start-scopes-token_lifetimes",
+    "title": "Token lifetimes",
+    "content": "# Token lifetimes\n\n## Access token lifetime\n\nThe access token lifetime decides how long an issued token can be used against an API. A short lifetime limits the impact if a token is leaked, but also means the client must obtain new tokens more often.\n\n## Authorization lifetime\n\nAuthorization lifetime describes how long a given authorization or approval can remain valid as the basis for issuing tokens. This is not necessarily the same as the lifetime of the access token itself.\n\n## Practical trade-off\n\nIt is common to choose shorter lifetimes for sensitive access and longer lifetimes where frequent renewal creates unnecessary complexity. Both values should be evaluated together with risk and user experience.\n",
+    "lang": "en",
+    "path": "/en/start/scopes/token_lifetimes"
+  },
+  {
+    "id": "en-start-scopes-token_type",
+    "title": "Token type",
+    "content": "# Token type\n\n## SELF_CONTAINED\n\nA `SELF_CONTAINED` token typically carries the information the receiver needs directly in the token, for example as claims in a JWT. This makes validation fast and independent of an extra lookup, but it can also produce larger tokens and expose more information on the client or API side.\n\n## OPAQUE\n\nAn `OPAQUE` token is usually only a reference. The API must then look up or introspect the token to retrieve the associated information. This gives more centralized control, but also creates a dependency on the lookup mechanism.\n\n## Practical choice\n\nToken type should be selected based on performance needs, control, complexity, and how much information should live directly inside the token.\n",
+    "lang": "en",
+    "path": "/en/start/scopes/token_type"
+  },
+  {
+    "id": "en-start-scopes-user_involvement",
+    "title": "User involvement",
+    "content": "# User involvement\n\n## What does this cover?\n\nUser involvement describes whether the end user must actively do something before access is granted or maintained. In the screenshot, examples include `Krev reautentisering` and `Krev godkjenning fra sluttbruker`.\n\n## Re-authentication\n\nIf re-authentication is required, the user must confirm their identity again before the action or data sharing can continue. This is typically used for higher-risk or more sensitive actions.\n\n## End-user approval\n\nWhen approval from the end user is required, consent or explicit acceptance becomes part of the flow. This fits scenarios where the user must control whether data sharing or access should be allowed.\n",
+    "lang": "en",
+    "path": "/en/start/scopes/user_involvement"
+  },
+  {
+    "id": "en-start-scopes-visibility",
+    "title": "Visibility",
+    "content": "# Visibility\n\n## What do PUBLIC and PRIVATE mean?\n\nVisibility decides how visible the scope is to other users or organizations in the solution. A `PUBLIC` scope can typically be discovered and reused more broadly, while a `PRIVATE` scope is more restricted and intended for controlled scenarios.\n\n## When to use PRIVATE\n\n`PRIVATE` is often the right choice when access needs tight control, when the scope should only be used by known parties, or when it represents internal or sensitive API access.\n\n## When to use PUBLIC\n\n`PUBLIC` can make sense when the scope should be easy to find and use for many consumers, and when the access process is clear enough that broader exposure is desirable.\n",
+    "lang": "en",
+    "path": "/en/start/scopes/visibility"
+  },
+  {
+    "id": "nb-start-Starthjelp",
+    "title": "Oppstartsguide",
+    "content": "# Oppstartsguide\n\nhei klar deg selv",
+    "lang": "nb",
+    "path": "/nb/start/Starthjelp"
+  },
+  {
+    "id": "nb-start-faq",
+    "title": "Ofte stilte spørsmål",
+    "content": "# Ofte stilte spørsmål\n\n## Hvordan lager jeg pannekaker?\n\nYou Dont",
+    "lang": "nb",
+    "path": "/nb/start/faq"
+  },
+  {
+    "id": "nb-start-oidc-access_token_lifetime",
+    "title": "Access token levetid",
+    "content": "# Access token levetid\n\n## Formål\n\nAccess token levetid angir hvor lenge et access token er gyldig.\n\nNår levetiden utløper, kan tokenet ikke lenger brukes mot beskyttede ressurser.\n\n## Teknisk virkemåte\n\nEt access token representerer en tidsbegrenset tilgang til API-er og ressurser innenfor gitte scopes og rettigheter. Levetiden avgjør hvor lenge denne tilgangen kan brukes uten fornyelse.\n\n### Avveining\n\nKort levetid gir bedre sikkerhet fordi et lekket token kan misbrukes i kortere tid.\n\nLengre levetid gir færre tokenfornyelser og kan forenkle klientlogikken, men øker samtidig konsekvensen dersom tokenet kompromitteres.\n\n## Bruk i OIDC-klienter\n\n### ID-porten og Ansattporten\n\nFor brukerrettede OIDC-klienter bør access token levetid ses i sammenheng med om refresh tokens brukes. Kort access token levetid kombinert med kontrollert fornyelse er et vanlig mønster.\n\n### Maskinporten\n\nMaskinporten bygger også på tidsbegrensede tokens, og levetid er her tilsvarende viktig for å balansere sikkerhet og operativ bruk.\n",
+    "lang": "nb",
+    "path": "/nb/start/oidc/access_token_lifetime"
+  },
+  {
+    "id": "nb-start-oidc-allowed_grant_types",
+    "title": "Tillatte grant types",
+    "content": "# Tillatte grant types\n\n## Formål\n\nTillatte grant types angir hvilke OAuth 2.0-flyter en klient har lov til å bruke.\n\nEn grant type beskriver hvordan klienten får tilgang til tokens, og er dermed en viktig del av klientens sikkerhets- og integrasjonsprofil.\n\n## Teknisk virkemåte\n\nHver grant type representerer et bestemt autorisasjonsmønster. Ved å begrense hvilke grant types som er tillatt, begrenses også hvilke tokenflyter klienten kan benytte.\n\nDette er viktig for å:\n\n- redusere angrepsflaten\n- hindre utilsiktet bruk av uønskede flyter\n- gjøre klientkonfigurasjonen mer forutsigbar\n\n### Sikkerhetsprinsipp\n\nEn klient bør bare ha tilgang til de grant types den faktisk trenger. Overflødige flyter bør ikke være aktivert.\n\n## authorization_code\n\n`authorization_code` er en grant type der en klient først sender brukeren til autorisasjonsserveren for autentisering, og deretter mottar en autorisasjonskode som byttes inn i tokens.\n\nDette er den vanligste og mest anbefalte flyten for nettleserbasert innlogging i OIDC.\n\n### Teknisk virkemåte\n\nFlyten består typisk av disse trinnene:\n\n1. Klienten sender brukeren til autorisasjonsendepunktet.\n2. Brukeren autentiserer seg.\n3. Autorisasjonsserveren returnerer brukeren til klientens redirect URI med en autorisasjonskode.\n4. Klienten sender autorisasjonskoden til token-endepunktet.\n5. Klienten mottar access token, og eventuelt ID-token og refresh token.\n\n#### Hvorfor denne flyten anses som sikker\n\nI denne flyten returneres det ikke tokens direkte via nettleseren. I stedet returneres en kortlivet kode, som klienten må utveksle server-til-server. Dette reduserer risikoen for lekkasje sammenlignet med mindre robuste mønstre.\n\n#### PKCE\n\n`authorization_code` brukes ofte sammen med PKCE. PKCE beskytter mot at autorisasjonskoden fanges opp og misbrukes av andre enn klienten som startet flyten.\n\n## Bruk i OIDC-klienter\n\n### ID-porten\n\nDette er den sentrale grant-typen for vanlige OIDC-innlogginger mot ID-porten.\n\n### Ansattporten\n\nAnsattporten bruker samme grunnmønster for brukerautentisering og tokenutveksling, og `authorization_code` er derfor tilsvarende relevant.\n\n### Maskinporten\n\nDenne grant-typen brukes normalt ikke for Maskinporten, siden Maskinporten ikke bygger på interaktiv brukerinnlogging i nettleser.\n\n## Refresh token\n\nEt refresh token gjør det mulig for en klient å hente nye access tokens uten at brukeren må autentisere seg på nytt hver gang et access token utløper.\n\nDette brukes for å opprettholde langvarige økter eller tilgang over tid.\n\n### Teknisk virkemåte\n\nNår en klient mottar både access token og refresh token, kan flyten se slik ut:\n\n1. Access token brukes mot beskyttede API-er.\n2. Når access token utløper, sender klienten refresh token til token-endepunktet.\n3. Autorisasjonsserveren utsteder nytt access token dersom refresh token fortsatt er gyldig.\n\n### Sikkerhetsmessig betydning\n\nEt refresh token er ofte mer sensitivt enn et access token, fordi det kan brukes til å utstede nye tokens over tid. Det må derfor lagres og behandles med høy grad av beskyttelse.\n\n## Bruk i OIDC-klienter\n\n### ID-porten og Ansattporten\n\nFor klienter som trenger vedvarende brukerøkter, kan refresh token være relevant. Dette må vurderes opp mot behov, sikkerhetsnivå og hvordan klienten lagrer tokens.\n\n### Maskinporten\n\nRefresh token er normalt ikke del av det vanlige mønsteret for Maskinporten, siden Maskinporten typisk ikke representerer brukerøkter på samme måte som OIDC-klienter for sluttbrukere.\n\n## Bruk i OIDC-klienter\n\n### ID-porten og Ansattporten\n\nFor sluttbrukerrettede OIDC-klienter er `authorization_code` den mest relevante grant-typen. Den brukes når en bruker autentiserer seg via nettleser og klienten deretter henter tokens fra token-endepunktet.\n\n### Maskinporten\n\nMaskinporten brukes normalt for maskin-til-maskin-autorisering og følger andre mønstre enn ordinær brukerinnlogging. Dokumentasjon som omtaler OIDC-klienter vil derfor som regel være mest relevant for ID-porten og Ansattporten.\n",
+    "lang": "nb",
+    "path": "/nb/start/oidc/allowed_grant_types"
+  },
+  {
+    "id": "nb-start-oidc-ansattporten-entraid-entraid",
+    "title": "Generelt om EntraID",
+    "content": "# Generelt om EntraID\n\nMicrosoft ",
+    "lang": "nb",
+    "path": "/nb/start/oidc/ansattporten/entraid/entraid"
+  },
+  {
+    "id": "nb-start-oidc-ansattporten-general",
+    "title": "Generelt om ansattporten",
+    "content": "# Generelt om ansattporten\nAnsattporten er en egen innloggingtjeneste med funksjonalitet som er tilpasset bruk som ansatt eller i andre situasjoner der en nett-tjeneste eller et API har behov for at sluttbruker må opptre i et representasjonsforhold på vegne av virksomheter.\n\n```mermaid\ngraph LR\n  I(ID-porten)\n  A(Ansattporten)\n  IRP(Tjeneste for innbygger)\n  ARP(Tjeneste for ansatte)\n\n  eid[\"Privat eID-leverandør \n  (MinID, BankID, etc... )\"]\n  ak[(\"Autorativ kilde\n(Altinn Autorisasjon)\")]\n  aid[\"Ansatt-eid\n(pilot: Microsoft Entra ID)\"]\n\n  IRP -. integrert mot .- I \n  I -. videreformidler innlogging fra  .- eid\n\n  ARP -. integrert mot .-\u003e A\n  A -. videreformidler innlogging fra .-\u003e eid \n  A -.-\u003e |henter representasjon fra | ak\n\n  A -...- | videreformidler innlogging og representasjon fra | aid\n```\n\nDisse viktigste egenskapene ved Ansattporten er som følger:\n\n### Egen \"port\"\n\nAnsattporten er en selvstendig tjeneste som er uavhengig av ID-porten.  Det betyr at tjenester i ID-porten ikke er mulig å nå fra Ansattporten og vice versa. \n\nSamtidig så deler ID-porten og Ansattporten samme kildekode-base, så det er i praksis bare litt konfigurasjon og tilpasset funksjonalitet som skiller de to portene teknisk.  Som hovedregel vil oppdateringer, feilrettinger og ny funksjonalitet bli rullet ut mer eller mindre samtidig til begge portene. Ansattporten tilbyr også de samme elektroniske ID'ene som er tilbudt av ID-porten, dvs. MinID, BankID, Buypass og Commfides.\n\nProtokollmessig sier vi at Ansattporten er en egen Oauth2 autorisasjonsserver / OpenID Provider, identifisert ved sin `issuer`-verdi.\n\n\n### Ingen SSO-funksjonalitet mellom tjenester\n\nSom forklart ovenfor, så er ID-porten og Ansattporten isolert fra hverandre som separate OpenID providere. Det er derfor ikke mulig å få single-sign on (SSO) mellom ansatt-tjenester i Ansattporten til innbygger-tjenester i ID-porten.  \n\nMen til forskjell fra ID-porten så tilbyr ikke Ansattporten SSO mellom de ulike tjenestene heller.  Dette er realisert ved at alle klienter får tvangs-satt flagget som aktiverer funksjonaliteten [isolert sso-sesjon](../../docs/idporten/oidc/oidc_func_nosso.html).\n\n### Autorative kilder for representasjon\n\nAnsattporten kan brukes enten til ordinær punktinnlogging, eller til å kreve at innlogga bruker må ha et bestemt representasjonsforhold for en virksomhet.   Ansattporten har ikke - og vil aldri få - sin egen database/register over roller/rettigheter, men baserer seg på eksterne, autorative kilder for representasjonsforhold.\n\nDersom tjenesten krever representasjon, vil Ansattporten vise en organisasjonsvelger til brukeren, som er forhåndspopulert basert den autorative kilden.\n\nI dag er det kun Altinn Autorisasjon som er støttet som autorativ kilde. \n\n\n# Hvem kan bruke Ansattporten ?\n\nAlle kunder som har inngått Digdir sine bruksvilkår for fellesløsninger kan bruke Ansattporten til ordinær punkt-autentisering på samme måte som de gjør i ID-porten idag.\n\nMen bare kunder som også er tjenesteeier i Altinn, kan bruke funksjonaliteten med organisasjonsvelger og tilgangstyring basert på representasjonsforhold i Altinn Autorisasjon.\n\n\n# Hva koster Ansattporten ?\n\nP.t. har Ansattporten samme finansieringsmodell som ID-porten.  200.000-innnloggingskvoten er felles for de to portene.\n\nMerk at finansieringsmodell trolig vil endres i fremtiden.\n\n\n# Hvordan administrerer jeg Ansattporten ?\n\nPå akkurat samme måte som for ID-porten, men du må passe på at integrasjonene du opprette i selvbetjening har `integration_type` satt til `ansattporten`.\n\n\n# Er Ansattporten fremdeles i pilot-status? \n\nFra 2025 går Ansattporten over i mer ordinær drift.  SLA i form av oppetid vil være den samme som for ID-porten, og feilrettinger vil bli prioritert ihht de ordinære rutinene rundt fellesløsningene.\n\nSe [artikkel på Samarbeidsportalen](https://samarbeid.digdir.no/ansattporten/ansattporten-er-no-i-produksjon-som-ei-fullverdig-fellesloysing/2969).\n\n# Hvilken bruk-scenario støttes ? \n\nAnsattporten tilbyr per nå tre brukerreiser:\n\n* [Vanlig innlogging (med isolert SSO)](ansattporten_guide.html)\n* [Innlogging på vegne av virksomhet](ansattporten_representasjon.html)\n* [Datadeling på vegne av virksomhet](ansattporten_datadeling.html)\n",
+    "lang": "nb",
+    "path": "/nb/start/oidc/ansattporten/general"
+  },
+  {
+    "id": "nb-start-oidc-ansattporten-integration_guide",
+    "title": "Integrasjonsguide",
+    "content": "# Integrasjonsguide\n\nSitronkake og mozell",
+    "lang": "nb",
+    "path": "/nb/start/oidc/ansattporten/integration_guide"
+  },
+  {
+    "id": "nb-start-oidc-application_type",
+    "title": "Applikasjonstyper",
+    "content": "# Applikasjonstyper\n\n## Web (Webapplikasjon)\n\nEn webapplikasjon er et program som kjører på en server og brukes via en nettleser over internett eller intranett. Brukeren installerer ingenting lokalt.\n\n### Kjennetegn\n\n- Tilgang via URL  \n- Krever nettleser  \n- Plattformuavhengig  \n- Oppdateres sentralt på server  \n\n## Browser (Nettleserbasert applikasjon)\n\nEn browser-applikasjon er en type webapplikasjon som kjører direkte i nettleseren og er bygget med HTML, CSS og JavaScript.\n\n### Kjennetegn\n\n- Kjører i nettlesermiljøet  \n- Ingen lokal installasjon  \n- Bruker nettleserens motor  \n- Kan bruke nettleserens API-er  \n\nMerk: “Web application” og “browser application” brukes ofte om hverandre, men “browser application” presiserer at kjøringen skjer direkte i nettleseren.\n\n## Native (Lokal / Native applikasjon)\n\nEn native applikasjon installeres direkte på en enhet og kjører på operativsystemet, ikke i en nettleser.\n\n### Kjennetegn\n\n- Må installeres  \n- Bygget for spesifikt operativsystem  \n- Direkte tilgang til maskinvare og systemressurser  \n- Ofte bedre ytelse  ",
+    "lang": "nb",
+    "path": "/nb/start/oidc/application_type"
+  },
+  {
+    "id": "nb-start-oidc-authentication_method",
+    "title": "Autentiseringsmetode",
+    "content": "# Autentiseringsmetode\n\n## Formål\n\nAutentiseringsmetode angir hvordan en klient identifiserer og autentiserer seg overfor autorisasjonsserveren når den kaller endepunkter som krever klientautentisering, typisk token-endepunktet.\n\nDette er særlig relevant for konfidensielle klienter, altså klienter som kan beskytte nøkler eller hemmeligheter på en forsvarlig måte.\n\n## Teknisk virkemåte\n\nValgt metode bestemmer hvilken mekanisme klienten skal bruke for å bevise sin identitet. Vanlige mekanismer er:\n\n- klienthemmelighet\n- signert klientassertion\n- andre støttede metoder for klientautentisering\n\nNår `private_key_jwt` brukes, autentiserer klienten seg ved å sende en signert JWT assertion. Autorisasjonsserveren validerer signaturen mot klientens registrerte offentlige nøkkel eller tilhørende nøkkelmateriale.\n\n### Hvorfor `private_key_jwt` brukes\n\n`private_key_jwt` brukes ofte når man ønsker sterkere klientautentisering enn delt hemmelighet kan gi. Dette passer godt i integrasjoner der:\n\n- nøkkelmateriale kan forvaltes sikkert\n- nøkkelrotasjon er viktig\n- man ønsker tydeligere separasjon mellom klientidentitet og delt passordbasert autentisering\n\n## Bruk i OIDC-klienter\n\n### ID-porten\n\nFor OIDC-klienter mot ID-porten brukes dette for å autentisere klienten mot token-endepunktet etter at en autorisasjonskode er mottatt.\n\n### Ansattporten\n\nFor OIDC-klienter mot Ansattporten gjelder samme prinsipp som for ID-porten: klienten må autentisere seg sikkert når kode byttes mot token.\n\n### Maskinporten\n\nMaskinporten er normalt ikke en sluttbrukerbasert OIDC-flyt, men tilsvarende prinsipp for sterk klientautentisering er sentralt også der, særlig ved signering med virksomhetsnøkler i maskin-til-maskin-scenarier.\n",
+    "lang": "nb",
+    "path": "/nb/start/oidc/authentication_method"
+  },
+  {
+    "id": "nb-start-oidc-authorization_lifetime",
+    "title": "Autorisasjon levetid",
+    "content": "# Autorisasjon levetid\n\n## Formål\n\nAutorisasjon levetid beskriver hvor lenge en autorisasjon eller autorisasjonsrelatert tilstand regnes som gyldig.\n\nDen eksakte betydningen kan variere mellom implementasjoner, men handler normalt om levetiden på en godkjenning, samtykketilstand eller autorisasjonskontekst.\n\n## Teknisk virkemåte\n\nI en autorisasjonsflyt kan det finnes flere tidsavgrensede tilstander, for eksempel at:\n\n- en bruker har gitt samtykke\n- en klient har fått etablert en autorisert relasjon\n- en pågående autorisasjonsprosess fortsatt er gyldig\n\nAutorisasjon levetid bestemmer hvor lenge en slik tilstand kan videreføres før ny autorisering eller ny vurdering må skje.\n\n### Viktig avgrensning\n\nDette er ikke nødvendigvis det samme som:\n\n- levetiden på access token\n- levetiden på refresh token\n- lengden på en innloggingssesjon\n\n## Bruk i OIDC-klienter\n\n### ID-porten og Ansattporten\n\nDette kan være relevant i klienter der samtykke, autorisasjonsbeslutninger eller relasjoner mellom klient og bruker skal ha en definert varighet.\n\n### Maskinporten\n\nI Maskinporten-sammenheng vil tilsvarende vurderinger ofte være mer knyttet til delegasjon, tilgangsgrunnlag og tokenutstedelse enn til sluttbrukerbasert samtykke.\n",
+    "lang": "nb",
+    "path": "/nb/start/oidc/authorization_lifetime"
+  },
+  {
+    "id": "nb-start-oidc-backchannel_logout_uri",
+    "title": "Backchannel logout URI",
+    "content": "# Backchannel logout URI\n\n## Formål\n\nBackchannel logout URI er adressen en autorisasjonsserver bruker for å varsle en klient direkte om at en sentral sesjon er avsluttet.\n\nDette skjer server-til-server, uten at brukerens nettleser er involvert.\n\n## Teknisk virkemåte\n\nVed logout kan autorisasjonsserveren sende en logout-melding til klientens backend. Klienten kan da:\n\n- identifisere berørt lokal sesjon\n- ugyldiggjøre sesjonstilstand\n- rydde opp i sikkerhetskontekst\n\n### Hvorfor dette er nyttig\n\nBackchannel logout er ofte mer robust enn nettleserbasert logout fordi den ikke er avhengig av nettleserpolicyer, cookies eller iframe-oppførsel.\n\n## Bruk i OIDC-klienter\n\n### ID-porten og Ansattporten\n\nDette er relevant for klienter som har server-side sesjoner og trenger pålitelig koordinert logout.\n\n### Maskinporten\n\nDette er normalt ikke relevant i Maskinporten, siden det ikke er en interaktiv sluttbrukersesjon som skal samordnes.\n",
+    "lang": "nb",
+    "path": "/nb/start/oidc/backchannel_logout_uri"
+  },
+  {
+    "id": "nb-start-oidc-frontchannel_logout_uri",
+    "title": "Frontchannel logout URI",
+    "content": "# Frontchannel logout URI\n\n## Formål\n\nFrontchannel logout URI er adressen som brukes når logout koordineres via brukerens nettleser.\n\nDette gjør det mulig å informere klienten om at sentral sesjon er avsluttet, slik at lokal sesjon også kan avsluttes.\n\n## Teknisk virkemåte\n\nVed frontchannel logout laster autorisasjonsserveren klientens registrerte URI i nettleseren. Klienten må da håndtere dette på en måte som gjør at lokal sesjon ryddes opp.\n\n### Begrensninger\n\nSiden denne mekanismen går via nettleseren, påvirkes den av forhold som:\n\n- cookie-regler\n- nettleserpolicyer\n- iframe-støtte\n- timing og lastemønster\n\nDerfor er frontchannel logout ofte mindre robust enn backchannel logout for klienter med omfattende server-side sesjonstilstand.\n\n## Bruk i OIDC-klienter\n\n### ID-porten og Ansattporten\n\nDette er relevant når man ønsker koordinert logout i nettleserbaserte sluttbrukerforløp.\n\n### Maskinporten\n\nDette er normalt ikke relevant i Maskinporten, siden det ikke finnes en tilsvarende nettleserbasert brukersesjon.\n",
+    "lang": "nb",
+    "path": "/nb/start/oidc/frontchannel_logout_uri"
+  },
+  {
+    "id": "nb-start-oidc-idporten-general",
+    "title": "Generelt om idporten",
+    "content": "# Generelt om idporten\nID-porten gjør innlogging til digitale tjenester trygt for innbyggere.  Se [produktsida for ID-porten på Samarbeidsportalen ](https://vg.no) for overordnet informasjon om hva ID-porten er, hva den koster og hvordan inngå bruksvilkår for å kunne ta den i bruk.\n\n## Introduksjon\n\nID-porten tilbyr følgende bruksområder til kundene:\n\n* hei\n* [**API-sikring** i kontekst av en innlogget bruker]({{site.baseurl}}/docs/idporten/oidc/oidc_auth_oauth2), populært kalt brukerstyrt datadeling.\n* [Innlogging **på vegne av andre**]({{site.baseurl}}/docs/idporten/oidc/oidc_auth_fullmakt)\n\n\n## Arkitektur\n\n\nArkitekturen for ID-porten ser slik ut:\n\nSelve ID-porten er basert på en moderne Oauth2/OIDC autorisasjonsserver fra Connect2ID.\n\n[SAML-grensesnittet]({{site.baseurl}}/docs/idporten/oidc/oidc_func_saml) er basert på en enkel proxy som oversetter kundens SAML-meldinger til OIDC-protokollen.\n\nBemyndigede ansatte eller systemer bruker [Digdirs felles selvbetjeningsløsning på web eller over API](https://docs.digdir.no/docs/Maskinporten/maskinporten_sjolvbetjening_web)\n til å registrere og vedlikeholde kundens integrasjoner.\n\nFølgende aktører inngår i løsningen:\n\n| Aktører | Beskrivelse |\n| ---- | ---- |\n| Sluttbruker | Innbygger med eID |\n| ID-porten | *ID-porten* er et tillitsanker for offentlige virksomheter. ID-porten knytter de offentlige virksomhetene og e-ID-leverandørene sammen. |\n| Kunde | Offentlig virksomhet som har akseptert bruksvilkår |\n| Tjenesteleverandør | Leverandør som leverer tjenester til en offentlig virksomhet |\n| API-tilbyder | Kunde som tilbyr APIer sikret med ID-porten. |\n| e-ID-leverandør | En av de 4 e-ID-aktørene som er tilgjengelige i ID-porten: MinID, Commfides, Buypass, BankID |\n| MinID | *MinID* er en offentlig utstedt e-ID på nivå betydelig, som tilbyr autentisering basert på engangskoder på sms eller app. |\n| Sertifikatutsteder | Sertifikatutsteder som oppfyller kravene for virksomhetssertifikater i henhold til Lov om Tillitstjenester. |\n\n| Felt | Krav |\n| ---- | ---- |\n| Filformat | .png .jpg eller .gif |\n| Størrelse | Maksimal høyde 90 pixel ... |\n| Farge | Bakgrunnsfargen på ID-porten ... |\n\n## Autentisering av sluttbruker\nID-portens tjenestetilbud for autentisering kan funksjonelt oppsummeres slik:\n\n#### Støttede protokoller\n* OpenID Connect\n* SAML2 er kun tilgjengelig for de som ikke kan benytte OpenID Connect\n\n#### Føderering / SSO\n\nDersom sluttbruker er innlogget hos tjenesteeier A og velger å gå videre til en tjenesteeier B uten å logge ut, vil bruker automatisk logges inn uten at bruker må autentisere seg på nytt.\n\n#### Sesjonsoppgradering\n\nDet er mulig for en sluttbruker å gjennomføre en autentisering på nivå 3 og seinere gå til en tjeneste som krever et høyere sikkerhetsnivå. I dette tilfellet vil ID-porten be brukeren om å oppgradere sikkerhetsnivå.\n\n#### Utenlandske brukere\n\nID-porten har støtte for at ulike kategorier av [utenlandske brukere]({{site.baseurl}}/docs/idporten/oidc/oidc_func_utanlandske_brukarar) kan logge seg på norske tjenester. \n\n\n## Brukerstyrt datadeling\n\nID-porten kan også [styre tilgang til APIer hos 3dje.part]({{site.baseurl}}/docs/idporten/oidc/oidc_auth_oauth2)\n\nAPI-tilgangen kan være innloggingsbasert (implisitt samtykke) eller brukerstyrt (eksplisitt samtykke).  I begge tilfeller  gjelder autorisasjonen kun for en enkelt innbygger, ulikt [Maskinporten]({{site.baseurl}}/docs/Maskinporten/maskinporten_overordnet) som er tiltenkt hjemmelsbasert datadeling.\n\nAPI-tilganger i ID-porten er modellert som Oauth2 scopes. For tilgangsstyrte scopes er det et organisasjonummer (=API-konsument) som blir gitt tilgang av API-tilbyder.  API-konsument må så aktivt selv registrere det tildelte scopet på en av sine integrasjoner.\n\n\n## Hvordan få tilgang til ID-porten\n\nFølg prosessen på [Samarbeidsportalen](https://samarbeid.digdir.no/id-porten/ta-i-bruk-id-porten/94) for å integrere mot ID-porten.\n\n#### Bruk selvbetjening til å registere integrasjonen din\n\nKunden bruker selvbetjeningsløsningen til å registrere påkrevd informasjon om integrasjonen sin. Dette er nærmere beskrevet under [klientregistrering]({{site.baseurl}}/docs/idporten/oidc/oidc_func_clientreg)\n\n#### Send oss logoen din\n\nKunde må sende oss egen logo som blir brukt i innloggingsbildet. Logoen for tjenesten må oppfylle følgende krav:\n\n| --- | --- |\n| Filformat | .png .jpg eller .gif |\n| Størrelse | Maksimal høyde 90 pixel og en bredde som ikke bør overskride 135 pixel. |\n| Farge | Bakgrunnsfargen på ID-porten er #f3f4f4, så logoen bør enten ha denne bakgrunnsfargen eller eventuelt ha transparent bakgrunn. |\n\n#### Test din egen løsning\n\nKunden må utføre en rekke verifikasjonstester for å bekrefte at integrasjonen oppfyller ID-portens krav.\n\n[Verifikasjonstester finner du her]({{site.baseurl}}/docs/idporten/idporten/idporten_verifikasjonstester).\n\n[Testbrukere finner du her]({{site.baseurl}}/docs/idporten/idporten/idporten_testbrukere).\n\n#### Åpne for IP-adresser\n\nDersom kunden har utgående brannmur, må det [åpnes for ID-portens IP-adresse]({{site.baseurl}}/docs/general/IP).\n\n#### Sørg for tilstrekkelig egen logging\n\nDet anbefales at kunden logger følgende informasjon om forsøk på autentisering:\n* Dato og tidspunkt\n* Hvilken handling som ble forsøkt\n* Resultatet av handlingen\n* Brukerens IP-adresse  \n* SessionIndex / sid\n* Fødselsnummer\n\nKunden sitt konkrete behov for logging opp mot personvernbetraktninger må vurderes av den enkelte kunde selv.\n\n#### Etabler gode IT-sikkerhetsrutiner i virksomheten\n\nDet er viktig at Kunden beskytter integrasjonen sin og etablerer rutiner slik at kun bemyndiget personell har tilgang til den. Se f.eks [anbefalinger for sertifikatbehandling, logging og sporing fra Veileder for virksomhetsautentisering](https://www.digdir.no/datadeling/sertifikatbehandling-logging-og-sporing/2438)\n\nKunden skal også gjøre en risikovurdering av egen løsning, her anbefaler vi [avsnittet om valg av sikkerhetsnivå fra Veileder for identifikasjon og sporbarhet i elektronisk kommunikasjon med og i offentlig sektor](https://www.digdir.no/digital-samhandling/veileder-identifikasjon-og-sporbarhet-i-elektronisk-kommunikasjon-med-og-i-offentlig-sektor/2992#veiledning_for_valg_av_sikkerhetsniv_for_identifikasjon)\n\n\n\n\n#### Sørg for sikker håndtering av nøkler\n\nDet er sentralt for sikkerheten i løsningen at tjenesteleverandør planlegger og designer prosedyrer for god nøkkelhåndtering (Key management, uansett om dette er statiske hemmeligheter (client_secret), egne-generete asymmetriske nøkler eller virksomhetssertifikat.  \n\nHvis en nøkkel kompromitteres, kan en angriper utgi seg for å være kunde i dialogen med ID-porten og dekryptere persondata sendt fra ID-porten. Slike sikkerhetsbrudd vil formodentlig i særlig grad ramme tilliten til kunden, men kan også tenkes å svekke tilliten til hele føderasjonen.\n\nFølgende punkter er det viktig at man tenker gjennom i forbindelse med nøkkelhåndtering:\n* Hvor oppbevares private nøkler, og hvordan sikres adgang til dem? For optimal beskyttelse kan en nøkkel oppbevares i kryptografisk hardware (HSM – hardware security module), men ofte benyttes krypterte filer som et billig, men mindre sikkert alternativ.\n* Hvordan håndteres backup av nøkler og hvordan gjenetableres disse ved behov?\n* Hvilket personell har tilgang til servere med private nøkler, og hvem har eventuelt tilgang til passord som kan benyttes til å dekryptere nøklene slik at de opptrer i klartekst? Kan enkeltpersoner skaffe seg adgang til private nøkler? Ligger passord for tilgang til nøkkellager ubeskyttet i konfigurasjonsfiler?\n* Hvordan håndteres fornyelse av nøkler når tilhørende sertifikater utløper? Hvis en tjenesteleverandør ikke fornyer nøkler/sertifikater innen de utløper, kan tjenester for tjenesteeier plutselig slutte å virke.\n* Hva er prosedyren om en privat nøkkel kompromitteres, eller om det er mistanke om at så har skjedd?\n* Hvordan loggføres nøkkelhåndteringsprosessen hos tjenesteleverandør?\n\nEn kunde bør analysere disse problemstillingene nøye, og utarbeide passende driftsprosedyrer som implementerer organisasjonens IT sikkerhetspolitikk.\n\n\n#### Bruk av virksomhetssertifikat\n\nVi anbefaler at kunder bruker virksomhetssertifikat til oppkobling mot ID-porten. For kunder som har mange integrasjoner, bør man heller vurdere å bruke virksomhetssertifikatet til å  automatisere integrasjonsvedlikeholdet slik at hver enkelt-integrasjon istedet bruker en assymetrisk nøkkel til oppkobling og denne blir rotert hyppig.\n\nMerk at sertifikatutstedere av virksomhetssertifikat har noe bestillingstid. Tjenesteleverandører oppfordres til å bestille sertifikat i god tid.\n\n\n## Problemer ?\n\nOm du opplever problemer med integrasjonen din: Kontakt servicedesk@digdir.no oppgi client_id og miljø og forklar problemet.",
+    "lang": "nb",
+    "path": "/nb/start/oidc/idporten/general"
+  },
+  {
+    "id": "nb-start-oidc-idporten-integration_guide",
+    "title": "Integrasjonsguide",
+    "content": "# Integrasjonsguide\n\nID-porten tilbyr funksjonalitet for autentisering av sluttbrukere basert på autorisasjonskode-flyten, slik den er spesifisert i OpenID Connect Core 1.0 spesifikasjonen.\n\n**Dette er den foretrukne flyten for de aller fleste tjenester** som skal bruke ID-porten som autentiseringstjeneste. Det kan finnes unntak, som for eksempel [mobilapp'er](oidc_auth_app.html) eller [javascript-applikasjoner](oidc_auth_spa.html), som vil ha en litt annen måte å bruke denne flyten på.\n\n## Overordna beskrivelse av bruksområdet\n\nID-porten tilbyr autentisering av brukere til sluttbrukertjenester. Autentiseringen blir utført av en OpenID Connect provider som utsteder ID-token til den aktuelle tjenesten.\n\n```mermaid\ngraph LR\n  end_user(Sluttbruker)\n  OP(ID-porten)\n  RP(Nett-tjeneste)\n  end_user -. autentiserer seg hos .-\u003e OP\n  OP -. utsteder id_token .-\u003e RP\n  end_user -. logger inn i  .-\u003e RP\n```\n\nFølgende aktører inngår:\n\n| Aktør | Beskrivelse | Begrep OIDC |\n| -|-|-|\n| Sluttbruker | Ønsker å logge inn til en offentlig tjeneste | End User |\n| Nett-tjeneste | Sluttbruker-tjeneste tilbudt av en offentlig etat | Relying Party (RP) / Client (=klient) |\n| ID-porten | ID-porten sin autentiseringstjeneste som usteder *ID-Token* til aktuelle tjenesten| OpenID Provider (OP) |\n\n## Beskrivelse av autorisasjonskode-flyten\n\n```mermaid\nsequenceDiagram\n  Sluttbruker -\u003e\u003e Relying Party: Klikker login-knapp\n  Relying Party -\u003e\u003e Sluttbruker: Redirect med autentiseringsforespørsel\n  Sluttbruker -\u003e\u003e OpenID Provider: følg redirect...\n  note over Sluttbruker,OpenID Provider: Sluttbruker autentiserer seg (og evt. samtykker til forespurte scopes)\n  OpenID Provider -\u003e\u003e Sluttbruker: Redirect med autorisasjonscode\n  Sluttbruker -\u003e\u003e Relying Party: følg redirect...\n  Relying Party -\u003e\u003e OpenID Provider: forespørre token (/token)\n  OpenID Provider -\u003e\u003e Relying Party: id_token (evt. flere tokens)\n  note over Sluttbruker,Relying Party: Innlogget i tjenesten\n```\n\n* Flyten starter med at en sluttbruker prøver å aksessere en gitt tjeneste ( Relying Party )\n* Tjenesten krever innlogging og en redirect url til OpenID Connect provideren blir generert og returnert til sluttbrukeren. Denne redirecten representerer en [**autentiseringsforespørsel**]({{site.baseurl}}/docs/idporten/oidc/oidc_protocol_authorize.html), og har parametere som identifiserer den aktuelle tjenesten for provideren.\n* Sluttbrukers browser kommer til **autorisasjonsendepunktet** hos provideren hvor forespørselen blir validert (f.eks. gyldig tjeneste og gyldig redirect_uri tilbake til tjenesten).\n* Brukeren gjennomfører **innlogging i provideren**\n* Provideren redirect'er brukeren tilbake til tjenestens forhåndsregistrere redirect url med en **autorisasjonskode**.\n* Tjenesten bruker den mottatte autorisasjonskoden til å gjøre et direkteoppslag mot providerens [**token-endepunkt**]({{site.baseurl}}/docs/idporten/oidc/oidc_protocol_token.html). Tjenesten må autentisere seg mot token-endepunktet, såkalt *klient-autentisering* (enten med client_secret eller en signert forespørsel)\n* Dersom klient-autentiseringen var velykket, valideres den mottatte autorisasjonskoden og et **ID-token** blir returnert til tjenesten.\n* Tjenesten omsetter normalt ID-tokenet til en egen, lokal sesjon.\n* Brukeren er nå autentisert for tjenesten og ønsket handling kan utføres\n\nMerk: OpenID Connect bygger på OAuth2, og denne flyten er derfinert i OAuth2-spesifikasjonen. Siden *autentisering* ikke er et begrep i OAuth2 vil en ofte se at begrepet *autorisasjon* blir brukt selv om man egentlig snakker om *autentisering*\n\n\n## Sesjonshåndtering\n\nMerk: Kunde og ID-porten holder egne sesjoner mot sluttbruker som ikke er avhengig av hverandre. Men Digitaliseringsdirektoratet anbefaler at kundene bruker samme sesjonstider som ID-porten.\n\n\n### Levetid for SSO-sesjonen i ID-porten\n\nI ID-porten måles maksimum sesjonstid for en brukers SSO-sesjon og denne settes til 120 minutter fra første autentisering.\n\nVed inaktivitet over 30 minutter, vil SSO-sesjonen utløpe.  Inaktivet måles som tiden mellom to autentiseringsforespørsler mot ID-porten.\n\nMerk at ved passivt utløp av sesjon så vil det ikke bli sendt noen kall til kundens tjeneste.\n\nMerk: id_tokenet returnert fra ID-porten vil inneholde en \"expire (exp)\" verdi. Denne verdien angir kun levetid for selve tokenet, dvs. en klient skal ikke akseptere et id_token etter at det utløpt. Denne verdien er ikke koblet mot den SSO-sesjonen hos ID-porten og gir ingen indikasjon på levetid på denne.\n\n### Levetid for kundens lokale sesjon\n\nI en føderasjon skal medlemmene konfigurere systemene slik at sesjoner utløper ved inaktivitet etter høyst 30 minutter.\n\nDet er valgfritt om timeout-perioden nullstilles hver gang brukerens nettleser forespør en av kundens tjeneste, eller om den er uavhengig av brukeraktivitet (fast timeout periode).\n\nEtter lokal timeout hos en kunde, skal brukerens nettleser ved neste http-forespørsel sendes over til ID-porten med en autentiseringsforespørsel.\n\nDet må bemerkes at lokal timeout hos en kunde ikke nødvendigvis medfører at brukeren blir tvunget til å logge på ID-porten. Hvis brukeren har en aktiv SSO-sesjon hos ID-porten, kan denne svare på forespørselen fra kunde uten brukerdialog (dvs. foreta single sign-on). Brukeren vil dermed ikke oppdage at sesjonen blir fornyet (bortsett fra at hans nettleser muligens ”blinker” et kort øyeblikk).\n\n### Tvungen re-autentisering\n\nHvis en tjenesteleverandør av sikkerhetsmessige grunner vil sikre seg at brukeren blir tvunget til aktiv pålogging i ID-porten, kan man sette parameteren prompt=login i autentiseringsforespørselen til ID-porten.  \n\nDet er også mulig å konfigurere tjenesten sin slik at den ikke deltar i felles SSO-sesjon (se [Isolert SSO-sesjon]({{site.baseurl}}/docs/idporten/oidc/oidc_func_nosso.html)).\n\n\n### Krav til utlogging\n\nID-porten tilbyr single signon-funksjonalitet (SSO) mellom alle integrerte tjenester.  **Derfor må alle tjenester også implementere støtte for single logout (SLO).**\n\n\n**En feilkonfigurert logout-håndtering hos én kunde kan ødelegge for utlogging hos andre kunder, og gjøre innbygger sårbar for angrep.**\n\nKlienten må håndtere to forskjellige utloggings-scenarier:\n\n1. **Brukeren logger ut fra din tjeneste:**  Du må redirecte brukeren til /endsession-endepunktet til ID-porten.  ID-porten sørger for å logge brukeren ut av alle andre tjenester, og redirecter til slutt brukeren tilbake til deg.\n\n2. **Brukeren logger ut fra annen tjeneste:** Du vil motta en front_channel_logout-melding med en sesjonsidentifikator `sid` som du tidligere har mottatt i id_token. Basert på denne må du finne lokal brukersesjon og invalidere denne.\n\n\n[Se full dokumentasjon om utlogging her]({{site.baseurl}}/docs/idporten/oidc/oidc_func_sso).\n\n\n## 1: Autentiseringsforespørsel til autorisasjons-endepunktet\n\nTjenesten/klienten sender en autentiseringsforespørsel ved å redirecte sluttbrukeren til autorisasjonsendepunktet.\n\nSe [detaljert dokumentasjon for autorisasjonsendepunktet]({{site.baseurl}}/docs/idporten/oidc/oidc_protocol_authorize) for valgmuligheter.\n\nKlienten må være forhåndsregistrert i ID-porten, se [klient-registrering]({{site.baseurl}}/docs/idporten/oidc/oidc_func_clientreg).\n\n\n### Eksempel på forespørsel\n\n```\n\nGET https://login.idporten.no/authorize?\n\n  client_id=min_tjeneste\u0026\n  redirect_uri=https%3A%2F%2Fmin.tjeneste.no%2Flogin_callback\u0026\n\n  scope=openid+profile\u0026\n  acr_values=idporten-loa-substantial\u0026\n  response_type=code\u0026\n  ui_locales=nb\u0026\n\n  state=sV-423vokts9_CZdO9KZSV9xb35mlgzj_7BPTt-_khQ\u0026\n  nonce=S6tRrJ3tWsilRZl7hqySoORosHDDq4l6du3dxDhXoWc\u0026\n  code_challenge=HC9NRzz4QUaVMvl2TUYrWg_L54PBleKON4hapcIOydk\n  code_challenge_method=S256\u0026\n\n```\n\nAlle tjenester må bruke [PKCE]({{site.baseurl}}/docs/idporten/oidc/oidc_func_pkce), og blir sterkt anbefalt å bruke state og nonce i kallet.\n\nFor tjenester med høye krav til sikkerhet bør en i tillegg vurdere å bruke [PAR]({{site.baseurl}}/docs/idporten/oidc/oidc_protocol_par) til å første POSTe autentiseringsparametrene direkte til ID-porten før en redirecter, slik at disse parametrene ikke blir eksponert for manipulasjon av brukers browser.\n\n## 2: Bruker autentiserer seg\n\nBruker vil så autentisere seg mot ID-porten.  ID-portens språk prioriteres slik:\n\n- Bokmål er standardspråk dersom ingenting er oppgitt\n- Dersom klient har oppgitt `ui_locales`, så vil dette språket bli brukt\n- Dersom cookien IDPORTEN_SELECTED_LANGUAGE-cookien er satt, vil dette overstyre andre valg. Cookien blir satt kun for brukere som aktiv endrer språk i ID-portens GUI.\n\n## 3: Redirect tilbake til tjenesten\n\nEtter at brukeren har logget inn vil det sendes en redirect tilbake til klienten til den forhåndsregistrerte `redirect_uri`.  Redirecten vil vil inneholde et autorisasjonskode-parameter `code` som  brukes til oppslag for å hente tokens.  Koden er base64-enkoda og URL-safe.\n\n\n\n### Eksempel på respons: {#authresponse}\n\n```\nGET https://min.tjeneste.no/login_callback?code=1JzjKYcPh4MIPP9YWxRfL-IivWblfKdiRLJkZtJFMT0\u0026state=min_egendefinerte_state_verdi\n```\nI testmiljø tillater vi redirect tilbake til localhost.\n\n## 4: Utstedelse av token fra token-endepunktet\n\nToken-endepunktet brukes for utstedelse av tokens.\n\n\nBruk av endepunktet varierer litt med hvilken klient-autentiseringsmetode som benyttes. Følgende autentiseringsmetoder fra [OIDC kap. 9](http://openid.net/specs/openid-connect-core-1_0.html#ClientAuthentication) støttes:\n\n* **client_secret_basic** / **client_secret_post** - Klientautentisering basert på client_secret\n* **private_key_jwt** - Klientautentisering basert på JWT'er signert med virksomhetssertifikater\n\nSistnevnte metode er anbefalt for klienter med høye krav til sikkerhet.\n\n##### Eksempel på forespørsel:\n\n\n```\nPOST /token\nContent-Type: application/x-www-form-urlencoded\nAuthorization: Basic bWluX3RqZW5lc3RlOnBhc3N3b3Jk\n\ngrant_type=authorization_code\u0026\n  redirect_uri=https%3A%2F%2Fmin.tjeneste.no%2Flogin_callback\u0026\n  code=1JzjKYcPh4MIPP9YWxRfL-IivWblfKdiRLJkZtJFMT0%3D\u0026\n  code_verifier=gEVARFlOi5LNYfVGSMHvhZCXoG_TPzdmXQQGqzKJkz0\n```\n\nSe [detaljert dokumentasjon for token-endepunktet]({{site.baseurl}}/docs/idporten/oidc/oidc_protocol_token) for alle valgmuligheter.  \n\nDersom forespørselen blir validert som gyldig, vil det returneres et eller flere token:\n\n* **id_token**: Autentiseringsbevis,  \"hvem brukeren er\"\n* **access_token**: Tilgangs-token, forteller \"hva brukeren kan få tilgang til\"\n* **refresh_token**: Brukes av klienten til å fornye access_token uten brukerinteraksjon (så lenge som autorisasjonen er gyldig)\n\n\n```\n{\n  \"access_token\" : \"eyJ4NWMiOlsiTUlJQ3NqQ0NBWnFnQXdJQkFnSUVZbSt1L3pBTkJna3Foa2lHOXcwQkFRc0ZBREFiTVJrd0Z3WURWUVFEREJCcFpIQnZjblJsYmkxemVYTjBaWE4wTUI0WERUSXlNRFV3TWpFd01UUXlNMW9YRFRJek1EVXdNakV3TVRReU0xb3dHekVaTUJjR0ExVUVBd3dRYVdSd2IzSjBaVzR0YzNsemRHVnpkRENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFMZTVuN3lXNFh2Y1J0d3RMazFVUEllakN5U3RmMUQ1akhCNnNQaUpSK3haR3JmejR4dXJJRlA4ekorbnI1OXRoblQrdVpuaFQwNzNwVUlNdkJsRCt1bjFiTWxENm9TZjJ6UTZpWmhFQ0V3bTBxdUk3RHpRcW93dGxGSUdxUTgzQ2Y4NEZjZDBVbVJiT0ZOUnJicDg3QkY2dkZzL3JsM0x0RHo4dXlWbVFXaGhubS9jR3F5ZGkxQWhXWi92YTVYdzR1SFoxYVNDOTgzK1EySllkSFZYRU45SXV4bWIvZVdlVmhzTVRXQ0FPbU4xMklvWVZHODFFOXMvMzJQZy82cFEyMkFNWjRqZzgwdGVMZTBZeWZGS2ppbUtWQnJkRTBnUXJmWThnemlBR3kwYnhhQTRBNTlneUZmcldKRTNhOE5tSHZxTHhhTE4yQ0hzcXhsQVhuRkNZd2NDQXdFQUFUQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFqY3NOVk43T0R2K1VDdlhGSVdnck0xQll4TGR0QTkvZ0QvU3ZzcGdIcjY5dUlPcHRxVTY1cklrMmllMDhPcjZRZXpTVnVRdkJ5a1U3cXgrZVFmV1N1OG1rWDRZa0VWcXBzYnh6Q0hneWEvTXJINzd2ZmV2UlhNRkk1QUlaVDU4TDdjSGovOWFYelpsRXhEVGo5bE5makFjcktCNm5kRS9rZVErUkUrdGdvM0c1Q0srVktINkJaMFJtOXQySDZBKzZxbEFZS0FCTFZ2dGFjekdKU3BQNUxrcGw0T1BscE5pY2M3MDVuQnpzYnBvMGd1WThNQjdqQnlKVWJRcXd6MCtkd3NNMWNQNkNTbFNUc3FNUWJaVjAzd1lCT014Si93dUt1Nnlyc0ZUV21sUi8rSGhvU3VkNUVBSnJHSGwvbnR6RmNBTExIcUk0dG92UFRkcGJTTVlnOXc9PSJdLCJraWQiOiJ1clFQU1pDU1hYSkhiTm9XMFZFbmtCcWJOZDFDeXdmT1RJZGNxQlRISk9FIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJFUklGdnBEN3BNNmo2WHZybnowbWw1M1YtTF9XNVpEU3Mza1lNczZkVFZjIiwiYWNyIjoiaWRwb3J0ZW4tbG9hLXN1YnN0YW50aWFsIiwic2NvcGUiOiJvcGVuaWQgcHJvZmlsZSIsImlzcyI6Imh0dHBzOi8vaWRwb3J0ZW4uZGV2IiwiY2xpZW50X2FtciI6ImNsaWVudF9zZWNyZXRfYmFzaWMiLCJwaWQiOiIyMTg3OTQ5ODAxMiIsImV4cCI6MTY3ODM3NjA5MiwiaWF0IjoxNjc4Mzc1NDkyLCJqdGkiOiJVUHc4YTYtdUtHbyIsImNsaWVudF9pZCI6ImRlbW9jbGllbnRfaWRwb3J0ZW5fc3lzdGVzdCIsImNvbnN1bWVyIjp7ImF1dGhvcml0eSI6ImlzbzY1MjMtYWN0b3JpZC11cGlzIiwiSUQiOiIwMTkyOjk5MTgyNTgyNyJ9fQ.CD2j7-F3GCggX0Owh_dm-hZzLxq8RIj2Ry51B2-KrIBD4QzmsHQ9KrsNgtL9YFBLajcUqEm2QPTniTo8_JZqP_DyjiaOFV0mati84ifoIEziuHH9MXb0MiFtO0hlpFdic-i_zoiO7IBal0htCkt2kTrSKokYMp2U4dnuMkw32aK45HCHt2h1P2HWuI4EBk_KAFsOEdO2wCAJHS9jH4WTf7Q-Xx1TyzEbnsb8LuvJ8vOxKCzHgPkR5LCgdXq7gYUOxSuORYa_9MEhAnLi0riRTAMxngB3pk8ZvrrJTscC0zE0a5-xjqA0BJ9bqaHrobP13LKXRR-ol1WHTb4QHH1-qg\",\n  \"refresh_token\" : \"eyJlbmMiOiJBMTI4Q0JDLUhTMjU2IiwiYWxnIjoiZGlyIn0..WES9oML4Je5S3qxXSPZOXg.5dJtItCTk7920ihGtylDL3ytHmA-yjaN1F0FDa2zn560A6RPga5R9BUYDEZDCVzAHtaewsdg4W_b79daTjVinTY5wqSfi5fb4JnwATx1ecxu2Pjo4QronnfZrBSD3ezCrvgcxtAFJ1w9uJymYhCbWc8rqL7X7H5wdHmNTbUzaT_WGL1Ymvqe4KDgF2XLuvpxs81sWJtgW5P1vaTrf58sA_oDUJZC9qZHNrIgW4JNp7E9au0cX5H0kF1wrGnkgiALAPVYqRJsd9IDc0kLnUKvtVKKRAja098CgpmPRSs61KVz-nPmtNvVMZJXmqsQnvW9qimkxPtnTUnxyFtKiHdB-wc2Q8Gv5bUC3w7BZR5-F_DfCVzcxlraay2fSN1gWpSdR7nFqsJI4TQNBUcPEKvV3wKxdAcQgrxgYtP0jQnZ14NvaNzO5eVE1DILXznWICZ5LGpzXb7vd7Sfk23kXX7xs7beGQ5dqRnnK9hH5NEBsW1rbDOlbPES5fDrWII0n9i9-aKWBVBbi34qkQL-nKtl-WxH1bJD2FhPZw3LEfuKk_XUDkMFGfP2uoFtf7KUjb7pfqFf9d8R_ZswFH6jYDd-ohzS6p-04GC71Sw8uWCpTraYtNNkOhkqVapOKN-K2U_6oquqqJXInrXZ0Ng-PL4UOdA75I_ccGTtKd-9jjnzwoxF3wDLRy0OwwkHPdvMSYo-KEK4fBcaOFQXCu7wU-IbzF96vOESDtPi4Xho2iuTsb-NSl2WpW4P7rVxFhJsjH0g7a64278vgYx5b9nvpQkjnh-42B-xgvcQsfATnW4cffa4xGQ-QpnxI2U9FRSWBcI_7vdkdVPpilum39ub-8Qv5V-cDje6cuOLj-izJDhHtT8GisRxOAzUlkBkkonmMyxgJaCR4L0QjSBpQpemD44sKQxIOYFNjT7AcAOR5EsHwiABzAgiJIe1erZpno8Zrbh2RWg7mUs4__Kvhzpxr8hjqbldUJI4okhg9SrWpFqoJoa7syNKv_lfm8twCDGAUmfRlk8TTdXrkhEr1bXpS3Q54kLtfVbKfkGWdHVanv1aIeTFCGbN2PXGk29Q2B6yAvyVoHFLm7gniZJKmZByYDtCvF5qwbVkmPi3vNOOQma9kOo_y8Gx--FVoZ0l5ST2MJx0T3FadspcR75HCP5WEARyktuYlJG2PxvPtNBNf7E6Tak3yS8p3pQzyeeVwYgNFkGpMdmax7aCAQEAm-5x7uXmX_1b6S7SX94uqh4pxYWvy0eLHmD3mtmfzfSQBgLEr7VSZVskM8MPHsUrO4wIhwXWjyV_NTRN9Jeofb3Zvmw1jsqK3vxVdHhc6iZwpRrbyWkQdb-MN9uv3cR4Dki1yXo3p50xL21BZMJB1SH_eHwTpWMJhZ1MjMV2VTRooJ3Nh4MiMMkZ7UTRPjLsI9UwsaonzexM1ApE7eT2UxxGUZNUd5JE0--7WDcowp45E0Hb2r6EFH2wLrFOAPuzhsYG3d88x_-VySUhvnzGV8C-9bjGZKoH1cdvq_ToqejytTpYzZ9QwOSwaPIypOauSGX6W7ruCKy9YbZgIngD8z0uxlXmQzm8v6jIVAZmLktVjHfY5gUm94hNF7HckDahlmtz2izYhSaVZA3vsaNPDDTmqNAalyD2zuelD-084_UdoKBRoSBFf1WaDBO1c0-SBqeBDFfM45EaYsAUZaYb133XM78W-MYA0xLGGQ1yLsqB7GQjlPRIK9HtO9YfpXIeSJ2culmPIopSBwkrvhCFOi5lZdkj2_Q.h25pAv8_-iKYQgxPtcF5iQ\",\n  \"scope\" : \"openid profile\",\n  \"id_token\" : \"eyJ4NWMiOlsiTUlJQ3NqQ0NBWnFnQXdJQkFnSUVZbSt1L3pBTkJna3Foa2lHOXcwQkFRc0ZBREFiTVJrd0Z3WURWUVFEREJCcFpIQnZjblJsYmkxemVYTjBaWE4wTUI0WERUSXlNRFV3TWpFd01UUXlNMW9YRFRJek1EVXdNakV3TVRReU0xb3dHekVaTUJjR0ExVUVBd3dRYVdSd2IzSjBaVzR0YzNsemRHVnpkRENDQVNJd0RRWUpLb1pJaHZjTkFRRUJCUUFEZ2dFUEFEQ0NBUW9DZ2dFQkFMZTVuN3lXNFh2Y1J0d3RMazFVUEllakN5U3RmMUQ1akhCNnNQaUpSK3haR3JmejR4dXJJRlA4ekorbnI1OXRoblQrdVpuaFQwNzNwVUlNdkJsRCt1bjFiTWxENm9TZjJ6UTZpWmhFQ0V3bTBxdUk3RHpRcW93dGxGSUdxUTgzQ2Y4NEZjZDBVbVJiT0ZOUnJicDg3QkY2dkZzL3JsM0x0RHo4dXlWbVFXaGhubS9jR3F5ZGkxQWhXWi92YTVYdzR1SFoxYVNDOTgzK1EySllkSFZYRU45SXV4bWIvZVdlVmhzTVRXQ0FPbU4xMklvWVZHODFFOXMvMzJQZy82cFEyMkFNWjRqZzgwdGVMZTBZeWZGS2ppbUtWQnJkRTBnUXJmWThnemlBR3kwYnhhQTRBNTlneUZmcldKRTNhOE5tSHZxTHhhTE4yQ0hzcXhsQVhuRkNZd2NDQXdFQUFUQU5CZ2txaGtpRzl3MEJBUXNGQUFPQ0FRRUFqY3NOVk43T0R2K1VDdlhGSVdnck0xQll4TGR0QTkvZ0QvU3ZzcGdIcjY5dUlPcHRxVTY1cklrMmllMDhPcjZRZXpTVnVRdkJ5a1U3cXgrZVFmV1N1OG1rWDRZa0VWcXBzYnh6Q0hneWEvTXJINzd2ZmV2UlhNRkk1QUlaVDU4TDdjSGovOWFYelpsRXhEVGo5bE5makFjcktCNm5kRS9rZVErUkUrdGdvM0c1Q0srVktINkJaMFJtOXQySDZBKzZxbEFZS0FCTFZ2dGFjekdKU3BQNUxrcGw0T1BscE5pY2M3MDVuQnpzYnBvMGd1WThNQjdqQnlKVWJRcXd6MCtkd3NNMWNQNkNTbFNUc3FNUWJaVjAzd1lCT014Si93dUt1Nnlyc0ZUV21sUi8rSGhvU3VkNUVBSnJHSGwvbnR6RmNBTExIcUk0dG92UFRkcGJTTVlnOXc9PSJdLCJraWQiOiJ1clFQU1pDU1hYSkhiTm9XMFZFbmtCcWJOZDFDeXdmT1RJZGNxQlRISk9FIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJFUklGdnBEN3BNNmo2WHZybnowbWw1M1YtTF9XNVpEU3Mza1lNczZkVFZjIiwiYW1yIjpbIlRlc3RJRCJdLCJpc3MiOiJodHRwczovL2lkcG9ydGVuLmRldiIsInBpZCI6IjIxODc5NDk4MDEyIiwibG9jYWxlIjoibmIiLCJub25jZSI6IlM2dFJySjN0V3NpbFJabDdocXlTb09Sb3NIRERxNGw2ZHUzZHhEaFhvV2MiLCJzaWQiOiJpWlpicC1hX3dTVWZmT1N3bW4xV2VvOUVvYXV5eVFMNnBxdjBfLThiUkhrIiwiYXVkIjoiZGVtb2NsaWVudF9pZHBvcnRlbl9zeXN0ZXN0IiwiYWNyIjoiaWRwb3J0ZW4tbG9hLXN1YnN0YW50aWFsIiwiYXV0aF90aW1lIjoxNjc4Mzc1NDkxLCJleHAiOjE2NzgzNzU2MTIsImlhdCI6MTY3ODM3NTQ5MiwianRpIjoicHJrUW91Y1FKZjgifQ.rRaBSFextSifr-VsClfaJzHW9Eb5eg_BKw5OLf6MOvAU8S4C1sqz-R0y7eCPk4zPbj6H2ZLB5MVbFEa-vy1Io9COqU9-9Uh1gi0Qg58ECoMjb5tXyWA5_Vg9IiGhiAC3EfqF5L1gyMd84KNbkNF22Bx-atI1IZq2hsW6FkfK5fn2tWHfYdofOL8oiQRlwU78JaoMxRq_buc3jKf8pc0fB08VGT-RDJKlEr6ha7Z3K5Q7i-EUwLmlqRoW1Hi-PQhSgPYEVjSJ1FcB1V-R24AGCu6NF6Ax3F24Su4WLw_cEWYDu6FAbefvQrg6lBVdpN029-O1OZlLduembjOB96UgMg\",\n  \"token_type\" : \"Bearer\",\n  \"expires_in\" : 600\n}\n```\n\n\n\n### id_token\n\nid_tokenet inneholder identiteten til den autentiserte brukeren - det forteller det hvem brukeren er, men ikke hvilke tilganger brukeren har.\n\nNormal bruker tjenesten id_tokenet kun til å opprette en egen, lokal sesjon.  Id_tokenet har derfor en ganske kort gyldighetsperiode.\n\n#### Eksempel:\n```\n{\n  \"sub\": \"ERIFvpD7pM6j6Xvrnz0ml53V-L_W5ZDSs3kYMs6dTVc\",\n  \"amr\": [\n    \"TestID\"\n  ],\n  \"iss\": \"https://idporten.no\",\n  \"pid\": \"21879498012\",\n  \"locale\": \"nb\",\n  \"nonce\": \"S6tRrJ3tWsilRZl7hqySoORosHDDq4l6du3dxDhXoWc\",\n  \"sid\": \"iZZbp-a_wSUffOSwmn1Weo9EoauyyQL6pqv0_-8bRHk\",\n  \"aud\": \"min_tjeneste\",\n  \"acr\": \"idporten-loa-substantial\",\n  \"auth_time\": 1678375491,\n  \"exp\": 1678375612,\n  \"iat\": 1678375492,\n  \"jti\": \"prkQoucQJf8\"\n}\n```\n\n\n**Korrekt validering av id_token** av klienten er kritisk for sikkerheten i løsningen. Det er spesielt viktig å validere at faktisk brukt sikkerhetsnivå `acr` er ihenhold til forespurt nivå.\n\nTjenesteleverandører som tar i bruk tjenesten må utføre validering i henhold til kapittel [3.1.3.7 - ID Token Validation i OpenID Connect Core 1.0 spesifikasjonen](https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation).\n\n[Klikk her for full dokumentasjon av id_token i ID-porten]({{site.baseurl}}/docs/idporten/oidc/oidc_protocol_id_token).\n\n\n\n### access_token\n\nAccess_tokenet (tilgangstoken) gir klienten [tilgang til APIer hos tredjepart]({{site.baseurl}}/docs/idporten/oidc/oidc_auth_oauth2) på vegne av den autentiserte brukeren.  \n\nLevetiden på aksess_tokenet er som oftest relativt kort (typisk 120 sekunder). Dersom tokenet er utløpt, kan klienten forespørre nytt acess_token ved å bruke refresh_tokenet. Det gjennomføres da en klient-autentisering, for å sikre at tokens ikke blir utlevert til feil part.\n\nLevetider kan også tilpasses per klient. Men merk at dette kan overstyres av API-tilbyder alt etter [hvilke oauth2 scopes]({{site.baseurl}}/docs/idporten/oidc/oidc_protocol_scope) som er i tokenet. \n\nDet er viktig å være klar over at access_token+refresh_token er **uavhengig** av innlogginga og tilhørende SSO-sesjon i ID-porten.  Selv om brukeren gjennomfører en utlogging, eller sso-sesjonen timer ut, så vil normalt autorisasjonen med tilhørende access_token og refresh_token være gyldige fram til deres levetider utløper.   \n\nMerk til slutt at en enkelt bruker bare kan ha en autorisasjon mot samme klient om gangen. Dersom klienten har en gyldig autorisasjon med gitte scopes, og så utfører en ny autorisasjon med andre scopes, så vil ny access_token kun inneholde scopene fra den nyeste autorisasjonen. ID-porten \"husker\" altså ikke samtykkede scopes over flere autorisasjoner. \n\n[Klikk her for full dokumentasjon av access_token-formatet til ID-porten]({{site.baseurl}}/docs/idporten/oidc/oidc_protocol_access_token).\n\n\n\n## 5: Userinfo-endepunkt\n\nVed å forespørre scopet *profile* vil klienttjenesten sammen med id tokenet også få utstedt et access_token (og evnt. refresh_token) som kan benyttes mot providerens userinfo-endepunkt.\n\nDette endepunktet kan i henhold til standarden benyttes for å hente ytterligere data om brukeren enn det som blir eksponert via ID tokenet. Da ID-porten generelt har lite data om sluttbrukeren har dette endepunktet begrenset verdi i de fleste tilfeller. Personnummer og valgt språk under innlogging er de\ndataene som vil bli eksponert her.\n\n\n```\nGET https://\u003c\u003cmiljø\u003e\u003e/idporten-oidc-provider/userinfo\nAuthorization: Bearer eyJA...\n\nRespons:\n{\n  \"sub\" : \"NR8vTTPrM3T7rWf8dXxeWLZpxEMsug4E7pxqJuh9wIM=\",\n  \"pid\" : \"23079421936\",\n  \"locale\" : \"nb\"\n}\n```\n\n\n## 6: Kontaktopplysninger fra Kontakt- og Reservasjonsregisteret\n\nKontakt-opplysninger knyttet til innlogget bruker, er [tilgjengelig på et eget endepunkt]({{site.baseurl}}/docs/Kontaktregisteret/Brukerspesifikt-oppslag_rest) dersom access_token inneholder `krr:user/kontaktinformasjon.read`-scopet.\n\n\n\n## Om OpenID Connect\n\nOpenID Connect er en protokoll for autentisering basert på OAuth2. Se [http://openid.net/connect/faq/](http://openid.net/connect/faq/) for mer informasjon.\n\nDe implementerte tjenestene bygger på (deler av) følgende standarder og spesifikasjoner:\n\n* OpenID Connect Core 1.0 - [http://openid.net/specs/openid-connect-core-1_0.html](http://openid.net/specs/openid-connect-core-1_0.html)\n* OpenID Connect Discovery\n[http://openid.net/specs/openid-connect-discovery-1_0.html](http://openid.net/specs/openid-connect-discovery-1_0.html)\n\n* OpenID Connect Session Management\n[http://openid.net/specs/openid-connect-session-1_0.html](http://openid.net/specs/openid-connect-session-1_0.html)\n* OpenID Connect Front-Channel Logout\n[http://openid.net/specs/openid-connect-frontchannel-1_0.html](http://openid.net/specs/openid-connect-frontchannel-1_0.html)\n* OAuth 2.0 Form Post Response Mode\n[http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html](http://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html)\n* OAuth 2.0 Token Introspection\n[https://tools.ietf.org/html/rfc7662](https://tools.ietf.org/html/rfc7662)\n* Proof Key for Code Exchange by OAuth Public Clients\n[https://tools.ietf.org/html/rfc7636](https://tools.ietf.org/html/rfc7636)\n\n* IETF RFC6749 The OAuth 2.0 Authorization Framework - [https://tools.ietf.org/html/rfc6749](https://tools.ietf.org/html/rfc6749)\n* IETF RFC7523 JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants - [https://tools.ietf.org/html/rfc7523](https://tools.ietf.org/html/rfc7523)",
+    "lang": "nb",
+    "path": "/nb/start/oidc/idporten/integration_guide"
+  },
+  {
+    "id": "nb-start-oidc-maskinporten-general",
+    "title": "Generelt om maskinporten",
+    "content": "# Generelt om maskinporten\n\n## Overordnet arkitekturbeskrivelse\n\nMaskinporten er en tjeneste som tilbyr en enkel modell for API-sikring basert på OAuth2 protokollen og bruk av JWT-bearer grants, inspirert av [Google sine system-kontoer](https://developers.google.com/identity/protocols/OAuth2ServiceAccount).\n\nMaskinporten lar API-tilbydere definere tilganger til sine API, modellert som scopes, basert på konsumenten sine organisasjonsnummer.\nDette kan gjøres via Maskinporten sine selvbetjeningsAPI eller webløsning.\n\n```mermaid\ngraph LR\n  subgraph API-tilbyder\n    API[API manager]\n  end\n  subgraph Digdir\n    MP[Maskinporten]\n  end\n\n  API --\u003e|Gir tilgang til scope for API-konsument|MP\n\n```\n\nForutsatt at de riktige tilgangene er gitt, kan API-konsumenter nå opprette sine API-klientregistreringer med de tildelte scopene:\n\n```mermaid\ngraph LR\nsubgraph Digdir\n  MP[Maskinporten]\nend\n  subgraph API-konsument\n    client[Administrasjonsklient]\n  end\n\n  client --\u003e|opprette / endre klient med tildelte scopes |MP\n  MP --\u003e|ny / endret klientregistrering|client\n```\n\nNår klientene er registrert kan disse brukes for å få tildelt token og gjennomføre api-kallene.\n\n```mermaid\ngraph LR\n  subgraph API-tilbyder\n    API\n  end\n  subgraph Digdir\n    Maskinporten[Maskinporten]\n  end\n  subgraph API-konsument\n     ny[Klient]\n  end\n  Maskinporten --\u003e|2.utsteder token med tildelt scope|ny\n  ny --\u003e|1.forspør tilgang til scope|Maskinporten\n  ny --\u003e|3.bruker token mot|API\n```\n\nAPI-konsumenter kan selv administrere sine klientkonfigurasjoner og registrere disse med tildelte scopes fra tilbyderene.\n\nAPI-tilbydere og konsumenter kan bruke denne tjenesten for å styre tilgang i de tilfellene der informasjonsverdiene APIet tilbyr er regulert av lovhjemmel, og ikke krever samtykke av brukeren.\n\nBruk av Maskinporten krever at begge aktørene bruker Maskinporten sin selvbetjeningsfunksjonalitet, enten gjennom webløsningen eller selvbetjeningsAPIet.",
+    "lang": "nb",
+    "path": "/nb/start/oidc/maskinporten/general"
+  },
+  {
+    "id": "nb-start-oidc-maskinporten-integration_guide",
+    "title": "Integrasjonsguide",
+    "content": "# Integrasjonsguide\n\nSitronkake og mozell",
+    "lang": "nb",
+    "path": "/nb/start/oidc/maskinporten/integration_guide"
+  },
+  {
+    "id": "nb-start-oidc-on_behalf_of",
+    "title": "OnBehalfOf",
+    "content": "# OnBehalfOf\n\n## Om funksjonaliteten\n\n*Onbehalfof* gjer det mogleg for tjenesteleverandørar å tilby tjenester til ulike kunder over same integrasjon.\n\n* Gir mulighet til å ha ulike navn, logo og tilbake-url\n* Statistikk / fakturering går til riktig tjenesteeier\n\nMerk at en onbehalfof-integrasjon IKKE gir tilgang til scopes som egen kunde har fått tilgang til.\n\n## Bruk\n\nAutentiseringsrequest må inneholde ekstra parameter ```onbehalfof```:\n\n```\nhttps:/…./authorize?client_id=test_client\u0026onbehalfof=leikanger_kommune\u0026...\n```\n\nReturnert ID-token vil då innehalde eit nytt claim ```client_onbehalfof```:\n\n```\n{\n  …\n  aud: \"test_client\"\n  aud_onbehalfof: \"leikanger_kommune\"\n  …\n}\n```\n\nKlient må validere at returnert \"client_onbehalfof\" stemmer overens med forespurt onbehalfof-verdi.\n\nKombinasjonen av client og client_onbehalfof må vere pre-registrert hjå ID-porten.",
+    "lang": "nb",
+    "path": "/nb/start/oidc/on_behalf_of"
+  },
+  {
+    "id": "nb-start-oidc-pkce",
+    "title": "Untitled",
+    "content": "#PKCE\n\n## Om funksjonaliteten\n\nPKCE - Proof Key  for Code Exchange - (uttales \"pixy\") er en metode som beskytter både public klienter som benytter autorisasjonskodeflyten (typisk mobil-app'er) mot stjeling av autorisasjonskoden, men også mot CSRF-angrep.\n\nPKCE er definert i [RFC7636](https://tools.ietf.org/html/rfc7636), og vi henviser til denne for detaljert dokumentasjon av funksjonaliten.\n\nMetoden er basert på  følgende steg:\n\n1. klienten genererer en hemmelighet `code_verifier` ved hver innlogging.  \n2. I /authorize-kallet sendes en hash'et versjon `code_challenge` av hemmeligheten som en del av forespørselen\n3. I /token-kallet må `code_verifier` sendes med. En eventuell angriper som har snappet opp autorisasjonskoden underveis, kjenner ikke hemmeligheten, og vil derfor ikke få utlevert tokens.\n\nVi støtter bare `code_challenge_method=S256`\n\n**Merk at code_verifier må være minst 43 karakterer lang, og ikke lengre enn 128.**\n\nDersom `code_verifier` er `xyo94uhy3zKvgB0NJwLms86SwcjtWviEOpkBnGgaLlo` så blir utrekna `code_challenge` lik `b7elB7ZyxIXgFyvBznKvxl7wOB-H17Pz0a3B62NIMFI`.  Code challenge skal ikke bruke padding.\n\n[Her er et verktøy for å rekne ut challenges:](https://gist.github.com/tonyxu-io/21eb57ab2a4aeb2a3ee10f77542abe64)\n\n\n### PKCE er som hovedregel påkrevd\n\nOppdaterte sikkerhetsanbefalinger fra IETF er klare på at bruk av PKCE er beste praksis, og det er påkrevd i Oauth 2.1-standarden.\n\nDerfor må alle klienter i ID-porten bruke PKCE, hvis ikke vil ID-porten som hovedregel avvise autentiseringsforespørselen.  \n\nMen for kunder med mindre sikker integrasjonsprogramvare som ennå ikke støtte PKCE, så er det er mulig å bruke [selvbetjening]({{site.baseurl}}/docs/idporten/oidc/oidc_func_clientreg.html) til å **nedgradere** klienten sin til omgå ID-portens tvungne PKCE-validering, dette gjøres ved å sette `code_challenge_method` på klienten til \"none\".\n",
+    "lang": "nb",
+    "path": "/nb/start/oidc/pkce"
+  },
+  {
+    "id": "nb-start-oidc-post_logout_redirect_uri",
+    "title": "Post logout redirect URI-er",
+    "content": "# Post logout redirect URI-er\n\n## Formål\n\nPost logout redirect URI-er er adresser brukeren kan sendes til etter at en sentral utloggingsprosess er fullført.\n\nDette brukes for å gi en kontrollert avslutning av brukerreisen etter logout.\n\n## Teknisk virkemåte\n\nNår brukeren logger ut hos autorisasjonsserveren, kan vedkommende omdirigeres tilbake til en registrert adresse hos klienten. Denne adressen kan brukes til å:\n\n- vise bekreftelse på utlogging\n- tilby ny innlogging\n- sende brukeren til startside eller annen definert landingsside\n\n### Sikkerhet\n\nSom med redirect URI-er må også disse adressene være forhåndsregistrert, for å unngå åpen redirect og uønsket videresending.\n\n## Bruk i OIDC-klienter\n\n### ID-porten og Ansattporten\n\nDette er relevant for klienter som deltar i sentral logout og ønsker å styre hvor brukeren havner etter utlogging.\n\n### Maskinporten\n\nDette er normalt ikke relevant i Maskinporten, siden det ikke er en sluttbrukerbasert nettlesersesjon som skal avsluttes.\n",
+    "lang": "nb",
+    "path": "/nb/start/oidc/post_logout_redirect_uri"
+  },
+  {
+    "id": "nb-start-oidc-redirect_uri",
+    "title": "Redirect URI-er",
+    "content": "# Redirect URI-er\n\n## Formål\n\nRedirect URI-er er adresser autorisasjonsserveren har lov til å sende brukeren tilbake til etter en autorisasjons- eller autentiseringsprosess.\n\nDette er en grunnleggende sikkerhetsmekanisme i OAuth 2.0 og OpenID Connect.\n\n## Teknisk virkemåte\n\nI en typisk `authorization_code`-flyt skjer dette slik:\n\n1. Klienten sender en autorisasjonsforespørsel med ønsket redirect URI.\n2. Autorisasjonsserveren kontrollerer at URI-en er registrert for klienten.\n3. Etter vellykket autentisering returneres brukeren til denne adressen.\n4. Responsen inneholder typisk en autorisasjonskode.\n\n### Hvorfor eksakt registrering er viktig\n\nRedirect URI-er må normalt samsvare nøyaktig med det klienten bruker i forespørselen. Dette reduserer risikoen for at autorisasjonskode eller andre parametere sendes til feil mottaker.\n\n## Bruk i OIDC-klienter\n\n### ID-porten\n\nRedirect URI-er er en sentral del av innlogging via ID-porten, siden autorisasjonskoden returneres til klientens registrerte adresse.\n\n### Ansattporten\n\nDet samme gjelder for Ansattporten, der korrekt registrering er nødvendig for at autorisasjonsflyten skal fungere og være sikker.\n\n### Maskinporten\n\nRedirect URI-er er normalt ikke relevante i klassiske Maskinporten-flyter, siden disse ikke er basert på nettleserredirect og interaktiv brukerinnlogging.\n",
+    "lang": "nb",
+    "path": "/nb/start/oidc/redirect_uri"
+  },
+  {
+    "id": "nb-start-oidc-refresh_token_lifetime",
+    "title": "Refresh token levetid",
+    "content": "# Refresh token levetid\n\n## Formål\n\nRefresh token levetid angir hvor lenge et refresh token kan brukes til å hente nye access tokens.\n\nDette setter en øvre grense for hvor lenge en klient kan videreføre tilgang uten ny autentisering.\n\n## Teknisk virkemåte\n\nSå lenge refresh tokenet er gyldig og ikke er tilbakekalt eller ugyldiggjort, kan klienten bruke det til å få utstedt nye access tokens.\n\n### Sikkerhetsvurdering\n\nJo lenger levetid et refresh token har, desto mer verdi har det dersom det kommer på avveie. Lang levetid bør derfor kombineres med tiltak som:\n\n- sikker lagring\n- rotasjon\n- tilbakekalling\n- overvåking av mistenkelig bruk\n\n## Bruk i OIDC-klienter\n\n### ID-porten og Ansattporten\n\nDette er relevant for klienter som ønsker langvarige brukerøkter, men må balanseres mot krav til sikkerhet og hvor følsomme data klienten gir tilgang til.\n\n### Maskinporten\n\nRefresh token levetid er normalt ikke en sentral parameter i klassiske Maskinporten-scenarier.\n",
+    "lang": "nb",
+    "path": "/nb/start/oidc/refresh_token_lifetime"
+  },
+  {
+    "id": "nb-start-oidc-refresh_token_usage",
+    "title": "Refresh token bruk",
+    "content": "# Refresh token bruk\n\n## Formål\n\nRefresh token bruk beskriver hvordan refresh tokens håndteres i praksis, utover bare om de er tillatt eller ikke.\n\nDette kan omfatte regler for utstedelse, gjenbruk, rotasjon og ugyldiggjøring.\n\n## Teknisk virkemåte\n\nI en enkel modell kan samme refresh token brukes flere ganger så lenge det er gyldig. I en strengere modell kan hvert bruk føre til at:\n\n- et nytt refresh token utstedes\n- det gamle ugyldiggjøres\n- misbruk lettere kan oppdages\n\n### Sikkerhetsbetydning\n\nValg av modell påvirker hvor robust løsningen er mot tokenlekkasje og replay. Jo mer langlivet og gjenbrukbart et refresh token er, desto viktigere er det med sterk beskyttelse.\n\n## Bruk i OIDC-klienter\n\n### ID-porten og Ansattporten\n\nFor klienter som trenger vedvarende brukerøkter, bør refresh token bruk vurderes sammen med tokenlagring, levetider og eventuelle krav til rotasjon.\n\n### Maskinporten\n\nDette er normalt ikke et sentralt tema i Maskinporten-integrasjoner, siden mønsteret der som regel ikke er bygget rundt refresh token-baserte brukerøkter.\n",
+    "lang": "nb",
+    "path": "/nb/start/oidc/refresh_token_usage"
+  },
+  {
+    "id": "nb-start-oidc-sso",
+    "title": "SSO",
+    "content": "# SSO\n\n## Om funksjonaliteten\nID-porten har siden oppstarten tilbudt single-signon (SSO), ved at alle tjenestene i føderasjonen tilhører samme Circle-of-Trust (CoT). Dette er en viktig funksjonalitet for å at innbygger skal ha en friksjonsfri opplevelse ved bruk av offentlige digitale tjenester, ved at man slipper hyppig re-autentisering.  Spesielt for samensatte tjenester, for eksempel såkalte lenketjenester, der innbygger \"hopper\" mellom ulike etater som del av en komplett tjenesteleveranse, er SSO en nøkkelfunksjonalitet.\n\nLike viktig som single signon er single logout.  Det er vesentlig for sikkerheten til innbygger at hen blir logget ut av alle tjenester når hen klikker logout. **En feilkonfigurert logout-håndtering hos én kunde kan ødelegge for utlogging hos andre kunder, og gjøre innbygger sårbar for angrep.**\n\n## Single Signon (SSO)\nSSO-sesjonen er felles for både OIDC- og SAML-baserte tjenester, og er fra nov. 2023 styrt av Nye ID-porten (OIDC). Sesjonslevetid er felles for alle tjenester uavhengig av sikkerhetsnivå, og denne er 30 minutter, men kan forlenges uten brukerinteraksjon inntil maksimalt 120 minutter, ved å sende en ny autentiseringsforespørsel.\n\nAlle tjenester er i utgangspunktet med i samme circle-of-trust, men tjenester kan tvinge frem re-autentisering ved å sette attributten *prompt* til `login` i [autentiseringsforespørselen](http://openid.net/specs/openid-connect-core-1_0.html#AuthRequest) (tilsvarende *forceAuth* i SAML2).  Det er i ny løsning også mulig å konfigurere en integrasjon til å bruke [isolert SSO-sesjon]({{site.baseurl}}/docs/idporten/oidc/oidc_func_nosso).\n\nMerk at levetiden på SSO-sesjonen ikke har noen sammenheng med levetiden på utstedte access-token og evt. refresh-tokens.\n\n## Single Logout (SLO)\nAlle OIDC-integrasjoner mot ID-porten må implementere støtte for følgende to utloggings-scenario:\n\n* Utlogging initiert fra egen tjeneste (endsession)\n* Utlogging initiert fra andre tjenester (front-channel logout)\n\nMerk at klienter som utfører endsession OGSÅ vil selv motta et frontkanal-utloggingskall dersom klienten har registrert en `frontchannel_logout_uri`.\n\nMerk at ID-porten nå støtter [back-channel logout]({{site.baseurl}}/docs/idporten/oidc/oidc_func_backchannel_logout).\n\n\nFor SAML-baserte tjenester må også begge utloggingsscenarioene støttes, men oppførselen er ulik - der OIDC sender frontkanalskallene fra iframer på en idporten-styrt side, så vil SAML foreta en kjede av redirects fra tjeneste til tjeneste. SAML-varianten er defor mer sårbar.\n\n### 1: Utlogging fra egen tjeneste (/logout)\n\nNår brukeren vil logge ut fra din tjeneste, må du sende en redirect (fortrinnsvis POSTe den) til ID-portens endsession-endepunkt `end_session_endpoint`. Se [detaljert grensesnittsdefinisjon her](oidc_protocol_logout.html).\n\n\nEksempel:\n```\nPOST https://idporten.no/logout\n\nid_token_hint=eyJraWQiOiJpZ2I1Q3lGT...\npost_logout_redirect_uri=\u003cmin registrerte post-logout uri \u003e\nstate=\u003ctilstand_jeg_kan_bruke_i_redirect_tilbake_til_meg_pluss_csrf_beskyttelse\u003e\n\n```\n\nVed mottak av endsession-redirect, vil ID-porten logge brukeren ut av alle andre tjenester i aktiv SSO-sesjon, både OIDC og SAML. Til slutt vil ID-porten redirecte brukeren til *post_logout_redirect_uri* er oppgitt i request dersom denne er angitt og definert for klient, og *id_token_hint* er inkludert.  Dersom disse mangler, vil brukeren ende opp i ID-porten.\n\nUtlogging fra egen tjeneste er basert på [OIDC Session Management](http://openid.net/specs/openid-connect-session-1_0.html)-spesifikasjonen.\n\n#### Samspill mellom sesjoner og tokens ved utlogging\n\nID-porten vil også invalidere alle tokens som tilhører rene innlogginger (dvs. som kun har scopene \"openid\" og/eller \"profile\"). Merk at dette betyr at tokens som inneholder ytterligere scopes, fremdeles vil være aktive etter utlogging.  Motivasjonen bak denne oppførselen er at en utlogging fra netttjeneste tilhørende virksomhet A, ikke naturlig skal føre til at langt-levende app-tilgang tilhørende virksomhet B skal trekkes tilbake, om disse to tilfeldigvis ble utstedt med utgangspunkt i samme sso-sesjon.\n\n\n\n### 2: Håndtere utlogging fra ID-porten (front-channel logout)\n\nDersom brukeren logger ut fra en annen tjeneste, vil ID-porten trigge utlogging fra alle andre tjenester, dvs. både OIDC-tjenester som er konfigurert med støtte for Front Channel Logout, og SAML-tjenester. \n\nID-porten samler opp informasjon om hvilke tjenester en bruker benytter innenfor en sesjon.  For OIDC-klienter som støtter Front Channel Logout, sender ID-porten en GET-forespørsel til klientens *frontchannel_logout_uri*.  Parameterne *iss* og *sid* inkluderes for klienter som krever *frontchannel_logout_session_required*.  *sid* har samme verdi som claim *sid* i id_token.  ID-porten lager en dynamisk side der hver innlogget OIDC-klient får sin egen iframe og blir sendt et front-channel logout-kall i parallell.\n\nMerk at siden browser-aktørene stadig strammer inn på tilgangen til 3djeparts-cookies, kan man ikke lenger forvente at egen cookie følger med i front_channel_logout-kallet. Bruk av `sid`er derfor eneste fremtidsrettede løsning for å finne igjen egen, lokale brukersesjon.\n\nMerk også at klienten som starter utlogging med kall på endsession-endepunktet, også vil motta kall på front channel logout.\n\nEksempel på kall fra ID-porten til klient:\n```\nGET https://client.example.com/myapp/logout\n     ?iss=https://idporten.no/\n     \u0026sid=D8Fgz-jEXG7JXP_VAORmAm1sKB0LjZyA3wAy-rVyMYc=\n```\n`sid` er brukerens sesjons-id som klienten  mottok som claim i id-tokenet.\n\n\nFront-channel logout i ID-porten er basert på  [OIDC Front Channel Logout](http://openid.net/specs/openid-connect-frontchannel-1_0.html)-spesifikasjonen.\n\n\nDersom en klient ikke er konfigurert med Front Channel Logout, vil klienten ikke motta utloggingsforespørsel fra ID-porten dersom brukeren logger ut fra en annen tjeneste i circle-of-trust og id-tokenet vil heller ikke inneholde `sid`.  \n",
+    "lang": "nb",
+    "path": "/nb/start/oidc/sso"
+  },
+  {
+    "id": "nb-start-scopes-access_policy",
+    "title": "Tilgangsstyring",
+    "content": "# Tilgangsstyring\n\n## Hva betyr \"Tilgjengelig for alle\"?\n\nValget `Tilgjengelig for alle (Krever ingen godkjenning)` betyr normalt at klienter kan be om tilgang uten en ekstra manuell eller eksplisitt godkjenningsprosess fra tilbyderen.\n\n## Fordeler\n\nDette kan gi rask onboarding og lav terskel for bruk. Det passer ofte best for åpne eller standardiserte API-tilganger der risikoen ved feil bruk er begrenset.\n\n## Ulemper\n\nNår ingen godkjenning kreves, mister du et viktig kontrollpunkt. For mer sensitive API eller for tilgang som må avklares juridisk eller organisatorisk, er det ofte bedre med strengere tilgangsstyring.\n",
+    "lang": "nb",
+    "path": "/nb/start/scopes/access_policy"
+  },
+  {
+    "id": "nb-start-scopes-client_types",
+    "title": "Klienttyper",
+    "content": "# Klienttyper\n\n## Hva betyr dette?\n\nValg som `Ansattporten`, `API-klient` og `Maskinporten` sier noe om hvilken type integrasjon eller brukssituasjon scopet hører til. Dette påvirker ofte hvilke andre felter som er relevante, og hvordan tilgang bør forstås.\n\n## Typisk tolkning\n\n`API-klient` brukes gjerne når en klient skal hente token og kalle API direkte. `Maskinporten` peker ofte mot maskin-til-maskin-scenarioer der virksomheter representerer seg selv. `Ansattporten` er mer relevant når en sluttbruker opptrer i en jobbsammenheng eller på vegne av en virksomhet.\n\n## Hvorfor er det viktig?\n\nKlienttypen er med på å sette forventninger til autentisering, tokeninnhold, delegasjon og brukerinvolvering. Den bør derfor stemme med faktisk bruksmønster, ikke bare med teknologien som brukes.\n",
+    "lang": "nb",
+    "path": "/nb/start/scopes/client_types"
+  },
+  {
+    "id": "nb-start-scopes-delegation_source",
+    "title": "Delegeringskilde",
+    "content": "# Delegeringskilde\n\n## Hva er en delegeringskilde?\n\nDelegeringskilden sier hvorfra en rettighet eller et representasjonsforhold kommer. I skjermbildet er `altinn` et eksempel på en slik kilde.\n\n## Hvorfor betyr det noe?\n\nNår tilgang bygger på delegasjon, er det ikke nok å vite hvem klienten er. Du må også vite hvor fullmakten kommer fra, og hvilket regelsett som styrer om klienten faktisk kan opptre på vegne av noen andre.\n\n## Eksempel\n\nHvis en virksomhet har gitt en annen aktør rett til å utføre en handling i Altinn, kan denne delegasjonen være grunnlaget for at scopet kan brukes. Da blir delegeringskilden en viktig del av autorisasjonsmodellen.\n",
+    "lang": "nb",
+    "path": "/nb/start/scopes/delegation_source"
+  },
+  {
+    "id": "nb-start-scopes-overview",
+    "title": "Oversikt over scopes",
+    "content": "# Oversikt over scopes\n\n## Hva er dette?\n\nDenne seksjonen beskriver felter og valg som ofte brukes når du definerer et scope eller en API-tilgang. Målet er ikke å dekke alle detaljer, men å gi korte forklaringer som gjør det enklere å forstå hva de ulike innstillingene betyr i praksis.\n\n## Typiske tema\n\n- hvilken type klient eller produkt tilgangen hører til\n- om scopet er offentlig eller privat\n- hvordan tilgang godkjennes og delegeres\n- hvordan token utformes og hvor lenge de varer\n- om sluttbruker må involveres\n\n## Hvordan lese artiklene\n\nHver underside forklarer ett begrep, når det typisk brukes, og hvilke avveininger som følger med. Dette gjør det enklere å bruke mappen som eksempelinnhold under `scopes`.\n",
+    "lang": "nb",
+    "path": "/nb/start/scopes/overview"
+  },
+  {
+    "id": "nb-start-scopes-pseudonymous_login",
+    "title": "Pseudonymisert innlogging",
+    "content": "# Pseudonymisert innlogging\n\n## Hva betyr det?\n\nPseudonymisert innlogging betyr at identiteten som deles med klienten eller API-et er begrenset, slik at sluttbrukeren ikke nødvendigvis eksponeres med full eller direkte identifikasjon.\n\n## Når er det nyttig?\n\nDette kan være relevant når tjenesten trenger å kjenne igjen samme bruker over tid, men ikke trenger fullt fødselsnummer eller andre sterke identifikatorer i hvert kall.\n\n## Hva må vurderes?\n\nPseudonymisering reduserer datadeling, men gjør også enkelte typer kobling og saksbehandling vanskeligere. Det bør derfor brukes når det faktisk er tilstrekkelig for formålet.\n",
+    "lang": "nb",
+    "path": "/nb/start/scopes/pseudonymous_login"
+  },
+  {
+    "id": "nb-start-scopes-token_lifetimes",
+    "title": "Tokenlevetid",
+    "content": "# Tokenlevetid\n\n## Access token levetid\n\nLevetiden til access token bestemmer hvor lenge et utstedt token kan brukes mot et API. Kort levetid begrenser skadeomfanget hvis et token kommer på avveie, men gjør også at klienten oftere må hente nye token.\n\n## Autorisasjon levetid\n\nAutorisasjon levetid beskriver hvor lenge en gitt autorisasjon eller godkjenning kan ligge til grunn for videre tokenutstedelse. Dette er ikke nødvendigvis det samme som levetiden til selve access tokenet.\n\n## Praktisk avveining\n\nDet er vanlig å velge kortere levetid for sensitive tilganger og lengre levetid der hyppig fornyelse skaper unødvendig kompleksitet. Begge verdiene bør sees i sammenheng med risiko og brukeropplevelse.\n",
+    "lang": "nb",
+    "path": "/nb/start/scopes/token_lifetimes"
+  },
+  {
+    "id": "nb-start-scopes-token_type",
+    "title": "Token type",
+    "content": "# Token type\n\n## SELF_CONTAINED\n\nEt `SELF_CONTAINED` token inneholder typisk informasjonen mottakeren trenger direkte i tokenet, for eksempel som claims i et JWT. Det gjør validering raskt og uavhengig av et ekstra oppslag, men kan gi større token og mer informasjon på klient- eller API-siden.\n\n## OPAQUE\n\nEt `OPAQUE` token er normalt bare en referanse. API-et må da slå opp eller introspektere tokenet for å finne tilhørende informasjon. Dette gir mer sentral kontroll, men skaper også avhengighet til oppslagsmekanismen.\n\n## Valg i praksis\n\nToken type bør velges ut fra behov for ytelse, kontroll, kompleksitet og hvor mye informasjon som bør ligge direkte i tokenet.\n",
+    "lang": "nb",
+    "path": "/nb/start/scopes/token_type"
+  },
+  {
+    "id": "nb-start-scopes-user_involvement",
+    "title": "Brukerinvolvering",
+    "content": "# Brukerinvolvering\n\n## Hva dekker dette?\n\nBrukerinvolvering handler om hvorvidt sluttbrukeren må gjøre noe aktivt for at tilgang skal gis eller opprettholdes. I skjermbildet ser vi eksempler som `Krev reautentisering` og `Krev godkjenning fra sluttbruker`.\n\n## Reautentisering\n\nHvis reautentisering kreves, må brukeren bekrefte identiteten sin på nytt før handlingen eller delingen kan fortsette. Dette brukes gjerne ved høyere risiko eller når handlingen er særlig sensitiv.\n\n## Godkjenning fra sluttbruker\n\nNår sluttbrukeren må gi godkjenning, blir samtykke eller eksplisitt aksept en del av flyten. Dette passer når brukeren selv må kontrollere om deling av data eller tilgang skal være tillatt.\n",
+    "lang": "nb",
+    "path": "/nb/start/scopes/user_involvement"
+  },
+  {
+    "id": "nb-start-scopes-visibility",
+    "title": "Synlighet",
+    "content": "# Synlighet\n\n## Hva betyr PUBLIC og PRIVATE?\n\nSynlighet avgjør hvor synlig scopet er for andre brukere eller virksomheter i løsningen. Et `PUBLIC` scope kan typisk oppdages og gjenbrukes bredere, mens et `PRIVATE` scope er mer begrenset og ment for kontrollerte scenarioer.\n\n## Når brukes PRIVATE?\n\n`PRIVATE` er ofte riktig når tilgang skal styres tett, når scopet bare skal brukes av kjente aktører, eller når scopet beskriver en intern eller sensitiv API-tilgang.\n\n## Når brukes PUBLIC?\n\n`PUBLIC` kan passe når scopet skal være enkelt å finne og ta i bruk for mange, og når tilgangsprosessen rundt scopet er tydelig nok til at bredere eksponering er ønskelig.\n",
+    "lang": "nb",
+    "path": "/nb/start/scopes/visibility"
+  }
+]