@ksvedal/docs 0.1.0

package/dist/radar-NHE76QYJ-DRN4buPP.js

@@ -0,0 +1,5 @@
+import { R as r, g as d } from "./mermaid-parser.core-C-16ojim.js";
+export {
+  r as RadarModule,
+  d as createRadarServices
+};

package/dist/redirect_uri-Cnlv_2rt.js

@@ -0,0 +1,38 @@
+const e = `# Redirect URI-er
+
+## Formål
+
+Redirect URI-er er adresser autorisasjonsserveren har lov til å sende brukeren tilbake til etter en autorisasjons- eller autentiseringsprosess.
+
+Dette er en grunnleggende sikkerhetsmekanisme i OAuth 2.0 og OpenID Connect.
+
+## Teknisk virkemåte
+
+I en typisk \`authorization_code\`-flyt skjer dette slik:
+
+1. Klienten sender en autorisasjonsforespørsel med ønsket redirect URI.
+2. Autorisasjonsserveren kontrollerer at URI-en er registrert for klienten.
+3. Etter vellykket autentisering returneres brukeren til denne adressen.
+4. Responsen inneholder typisk en autorisasjonskode.
+
+### Hvorfor eksakt registrering er viktig
+
+Redirect 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.
+
+## Bruk i OIDC-klienter
+
+### ID-porten
+
+Redirect URI-er er en sentral del av innlogging via ID-porten, siden autorisasjonskoden returneres til klientens registrerte adresse.
+
+### Ansattporten
+
+Det samme gjelder for Ansattporten, der korrekt registrering er nødvendig for at autorisasjonsflyten skal fungere og være sikker.
+
+### Maskinporten
+
+Redirect URI-er er normalt ikke relevante i klassiske Maskinporten-flyter, siden disse ikke er basert på nettleserredirect og interaktiv brukerinnlogging.
+`;
+export {
+  e as default
+};

package/dist/redirect_uri-DgNidm8d.js

@@ -0,0 +1,38 @@
+const e = `# Redirect URIs
+
+## Purpose
+
+Redirect URIs are addresses the authorization server is allowed to send the user back to after an authorization or authentication process.
+
+This is a fundamental security mechanism in OAuth 2.0 and OpenID Connect.
+
+## Technical behavior
+
+In a typical \`authorization_code\` flow, this works as follows:
+
+1. The client sends an authorization request with the desired redirect URI.
+2. The authorization server verifies that the URI is registered for the client.
+3. After successful authentication, the user is returned to this address.
+4. The response typically contains an authorization code.
+
+### Why exact registration matters
+
+Redirect 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.
+
+## Use in OIDC clients
+
+### ID-porten
+
+Redirect URIs are a central part of login through ID-porten, since the authorization code is returned to the client's registered address.
+
+### Ansattporten
+
+The same applies to Ansattporten, where correct registration is necessary for the authorization flow to work and remain secure.
+
+### Maskinporten
+
+Redirect URIs are normally not relevant in classic Maskinporten flows, since those are not based on browser redirects and interactive user login.
+`;
+export {
+  e as default
+};

package/dist/refresh_token_lifetime-DCzCzIyu.js

@@ -0,0 +1,34 @@
+const e = `# Refresh token levetid
+
+## Formål
+
+Refresh token levetid angir hvor lenge et refresh token kan brukes til å hente nye access tokens.
+
+Dette setter en øvre grense for hvor lenge en klient kan videreføre tilgang uten ny autentisering.
+
+## Teknisk virkemåte
+
+Så lenge refresh tokenet er gyldig og ikke er tilbakekalt eller ugyldiggjort, kan klienten bruke det til å få utstedt nye access tokens.
+
+### Sikkerhetsvurdering
+
+Jo 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:
+
+- sikker lagring
+- rotasjon
+- tilbakekalling
+- overvåking av mistenkelig bruk
+
+## Bruk i OIDC-klienter
+
+### ID-porten og Ansattporten
+
+Dette 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.
+
+### Maskinporten
+
+Refresh token levetid er normalt ikke en sentral parameter i klassiske Maskinporten-scenarier.
+`;
+export {
+  e as default
+};

package/dist/refresh_token_lifetime-QcGf0aOG.js

@@ -0,0 +1,34 @@
+const e = `# Refresh token lifetime
+
+## Purpose
+
+Refresh token lifetime specifies how long a refresh token can be used to obtain new access tokens.
+
+This sets an upper limit on how long a client can continue access without new authentication.
+
+## Technical behavior
+
+As 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.
+
+### Security considerations
+
+The 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:
+
+- secure storage
+- rotation
+- revocation
+- monitoring of suspicious use
+
+## Use in OIDC clients
+
+### ID-porten and Ansattporten
+
+This 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.
+
+### Maskinporten
+
+Refresh token lifetime is normally not a central parameter in classic Maskinporten scenarios.
+`;
+export {
+  e as default
+};

package/dist/refresh_token_usage-C2LdxQHa.js

@@ -0,0 +1,33 @@
+const e = `# Refresh token bruk
+
+## Formål
+
+Refresh token bruk beskriver hvordan refresh tokens håndteres i praksis, utover bare om de er tillatt eller ikke.
+
+Dette kan omfatte regler for utstedelse, gjenbruk, rotasjon og ugyldiggjøring.
+
+## Teknisk virkemåte
+
+I 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:
+
+- et nytt refresh token utstedes
+- det gamle ugyldiggjøres
+- misbruk lettere kan oppdages
+
+### Sikkerhetsbetydning
+
+Valg 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.
+
+## Bruk i OIDC-klienter
+
+### ID-porten og Ansattporten
+
+For klienter som trenger vedvarende brukerøkter, bør refresh token bruk vurderes sammen med tokenlagring, levetider og eventuelle krav til rotasjon.
+
+### Maskinporten
+
+Dette er normalt ikke et sentralt tema i Maskinporten-integrasjoner, siden mønsteret der som regel ikke er bygget rundt refresh token-baserte brukerøkter.
+`;
+export {
+  e as default
+};

package/dist/refresh_token_usage-DXI98e4O.js

@@ -0,0 +1,33 @@
+const e = `# Refresh token usage
+
+## Purpose
+
+Refresh token usage describes how refresh tokens are handled in practice, beyond simply whether they are allowed or not.
+
+This can include rules for issuance, reuse, rotation, and invalidation.
+
+## Technical behavior
+
+In 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:
+
+- a new refresh token being issued
+- the old one being invalidated
+- misuse being easier to detect
+
+### Security significance
+
+The 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.
+
+## Use in OIDC clients
+
+### ID-porten and Ansattporten
+
+For clients that need persistent user sessions, refresh token usage should be considered together with token storage, token lifetimes, and any requirements for rotation.
+
+### Maskinporten
+
+This is normally not a central topic in Maskinporten integrations, since the pattern there is usually not built around refresh-token-based user sessions.
+`;
+export {
+  e as default
+};