@ksvedal/docs 0.1.0

package/dist/allowed_grant_types-BrnsQvWi.js

@@ -0,0 +1,101 @@
+const e = `# Tillatte grant types
+
+## Formål
+
+Tillatte grant types angir hvilke OAuth 2.0-flyter en klient har lov til å bruke.
+
+En grant type beskriver hvordan klienten får tilgang til tokens, og er dermed en viktig del av klientens sikkerhets- og integrasjonsprofil.
+
+## Teknisk virkemåte
+
+Hver grant type representerer et bestemt autorisasjonsmønster. Ved å begrense hvilke grant types som er tillatt, begrenses også hvilke tokenflyter klienten kan benytte.
+
+Dette er viktig for å:
+
+- redusere angrepsflaten
+- hindre utilsiktet bruk av uønskede flyter
+- gjøre klientkonfigurasjonen mer forutsigbar
+
+### Sikkerhetsprinsipp
+
+En klient bør bare ha tilgang til de grant types den faktisk trenger. Overflødige flyter bør ikke være aktivert.
+
+## authorization_code
+
+\`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.
+
+Dette er den vanligste og mest anbefalte flyten for nettleserbasert innlogging i OIDC.
+
+### Teknisk virkemåte
+
+Flyten består typisk av disse trinnene:
+
+1. Klienten sender brukeren til autorisasjonsendepunktet.
+2. Brukeren autentiserer seg.
+3. Autorisasjonsserveren returnerer brukeren til klientens redirect URI med en autorisasjonskode.
+4. Klienten sender autorisasjonskoden til token-endepunktet.
+5. Klienten mottar access token, og eventuelt ID-token og refresh token.
+
+#### Hvorfor denne flyten anses som sikker
+
+I 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.
+
+#### PKCE
+
+\`authorization_code\` brukes ofte sammen med PKCE. PKCE beskytter mot at autorisasjonskoden fanges opp og misbrukes av andre enn klienten som startet flyten.
+
+## Bruk i OIDC-klienter
+
+### ID-porten
+
+Dette er den sentrale grant-typen for vanlige OIDC-innlogginger mot ID-porten.
+
+### Ansattporten
+
+Ansattporten bruker samme grunnmønster for brukerautentisering og tokenutveksling, og \`authorization_code\` er derfor tilsvarende relevant.
+
+### Maskinporten
+
+Denne grant-typen brukes normalt ikke for Maskinporten, siden Maskinporten ikke bygger på interaktiv brukerinnlogging i nettleser.
+
+## Refresh token
+
+Et 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.
+
+Dette brukes for å opprettholde langvarige økter eller tilgang over tid.
+
+### Teknisk virkemåte
+
+Når en klient mottar både access token og refresh token, kan flyten se slik ut:
+
+1. Access token brukes mot beskyttede API-er.
+2. Når access token utløper, sender klienten refresh token til token-endepunktet.
+3. Autorisasjonsserveren utsteder nytt access token dersom refresh token fortsatt er gyldig.
+
+### Sikkerhetsmessig betydning
+
+Et 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.
+
+## Bruk i OIDC-klienter
+
+### ID-porten og Ansattporten
+
+For klienter som trenger vedvarende brukerøkter, kan refresh token være relevant. Dette må vurderes opp mot behov, sikkerhetsnivå og hvordan klienten lagrer tokens.
+
+### Maskinporten
+
+Refresh 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.
+
+## Bruk i OIDC-klienter
+
+### ID-porten og Ansattporten
+
+For 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.
+
+### Maskinporten
+
+Maskinporten 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.
+`;
+export {
+  e as default
+};

package/dist/allowed_grant_types-ovkxJeQq.js

@@ -0,0 +1,101 @@
+const e = `# Allowed grant types
+
+## Purpose
+
+Allowed grant types define which OAuth 2.0 flows a client is permitted to use.
+
+A grant type describes how the client obtains tokens, and is therefore an important part of the client's security and integration profile.
+
+## Technical behavior
+
+Each grant type represents a specific authorization pattern. Restricting which grant types are allowed also restricts which token flows the client can use.
+
+This is important in order to:
+
+- reduce the attack surface
+- prevent unintended use of unwanted flows
+- make the client configuration more predictable
+
+### Security principle
+
+A client should only have access to the grant types it actually needs. Unnecessary flows should not be enabled.
+
+## authorization_code
+
+\`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.
+
+This is the most common and recommended flow for browser-based sign-in in OIDC.
+
+### Technical behavior
+
+The flow typically consists of these steps:
+
+1. The client sends the user to the authorization endpoint.
+2. The user authenticates.
+3. The authorization server returns the user to the client's redirect URI with an authorization code.
+4. The client sends the authorization code to the token endpoint.
+5. The client receives an access token, and optionally an ID token and refresh token.
+
+#### Why this flow is considered secure
+
+In 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.
+
+#### PKCE
+
+\`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.
+
+## Use in OIDC clients
+
+### ID-porten
+
+This is the central grant type for regular OIDC logins against ID-porten.
+
+### Ansattporten
+
+Ansattporten uses the same basic pattern for user authentication and token exchange, so \`authorization_code\` is equally relevant there.
+
+### Maskinporten
+
+This grant type is normally not used for Maskinporten, since Maskinporten is not based on interactive user login in a browser.
+
+## Refresh token
+
+A refresh token allows a client to obtain new access tokens without requiring the user to authenticate again every time an access token expires.
+
+This is used to maintain long-lived sessions or access over time.
+
+### Technical behavior
+
+When a client receives both an access token and a refresh token, the flow can look like this:
+
+1. The access token is used against protected APIs.
+2. When the access token expires, the client sends the refresh token to the token endpoint.
+3. The authorization server issues a new access token if the refresh token is still valid.
+
+### Security significance
+
+A 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.
+
+## Use in OIDC clients
+
+### ID-porten and Ansattporten
+
+For 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.
+
+### Maskinporten
+
+Refresh 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.
+
+## Use in OIDC clients
+
+### ID-porten and Ansattporten
+
+For 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.
+
+### Maskinporten
+
+Maskinporten 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.
+`;
+export {
+  e as default
+};

package/dist/application_type-BAESO1T4.js

@@ -0,0 +1,36 @@
+const e = `# Application types
+
+## Web Application
+
+A web application is software that runs on a remote server and is accessed through a web browser. Nothing is installed locally by the user.
+
+### Characteristics
+- Accessed via URL  
+- Runs in a browser  
+- Platform-independent  
+- Centrally maintained and updated  
+
+## Browser Application
+
+A browser application is a web application that runs directly inside the browser environment using technologies such as HTML, CSS, and JavaScript.
+
+### Characteristics
+- Executes inside the browser engine  
+- No local installation required  
+- Uses browser APIs  
+- Dependent on browser capabilities  
+
+Note: “Web app” and “browser app” are often used interchangeably, but “browser application” emphasizes execution inside the browser.
+
+## Native Application
+
+A native application is installed directly on a device and runs on the operating system rather than inside a browser.
+
+### Characteristics
+- Requires installation  
+- Built for a specific operating system  
+- Direct access to hardware and system resources  
+- Typically higher performance  `;
+export {
+  e as default
+};

package/dist/application_type-BtouPPrt.js

@@ -0,0 +1,39 @@
+const e = `# Applikasjonstyper
+
+## Web (Webapplikasjon)
+
+En webapplikasjon er et program som kjører på en server og brukes via en nettleser over internett eller intranett. Brukeren installerer ingenting lokalt.
+
+### Kjennetegn
+
+- Tilgang via URL  
+- Krever nettleser  
+- Plattformuavhengig  
+- Oppdateres sentralt på server  
+
+## Browser (Nettleserbasert applikasjon)
+
+En browser-applikasjon er en type webapplikasjon som kjører direkte i nettleseren og er bygget med HTML, CSS og JavaScript.
+
+### Kjennetegn
+
+- Kjører i nettlesermiljøet  
+- Ingen lokal installasjon  
+- Bruker nettleserens motor  
+- Kan bruke nettleserens API-er  
+
+Merk: “Web application” og “browser application” brukes ofte om hverandre, men “browser application” presiserer at kjøringen skjer direkte i nettleseren.
+
+## Native (Lokal / Native applikasjon)
+
+En native applikasjon installeres direkte på en enhet og kjører på operativsystemet, ikke i en nettleser.
+
+### Kjennetegn
+
+- Må installeres  
+- Bygget for spesifikt operativsystem  
+- Direkte tilgang til maskinvare og systemressurser  
+- Ofte bedre ytelse  `;
+export {
+  e as default
+};

package/dist/arc-zSbgd3Dl.js

@@ -0,0 +1,83 @@
+import { M as ln, N as an, O as y, P as tn, Q as Y, R as O, S as _, T as un, V as Q, W as rn, X as j, Y as o, Z as sn, $ as on, a0 as fn } from "./index-D_FT2Td-.js";
+function cn(l) {
+  return l.innerRadius;
+}
+function yn(l) {
+  return l.outerRadius;
+}
+function gn(l) {
+  return l.startAngle;
+}
+function dn(l) {
+  return l.endAngle;
+}
+function mn(l) {
+  return l && l.padAngle;
+}
+function pn(l, h, D, S, v, R, V, a) {
+  var E = D - l, i = S - h, n = V - v, d = a - R, u = d * E - n * i;
+  if (!(u * u < y))
+    return u = (n * (h - R) - d * (l - v)) / u, [l + u * E, h + u * i];
+}
+function H(l, h, D, S, v, R, V) {
+  var a = l - D, E = h - S, i = (V ? R : -R) / j(a * a + E * E), n = i * E, d = -i * a, u = l + n, s = h + d, f = D + n, c = S + d, W = (u + f) / 2, t = (s + c) / 2, m = f - u, g = c - s, A = m * m + g * g, T = v - R, P = u * c - f * s, I = (g < 0 ? -1 : 1) * j(fn(0, T * T * A - P * P)), M = (P * g - m * I) / A, N = (-P * m - g * I) / A, w = (P * g + m * I) / A, p = (-P * m + g * I) / A, x = M - W, e = N - t, r = w - W, X = p - t;
+  return x * x + e * e > r * r + X * X && (M = w, N = p), {
+    cx: M,
+    cy: N,
+    x01: -n,
+    y01: -d,
+    x11: M * (v / T - 1),
+    y11: N * (v / T - 1)
+  };
+}
+function hn() {
+  var l = cn, h = yn, D = Q(0), S = null, v = gn, R = dn, V = mn, a = null, E = ln(i);
+  function i() {
+    var n, d, u = +l.apply(this, arguments), s = +h.apply(this, arguments), f = v.apply(this, arguments) - an, c = R.apply(this, arguments) - an, W = un(c - f), t = c > f;
+    if (a || (a = n = E()), s < u && (d = s, s = u, u = d), !(s > y)) a.moveTo(0, 0);
+    else if (W > tn - y)
+      a.moveTo(s * Y(f), s * O(f)), a.arc(0, 0, s, f, c, !t), u > y && (a.moveTo(u * Y(c), u * O(c)), a.arc(0, 0, u, c, f, t));
+    else {
+      var m = f, g = c, A = f, T = c, P = W, I = W, M = V.apply(this, arguments) / 2, N = M > y && (S ? +S.apply(this, arguments) : j(u * u + s * s)), w = _(un(s - u) / 2, +D.apply(this, arguments)), p = w, x = w, e, r;
+      if (N > y) {
+        var X = sn(N / u * O(M)), z = sn(N / s * O(M));
+        (P -= X * 2) > y ? (X *= t ? 1 : -1, A += X, T -= X) : (P = 0, A = T = (f + c) / 2), (I -= z * 2) > y ? (z *= t ? 1 : -1, m += z, g -= z) : (I = 0, m = g = (f + c) / 2);
+      }
+      var Z = s * Y(m), $ = s * O(m), B = u * Y(T), C = u * O(T);
+      if (w > y) {
+        var F = s * Y(g), G = s * O(g), J = u * Y(A), K = u * O(A), q;
+        if (W < rn)
+          if (q = pn(Z, $, J, K, F, G, B, C)) {
+            var L = Z - q[0], U = $ - q[1], k = F - q[0], b = G - q[1], nn = 1 / O(on((L * k + U * b) / (j(L * L + U * U) * j(k * k + b * b))) / 2), en = j(q[0] * q[0] + q[1] * q[1]);
+            p = _(w, (u - en) / (nn - 1)), x = _(w, (s - en) / (nn + 1));
+          } else
+            p = x = 0;
+      }
+      I > y ? x > y ? (e = H(J, K, Z, $, s, x, t), r = H(F, G, B, C, s, x, t), a.moveTo(e.cx + e.x01, e.cy + e.y01), x < w ? a.arc(e.cx, e.cy, x, o(e.y01, e.x01), o(r.y01, r.x01), !t) : (a.arc(e.cx, e.cy, x, o(e.y01, e.x01), o(e.y11, e.x11), !t), a.arc(0, 0, s, o(e.cy + e.y11, e.cx + e.x11), o(r.cy + r.y11, r.cx + r.x11), !t), a.arc(r.cx, r.cy, x, o(r.y11, r.x11), o(r.y01, r.x01), !t))) : (a.moveTo(Z, $), a.arc(0, 0, s, m, g, !t)) : a.moveTo(Z, $), !(u > y) || !(P > y) ? a.lineTo(B, C) : p > y ? (e = H(B, C, F, G, u, -p, t), r = H(Z, $, J, K, u, -p, t), a.lineTo(e.cx + e.x01, e.cy + e.y01), p < w ? a.arc(e.cx, e.cy, p, o(e.y01, e.x01), o(r.y01, r.x01), !t) : (a.arc(e.cx, e.cy, p, o(e.y01, e.x01), o(e.y11, e.x11), !t), a.arc(0, 0, u, o(e.cy + e.y11, e.cx + e.x11), o(r.cy + r.y11, r.cx + r.x11), t), a.arc(r.cx, r.cy, p, o(r.y11, r.x11), o(r.y01, r.x01), !t))) : a.arc(0, 0, u, T, A, t);
+    }
+    if (a.closePath(), n) return a = null, n + "" || null;
+  }
+  return i.centroid = function() {
+    var n = (+l.apply(this, arguments) + +h.apply(this, arguments)) / 2, d = (+v.apply(this, arguments) + +R.apply(this, arguments)) / 2 - rn / 2;
+    return [Y(d) * n, O(d) * n];
+  }, i.innerRadius = function(n) {
+    return arguments.length ? (l = typeof n == "function" ? n : Q(+n), i) : l;
+  }, i.outerRadius = function(n) {
+    return arguments.length ? (h = typeof n == "function" ? n : Q(+n), i) : h;
+  }, i.cornerRadius = function(n) {
+    return arguments.length ? (D = typeof n == "function" ? n : Q(+n), i) : D;
+  }, i.padRadius = function(n) {
+    return arguments.length ? (S = n == null ? null : typeof n == "function" ? n : Q(+n), i) : S;
+  }, i.startAngle = function(n) {
+    return arguments.length ? (v = typeof n == "function" ? n : Q(+n), i) : v;
+  }, i.endAngle = function(n) {
+    return arguments.length ? (R = typeof n == "function" ? n : Q(+n), i) : R;
+  }, i.padAngle = function(n) {
+    return arguments.length ? (V = typeof n == "function" ? n : Q(+n), i) : V;
+  }, i.context = function(n) {
+    return arguments.length ? (a = n ?? null, i) : a;
+  }, i;
+}
+export {
+  hn as d
+};

package/dist/architecture-U656AL7Q-bG73RCfJ.js

@@ -0,0 +1,5 @@
+import { A as c, e as t } from "./mermaid-parser.core-C-16ojim.js";
+export {
+  c as ArchitectureModule,
+  t as createArchitectureServices
+};