@ksvedal/docs 0.1.0

package/dist/authentication_method-B28p58-a.js

@@ -0,0 +1,43 @@
+const e = `# Authentication method
+
+## Purpose
+
+The 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.
+
+This is particularly relevant for confidential clients, meaning clients that can protect keys or secrets in a responsible way.
+
+## Technical behavior
+
+The selected method determines which mechanism the client must use to prove its identity. Common mechanisms include:
+
+- client secret
+- signed client assertion
+- other supported methods for client authentication
+
+When \`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.
+
+### Why \`private_key_jwt\` is used
+
+\`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:
+
+- key material can be managed securely
+- key rotation is important
+- a clearer separation is desired between client identity and shared password-based authentication
+
+## Use in OIDC clients
+
+### ID-porten
+
+For OIDC clients against ID-porten, this is used to authenticate the client to the token endpoint after an authorization code has been received.
+
+### Ansattporten
+
+For OIDC clients against Ansattporten, the same principle applies as for ID-porten: the client must authenticate securely when exchanging a code for a token.
+
+### Maskinporten
+
+Maskinporten 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.
+`;
+export {
+  e as default
+};

package/dist/authentication_method-D8EwmEki.js

@@ -0,0 +1,43 @@
+const e = `# Autentiseringsmetode
+
+## Formål
+
+Autentiseringsmetode angir hvordan en klient identifiserer og autentiserer seg overfor autorisasjonsserveren når den kaller endepunkter som krever klientautentisering, typisk token-endepunktet.
+
+Dette er særlig relevant for konfidensielle klienter, altså klienter som kan beskytte nøkler eller hemmeligheter på en forsvarlig måte.
+
+## Teknisk virkemåte
+
+Valgt metode bestemmer hvilken mekanisme klienten skal bruke for å bevise sin identitet. Vanlige mekanismer er:
+
+- klienthemmelighet
+- signert klientassertion
+- andre støttede metoder for klientautentisering
+
+Nå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.
+
+### Hvorfor \`private_key_jwt\` brukes
+
+\`private_key_jwt\` brukes ofte når man ønsker sterkere klientautentisering enn delt hemmelighet kan gi. Dette passer godt i integrasjoner der:
+
+- nøkkelmateriale kan forvaltes sikkert
+- nøkkelrotasjon er viktig
+- man ønsker tydeligere separasjon mellom klientidentitet og delt passordbasert autentisering
+
+## Bruk i OIDC-klienter
+
+### ID-porten
+
+For OIDC-klienter mot ID-porten brukes dette for å autentisere klienten mot token-endepunktet etter at en autorisasjonskode er mottatt.
+
+### Ansattporten
+
+For OIDC-klienter mot Ansattporten gjelder samme prinsipp som for ID-porten: klienten må autentisere seg sikkert når kode byttes mot token.
+
+### Maskinporten
+
+Maskinporten 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.
+`;
+export {
+  e as default
+};

package/dist/authorization_lifetime-CfhrWQ9Y.js

@@ -0,0 +1,39 @@
+const e = `# Autorisasjon levetid
+
+## Formål
+
+Autorisasjon levetid beskriver hvor lenge en autorisasjon eller autorisasjonsrelatert tilstand regnes som gyldig.
+
+Den eksakte betydningen kan variere mellom implementasjoner, men handler normalt om levetiden på en godkjenning, samtykketilstand eller autorisasjonskontekst.
+
+## Teknisk virkemåte
+
+I en autorisasjonsflyt kan det finnes flere tidsavgrensede tilstander, for eksempel at:
+
+- en bruker har gitt samtykke
+- en klient har fått etablert en autorisert relasjon
+- en pågående autorisasjonsprosess fortsatt er gyldig
+
+Autorisasjon levetid bestemmer hvor lenge en slik tilstand kan videreføres før ny autorisering eller ny vurdering må skje.
+
+### Viktig avgrensning
+
+Dette er ikke nødvendigvis det samme som:
+
+- levetiden på access token
+- levetiden på refresh token
+- lengden på en innloggingssesjon
+
+## Bruk i OIDC-klienter
+
+### ID-porten og Ansattporten
+
+Dette kan være relevant i klienter der samtykke, autorisasjonsbeslutninger eller relasjoner mellom klient og bruker skal ha en definert varighet.
+
+### Maskinporten
+
+I Maskinporten-sammenheng vil tilsvarende vurderinger ofte være mer knyttet til delegasjon, tilgangsgrunnlag og tokenutstedelse enn til sluttbrukerbasert samtykke.
+`;
+export {
+  e as default
+};

package/dist/authorization_lifetime-DrFRbscQ.js

@@ -0,0 +1,39 @@
+const n = `# Authorization lifetime
+
+## Purpose
+
+Authorization lifetime describes how long an authorization or authorization-related state is considered valid.
+
+The exact meaning may vary between implementations, but it normally concerns the lifetime of an approval, consent state, or authorization context.
+
+## Technical behavior
+
+In an authorization flow there can be several time-limited states, for example that:
+
+- a user has given consent
+- a client has established an authorized relationship
+- an ongoing authorization process is still valid
+
+Authorization lifetime determines how long such a state can continue before a new authorization or a new assessment is required.
+
+### Important distinction
+
+This is not necessarily the same as:
+
+- the lifetime of an access token
+- the lifetime of a refresh token
+- the length of a sign-in session
+
+## Use in OIDC clients
+
+### ID-porten and Ansattporten
+
+This can be relevant in clients where consent, authorization decisions, or relationships between client and user should have a defined duration.
+
+### Maskinporten
+
+In a Maskinporten context, similar considerations will often be more closely related to delegation, access basis, and token issuance than to end-user-based consent.
+`;
+export {
+  n as default
+};

package/dist/backchannel_logout_uri-BTceN7xq.js

@@ -0,0 +1,33 @@
+const e = `# Backchannel logout URI
+
+## Purpose
+
+Backchannel logout URI is the address an authorization server uses to notify a client directly that a central session has ended.
+
+This happens server-to-server, without involving the user's browser.
+
+## Technical behavior
+
+At logout, the authorization server can send a logout message to the client's backend. The client can then:
+
+- identify the affected local session
+- invalidate session state
+- clean up the security context
+
+### Why this is useful
+
+Backchannel logout is often more robust than browser-based logout because it does not depend on browser policies, cookies, or iframe behavior.
+
+## Use in OIDC clients
+
+### ID-porten and Ansattporten
+
+This is relevant for clients that maintain server-side sessions and need reliable coordinated logout.
+
+### Maskinporten
+
+This is normally not relevant in Maskinporten, since there is no interactive end-user session to coordinate.
+`;
+export {
+  e as default
+};

package/dist/backchannel_logout_uri-CBdktUL7.js

@@ -0,0 +1,33 @@
+const e = `# Backchannel logout URI
+
+## Formål
+
+Backchannel logout URI er adressen en autorisasjonsserver bruker for å varsle en klient direkte om at en sentral sesjon er avsluttet.
+
+Dette skjer server-til-server, uten at brukerens nettleser er involvert.
+
+## Teknisk virkemåte
+
+Ved logout kan autorisasjonsserveren sende en logout-melding til klientens backend. Klienten kan da:
+
+- identifisere berørt lokal sesjon
+- ugyldiggjøre sesjonstilstand
+- rydde opp i sikkerhetskontekst
+
+### Hvorfor dette er nyttig
+
+Backchannel logout er ofte mer robust enn nettleserbasert logout fordi den ikke er avhengig av nettleserpolicyer, cookies eller iframe-oppførsel.
+
+## Bruk i OIDC-klienter
+
+### ID-porten og Ansattporten
+
+Dette er relevant for klienter som har server-side sesjoner og trenger pålitelig koordinert logout.
+
+### Maskinporten
+
+Dette er normalt ikke relevant i Maskinporten, siden det ikke er en interaktiv sluttbrukersesjon som skal samordnes.
+`;
+export {
+  e as default
+};