@wildo-ai/saas-models 1.1.4 → 1.1.6

package/dist/esm/security/authentications/authentication.shared.schemas.d.ts

@@ -114,17 +114,33 @@ export declare const OIDC_RESERVED_ID_TOKEN_CLAIM_NAMES: ReadonlySet<string>;
  * | `ORG_SAML` | first or second | a connection resource on the organization, AND a Java runtime with the schema-validation helper compiled on every host that serves SAML |
  * | `ORG_OPENID_CONNECT` | first or second | a connection resource on the organization |
  *
- * ## ⚠️ The organization SSO methods are gated by the USER TYPE first
+ * ## Passkeys sign in without an email, and several accounts can share one device
  *
- * A perfectly configured SSO connection is never offered unless the user type enables `ORG_SAML` /
- * `ORG_OPENID_CONNECT`: the connection lookup only runs when the resolved policy already has the
- * method, so the organization is never consulted. The symptom is a login screen that simply does not
- * show the option, with nothing wrong on the connection and nothing in the logs. Enable the method on
- * the user type BEFORE debugging the connection.
+ * Enabling `PASSKEY` gives the sign-in screen two username-less entries on top of the passkey method
+ * shown after an email: passkey AUTOFILL on the email field, and a "Sign in with a passkey" button. The
+ * device lists every account the person holds a passkey for on this site, and the account that signs
+ * in is the one the chosen passkey belongs to — whatever email, if any, was typed.
+ *
+ * - **Every passkey is a discoverable credential.** There is no setting to turn this off: sign-in
+ *   names no account to the device, so the device must be able to offer the account itself.
+ * - **The sign-in options are identical for every email**, so they never reveal whether an account
+ *   exists or holds a passkey.
+ * - **A signed-in account is held to the same rules as a typed email**: the frontend must be allowed
+ *   to sign in that account's user type, and an organization that restricts its domain to SSO refuses
+ *   a passkey sign-in exactly as it refuses a password.
+ * - **Re-authentication does not offer the username-less entries** — a re-proof must be the same person.
+ *
+ * ## Organization SSO also requires an enabled method in the effective policy
+ *
+ * A configured connection alone does not enable `ORG_SAML` / `ORG_OPENID_CONNECT`. Check the user
+ * type's methods and the application's `auth.orgAuthMethodPolicy`: RESTRICT_ONLY intersects,
+ * EXPAND_WITHIN_SET permits additions from `auth.expandableOrgMethods`, and UNRESTRICTED uses the
+ * organization's set. Explicit organization method overrides intersect across memberships.
+ * Login-method expansion does not weaken the separate MFA, password or step-up requirements.
  *
  * ## Other refusals worth knowing before you pick one
  *
- * - **`EXTERNAL_OAUTH2` will not link or create an account from a provider that does not report the
+ * - **`EXTERNAL_OAUTH2` will not automatically link by email or create an account from a provider that does not report the
  *   email address as VERIFIED.** That is a refusal, not a warning — a provider whose claim mapping
  *   does not surface a verified flag cannot be used for sign-up until the mapping is corrected.
  * - **A missing SAML validation helper surfaces as an invalid signature**, not as a missing
@@ -167,6 +183,31 @@ export declare enum AuthMethod {
     EMAIL_OTP = "EMAIL_OTP",// Email One-Time Password
     PASSKEY = "PASSKEY"
 }
+/**
+ * Is this method strong enough for a policy that demands a STRONG second factor?
+ *
+ * Derived from the method's own channel rather than from a hand-kept weak list: a second factor
+ * delivered to an email address is excluded, because email is not an acceptable channel for
+ * out-of-band authentication at all — "Email SHALL NOT be used for out-of-band authentication because
+ * it may be vulnerable to: Access using only a password; Interception in transit or at intermediate
+ * mail servers; Rerouting attacks".
+ *
+ * spec-cite: NIST SP 800-63B-4 §3.1.3.1 "Out-of-Band Authenticators"
+ * (https://pages.nist.gov/800-63-4/sp800-63b.html).
+ *
+ * **This reproduces the set the previous rule produced, and that is deliberate.** `requireStrongMFA`
+ * used to be expressed as "drop the factors that need no enrolment", which removed `EMAIL_OTP`
+ * because an address the account already proved needs no setup. That reasoning is sound and it was
+ * reaching the right answer by a property that only coincides with the one it meant — a second
+ * always-available factor on another channel would have been excluded for no reason, and a weak
+ * factor that DID need enrolment would have passed. Deriving from the channel says the thing itself.
+ *
+ * **What it deliberately does NOT change:** `SMS_OTP` stays strong. NIST classes PSTN out-of-band as
+ * the one RESTRICTED authenticator (§3.2.9) — permitted, with an obligation to offer an unrestricted
+ * alternative — rather than as a prohibited channel, and promoting "restricted" to "not strong" is a
+ * posture decision an application should make, not one this predicate should make for it.
+ */
+export declare function isStrongSecondFactor(method: AuthMethod): boolean;
 /** @wildo_source:part:end saas.models.auth.methods */
 /**
  * Authentication Factor Levels
@@ -212,8 +253,52 @@ export declare enum AuthNextStep {
      * the link is that proof. It is also, permanently, the recovery path — see the note on
      * `registerUser`.
      */
-    PASSKEY_ENROLLMENT = "passkey_enrollment"
+    PASSKEY_ENROLLMENT = "passkey_enrollment",
+    /**
+     * An invitation was accepted and no session was issued (#1158). The user's effective policy disables the sign-in the
+     * invitation link amounts to (possession of the email address), so they continue on the sign-in page with a method
+     * their policy allows.
+     */
+    SIGN_IN_REQUIRED = "sign_in_required"
 }
+/**
+ * What a re-authentication proof is FOR (#1417). It decides which factors may mint the proof and which
+ * doors accept it.
+ *
+ * - `STEP_UP`: a sensitive operation, removing a way to sign in, or turning TOTP off. Minted only from
+ *   a factor the effective `stepUpAuth.methods` accepts, as a `REAUTH` token.
+ * - `BIND_AUTHENTICATOR`: adding a way to sign in. Minted from any factor the account holds, as a
+ *   `REAUTH_BIND` token, which only the binding doors accept.
+ */
+export declare enum ReAuthenticationPurpose {
+    STEP_UP = "step_up",
+    BIND_AUTHENTICATOR = "bind_authenticator"
+}
+/**
+ * The frontend page a federated re-authentication returns to (#1441), inside the popup the step-up
+ * dialog opened. The backend redirects there with `?code=` (a one-time `REAUTH_CODE_EXCHANGE` code) or
+ * `?error=`; the page hands either to the window that opened it and closes. ONE constant, so the URL the
+ * backend writes and the route the frontend mounts cannot disagree.
+ */
+export declare const REAUTHENTICATION_CALLBACK_PAGE_PATH = "/auth/reauth/callback";
+/**
+ * A linked identity that can re-authenticate its account through its provider (#1441): what the step-up
+ * dialog shows as "Continue with <displayName>", what `GET /auth/reauth/methods` lists beside the local
+ * factors, and what `POST /auth/reauth/federated/authorize` accepts by `identityLinkId`.
+ */
+export interface ReAuthenticationIdentityLink {
+    identityLinkId: string;
+    providerRef: string;
+    /** The provider's (social) or the connection's (enterprise) display name. */
+    displayName: string;
+    /** What a step-up policy names this factor by. */
+    method: FederatedReAuthenticationMethod;
+}
+/**
+ * The methods a linked identity re-authenticates with (#1441): `EXTERNAL_OAUTH2` for a social OIDC link,
+ * `ORG_OPENID_CONNECT` for an enterprise OIDC one, `ORG_SAML` for an enterprise SAML one.
+ */
+export type FederatedReAuthenticationMethod = AuthMethod.EXTERNAL_OAUTH2 | AuthMethod.ORG_OPENID_CONNECT | AuthMethod.ORG_SAML;
 /**
  * W4.2: Session purpose — drives UI rendering and valid state transitions.
  */
@@ -234,14 +319,243 @@ export declare enum MfaEnrollmentState {
     GRACE = "grace",
     ENROLLED = "enrolled"
 }
+/**
+ * @wildo_source:part:start saas.models.auth.methods facet:layer:shared facet:audience:app-developer
+ *
+ * ## What each method PROVES, and how the engine decides with it
+ *
+ * Three maps classify a method, and they answer different questions. Reach for the right one:
+ *
+ * | map | answers |
+ * |---|---|
+ * | `AUTH_METHOD_FACTOR_MAP` | WHERE it may sit — first factor, second factor, or either |
+ * | `AUTH_METHOD_CATEGORY_MAP` | which GROUP the sign-in page renders it in |
+ * | `AUTH_METHOD_EVIDENCE` | what it PROVES — the one the engine's factor rules read |
+ */
 /**
  * Authentication Method Factor Classification Map
  */
 export declare const AUTH_METHOD_FACTOR_MAP: Record<AuthMethod, AuthFactorType>;
+/**
+ * The order authentication methods are PRESENTED in, and the order that decides which one is offered first.
+ *
+ * ONE authority, deliberately. Until #1218 there were two and neither was: the backend returned methods in
+ * `AUTH_METHOD_FACTOR_MAP` declaration order — so `defaultFirstFactorMethod` was `PASSWORD` because PASSWORD happens to
+ * be the first key of an unrelated map — and the frontend threw that order away and re-sorted by a display list only it
+ * could see. A domain routed to an enterprise identity provider still met the password form, with "Continue with your
+ * provider" relegated to "other methods".
+ *
+ * The head is the one the sign-in page already used, promoted rather than invented: the organization's own identity
+ * provider first, because a domain that routes to one is telling you where this person signs in; then the credentials a
+ * person holds directly; then the delegated and one-time channels.
+ *
+ * **The TRAILER orders the second-factor challenge, and it is strongest-first.** Those members are second-factor-only
+ * (or, for `SMS_OTP`, first-or-second), so they never appear in a first-factor list and their position here decides one
+ * thing: what the MFA screen offers first. `TOTP` leads them because it is an unrestricted authenticator; `SMS_OTP`
+ * follows because NIST classes PSTN out-of-band as RESTRICTED — permitted, with an obligation to offer an unrestricted
+ * alternative — and `EMAIL_OTP` is last because email "SHALL NOT be used for out-of-band authentication".
+ * spec-cite: NIST SP 800-63B-4 §3.2.9 (restricted authenticators) and §3.1.3.1 (out-of-band authenticators)
+ * (https://pages.nist.gov/800-63-4/sp800-63b.html). The same two sections `isStrongSecondFactor` cites.
+ *
+ * The frontend's deleted display order put `TOTP` last, behind both OTP channels, for no recorded reason — that is what
+ * this replaces, and the change is deliberate rather than incidental.
+ *
+ * TOTAL over the vocabulary, and pinned as total: a method added to `AuthMethod` tomorrow must be PLACED here, rather
+ * than appearing silently at the end of whichever list happened to be sorted last.
+ */
+export declare const AUTH_METHOD_PRECEDENCE: readonly AuthMethod[];
 /**
  * Authentication Method Category Map
  */
 export declare const AUTH_METHOD_CATEGORY_MAP: Record<AuthMethod, AuthMethodCategory>;
+/**
+ * The factor CATEGORY a method proves, in the classical three — plus the one Wildo cannot classify.
+ *
+ * `FEDERATED` is not a fourth kind of factor. It means the proof happened at an identity provider, so
+ * what was proved is the IdP's answer and not ours: the engine reads it from the assertion's `acr`
+ * demands and assurance evidence rather than declaring it here. Giving a federated method a concrete
+ * category would be asserting something about somebody else's ceremony.
+ */
+export declare enum AuthFactorCategory {
+    /** Something you know. */
+    KNOWLEDGE = "KNOWLEDGE",
+    /** Something you have. */
+    POSSESSION = "POSSESSION",
+    /** Something you are. */
+    INHERENCE = "INHERENCE",
+    /** Proved elsewhere; the assertion says what, not this map. */
+    FEDERATED = "FEDERATED"
+}
+/**
+ * The CHANNEL a method's proof travels over — the axis that decides whether two factors are
+ * independent.
+ *
+ * Two factors that share a channel are one factor counted twice: whoever holds the channel holds
+ * both. A magic link and an email one-time code are the worked example, and the law states the rule
+ * directly — "the breach of one of the elements does not compromise the reliability of the other
+ * elements".
+ *
+ * spec-cite: Commission Delegated Regulation (EU) 2018/389, Art. 9(1) "Independence of the elements"
+ * (https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32018R0389). That regulation binds
+ * payment service providers; it is cited here as the clearest statement of the principle, never as an
+ * obligation a Wildo application inherits.
+ *
+ * `NONE` means the proof does not travel: a password is typed, a TOTP code is computed from a secret
+ * shared once at enrolment. Those can never collide with anything, which is why the rule is expressed
+ * as "not the same channel" rather than as a list of forbidden pairs.
+ */
+export declare enum AuthProofChannel {
+    /** Nothing is delivered — the proof is presented directly. */
+    NONE = "NONE",
+    /** Delivered to a mailbox. */
+    EMAIL = "EMAIL",
+    /** Delivered over the public switched telephone network. */
+    PSTN = "PSTN",
+    /** Produced by an authenticator on the device, and never transmitted. */
+    LOCAL_AUTHENTICATOR = "LOCAL_AUTHENTICATOR",
+    /** Carried in an assertion from an identity provider. */
+    FEDERATED = "FEDERATED"
+}
+/**
+ * Whether ONE ceremony of this method can prove TWO factors by itself.
+ *
+ * Only a cryptographic authenticator can, and only when an activation factor unlocked its key —
+ * "a multi-factor cryptographic authenticator is 'something you have' and is activated by an
+ * activation factor that represents either 'something you know' or 'something you are'".
+ *
+ * spec-cite: NIST SP 800-63B-4 §3.1.7 "Multi-Factor Cryptographic Authentication"
+ * (https://pages.nist.gov/800-63-4/sp800-63b.html).
+ *
+ * `WHEN_USER_VERIFIED` is therefore a CONDITION, not a property: the same passkey proves two factors
+ * in a ceremony that verified the person and one in a ceremony that did not, and both produce a valid
+ * assertion. The engine reads the WebAuthn `UV` flag off the assertion to tell them apart.
+ */
+export declare enum AuthSelfSufficientMultiFactor {
+    /** One ceremony, one factor — always. */
+    NEVER = "NEVER",
+    /** Two factors when the authenticator locally verified the person, one when it did not. */
+    WHEN_USER_VERIFIED = "WHEN_USER_VERIFIED"
+}
+/** What one authentication method proves. See {@link AUTH_METHOD_EVIDENCE}. */
+export interface AuthMethodEvidence {
+    readonly factorCategory: AuthFactorCategory;
+    readonly channel: AuthProofChannel;
+    /**
+     * Whether presenting this method to an impostor verifier is useless to the impostor.
+     *
+     * True for `PASSKEY` alone, and that is not a judgement — "authenticators that involve the manual
+     * entry of an authenticator output (e.g., out-of-band and OTP authenticators) SHALL NOT be
+     * considered phishing-resistant because the manual entry does not bind the authenticator output to
+     * the specific session being authenticated". A typed code is relayable, TOTP included.
+     *
+     * spec-cite: NIST SP 800-63B-4 §3.2.5 "Phishing Resistance"
+     * (https://pages.nist.gov/800-63-4/sp800-63b.html).
+     *
+     * A federated method is `false` because Wildo cannot know how the IdP authenticated the person;
+     * that question is answered by the connection's `acr` demands, not by this map.
+     */
+    readonly phishingResistant: boolean;
+    readonly selfSufficientMultiFactor: AuthSelfSufficientMultiFactor;
+}
+/**
+ * Authentication Method Evidence Map — what each method PROVES.
+ *
+ * The two maps above say where a method may sit and how it is grouped on screen. Neither says what it
+ * proves, so every rule that depends on the strength of a proof used to be hand-applied at its own
+ * door and derived differently at each one: the MFA waiver matched a method NAME, `requireStrongMFA`
+ * was expressed as "drop the ones needing no enrolment", and nothing anywhere expressed the channel —
+ * which is why a magic-link sign-in could be completed by an email code to the same mailbox.
+ *
+ * Being `Record<AuthMethod, …>` is the point: a method added to the vocabulary tomorrow does not
+ * compile until it declares what it proves, so the rules below stay total over the vocabulary instead
+ * of quietly omitting it.
+ *
+ * ## Reading the rows
+ *
+ * - **`MAGIC_LINK` is POSSESSION, not knowledge.** It sits beside `PASSWORD` in
+ *   `AUTH_METHOD_CATEGORY_MAP` because both are rendered as "credentials", and that grouping is a
+ *   screen concern. What a magic link proves is control of a mailbox.
+ * - **`TOTP` has NO channel.** The secret is shared once at enrolment and the code is computed
+ *   locally, so nothing is delivered and it can never collide with another factor's channel.
+ * - **The three federated methods are `FEDERATED` on both axes.** Their strength question already has
+ *   an answer — `externalAssuranceEnforcement` and the connection's `acr` demands — and this map must
+ *   not grow a second, competing one.
+ *
+ * Imported from `@wildo-ai/saas-models`.
+ */
+export declare const AUTH_METHOD_EVIDENCE: Record<AuthMethod, AuthMethodEvidence>;
+/**
+ * Do these two methods prove things a single breach could reach?
+ *
+ * The rule the engine applies when it offers or accepts a SECOND factor: a factor whose channel the
+ * FIRST factor already proved is not a second factor. `NONE` never collides, because nothing is
+ * delivered over it.
+ *
+ * @example
+ * sharesProofChannel(AuthMethod.MAGIC_LINK, AuthMethod.EMAIL_OTP); // true — one mailbox, counted twice
+ * sharesProofChannel(AuthMethod.PASSWORD, AuthMethod.EMAIL_OTP);   // false — nothing is delivered to prove a password
+ */
+export declare function sharesProofChannel(first: AuthMethod, second: AuthMethod): boolean;
+/**
+ * The RFC 8176 `amr` values each method may claim, and nothing else (#1248).
+ *
+ * `amr` is what an ID token tells a relying party about HOW the person authenticated. Wildo demands
+ * exactly this of every identity provider it trusts — `oauth2-authentication` reads an upstream `amr`
+ * as session evidence — and published none of its own, so a client receiving a Wildo ID token could not
+ * make the decision Wildo insists on making about its own upstreams. That asymmetry is the defect.
+ *
+ * spec-cite: RFC 8176 "Authentication Method Reference Values", §2 — the registry of short names and
+ * their definitions (https://www.rfc-editor.org/rfc/rfc8176.html). Every value below is taken from
+ * that registry; none is invented.
+ *
+ * ## Only REGISTERED values, which is why three methods contribute none
+ *
+ * A value outside the registry is a private string a generic relying party cannot read, so an
+ * unregistered "email" or "sso" would be worse than silence — the same reasoning that keeps `acr`
+ * unpublished until Wildo defines what its values mean.
+ *
+ * - **The federated methods contribute nothing.** The registry has no value for "the person proved
+ *   themselves to somebody else and that party vouched for them", and restating the UPSTREAM's `amr`
+ *   as our own would assert a proof this application never observed. What the upstream proved is the
+ *   upstream's claim to make.
+ * - **`MAGIC_LINK` and `EMAIL_OTP` claim `mca`**, "Multiple-channel authentication involving
+ *   communication over distinct channels", which is literally what they are: the credential travels by
+ *   email, a channel distinct from the browser. That is applying a registered definition, not
+ *   stretching one. `EMAIL_OTP` also claims `otp`, which it plainly is; `MAGIC_LINK` is not an OTP —
+ *   the link itself is the credential.
+ * - **`PASSKEY` claims `user`**, "User presence test", because WebAuthn always tests presence. It does
+ *   NOT claim `hwk` or `swk`: which is true depends on whether the credential is single-device or
+ *   synced, and the session does not carry the credential's device type. Claiming either would be a
+ *   guess about the authenticator, and `hwk` is precisely what a relying party reads as
+ *   phishing-resistant hardware.
+ */
+export declare const AUTH_METHOD_AMR: Record<AuthMethod, readonly string[]>;
+/**
+ * What an ID token may say about how THIS session was authenticated (#1248).
+ *
+ * Returns the sorted, de-duplicated registered `amr` values for the factors the session actually
+ * completed — never for the factors it could have used. An empty result means the session has nothing
+ * a relying party could read, and the caller omits the claim rather than emitting `[]`: an empty array
+ * asserts "authenticated by no method", which is false, where an absent claim correctly says nothing.
+ *
+ * ## `mfa` is DERIVED, and it is the value that matters most
+ *
+ * "Multiple-factor authentication" is claimed when the session genuinely holds two independent proofs,
+ * decided by the same {@link AUTH_METHOD_EVIDENCE} channels that decide whether a second factor is
+ * admissible — so an ID token cannot claim `mfa` for a pair this application's own sign-in doors would
+ * refuse as sharing a channel. A password plus an email OTP is two methods and one mailbox; it does
+ * not claim `mfa`.
+ *
+ * A single passkey claims `mfa` when the authenticator locally verified the person, because that
+ * ceremony IS two factors — possession of the authenticator and the activation that unlocked it — and
+ * the WebAuthn UV flag is the only report that the activation happened. That is the distinction the
+ * acceptance asks an ID token to carry, and it is readable only because the verifier reads the flag
+ * off the assertion rather than inferring it from the policy that requested it.
+ */
+export declare function deriveAuthenticationMethodReferences(completedFactors: readonly AuthMethod[], ceremony?: {
+    passkeyUserVerified?: boolean;
+}): string[];
+/** @wildo_source:part:end saas.models.auth.methods */
 /**
  * Scope type for auth policies — organization-level vs application-level.
  *
@@ -277,7 +591,8 @@ export declare const AvailableMethodSchema: z.ZodObject<{
     category: z.ZodEnum<typeof AuthMethodCategory>;
     canBeFirstFactor: z.ZodBoolean;
     canBeSecondFactor: z.ZodBoolean;
-    required: z.ZodBoolean;
+    enforcedFirstFactor: z.ZodBoolean;
+    satisfiesRequiredSecondFactor: z.ZodBoolean;
     oauth2ProviderRefs: z.ZodOptional<z.ZodArray<z.ZodString>>;
     ssoIds: z.ZodOptional<z.ZodArray<z.ZodString>>;
     organizationRestricted: z.ZodDefault<z.ZodBoolean>;

package/dist/esm/security/authentications/authentication.shared.schemas.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"authentication.shared.schemas.d.ts","sourceRoot":"","sources":["../../../../src/security/authentications/authentication.shared.schemas.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAEH,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAGxB,OAAO,KAAK,EAAE,4BAA4B,EAAE,MAAM,qDAAqD,CAAC;AAExG;;;;;;;GAOG;AAGH,eAAO,MAAM,mBAAmB,EAAE,4BAA4B,EAG7D,CAAC;AAOF;;;GAGG;AACH,oBAAY,cAAc;IACxB,UAAU,eAAe,CAAQ,kDAAkD;IACnF,WAAW,gBAAgB,CAAM,0CAA0C;IAC3E,eAAe,oBAAoB,CAAE,+CAA+C;IACpF,GAAG,QAAQ;CACZ;AAED;;;GAGG;AACH,oBAAY,kBAAkB;IAC5B,UAAU,eAAe,CAAY,6BAA6B;IAClE,eAAe,oBAAoB,CAAE,yDAAyD;IAC9F,OAAO,YAAY,CAAiB,oDAAoD;IACxF,SAAS,cAAc,CAAa,yCAAyC;IAC7E,SAAS,cAAc;CACxB;AAED;;;;;;;;;;;;;;;;GAgBG;AACH;;;GAGG;AACH,eAAO,MAAM,sBAAsB,EAAG,mBAA4B,CAAC;AAEnE,oBAAY,cAAc;IACtB,wDAAwD;IACxD,4BAA4B,iCAAiC;IAC7D,sDAAsD;IACtD,0BAA0B,+BAA+B;IACzD,mCAAmC;IACnC,mBAAmB,wBAAwB;IAC3C,sCAAsC;IACtC,sBAAsB,2BAA2B;CACpD;AAED;;;;;;GAMG;AACH,oBAAY,aAAa;IACrB,qEAAqE;IACrE,qBAAqB,0BAA0B;IAE/C,0EAA0E;IAC1E,iCAAiC,sCAAsC;CAC1E;AAED;;;;;;;;;;GAUG;AACH,eAAO,MAAM,kCAAkC,EAAE,WAAW,CAAC,MAAM,CAKjE,CAAC;AAEH;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA+DG;AACH,oBAAY,UAAU;IAEpB,QAAQ,aAAa;IAGrB,eAAe,oBAAoB,CAAE,qCAAqC;IAG1E,QAAQ,aAAa,CAAsB,wBAAwB;IACnE,kBAAkB,uBAAuB,CAAE,kCAAkC;IAG7E,UAAU,eAAe,CAAO,uBAAuB;IAGvD,IAAI,SAAS,CAAqB,+BAA+B;IACjE,OAAO,YAAY,CAAc,wBAAwB;IACzD,SAAS,cAAc,CAAU,0BAA0B;IAG3D,OAAO,YAAY;CACpB;AACD,sDAAsD;AAEtD;;GAEG;AACH,oBAAY,UAAU;IACpB,MAAM,WAAW,CAAQ,+BAA+B;IACxD,KAAK,UAAU;CAChB;AAED;;GAEG;AACH,oBAAY,eAAe;IACzB,cAAc,mBAAmB,CAAE,sBAAsB;IACzD,KAAK,UAAU,CAAU,8BAA8B;IACvD,MAAM,WAAW;CAClB;AAED;;;GAGG;AACH,oBAAY,YAAY;IACtB,cAAc,mBAAmB;IACjC,UAAU,eAAe;IACzB,QAAQ,aAAa;IACrB,kBAAkB,uBAAuB;IACzC,eAAe,oBAAoB;IACnC;;;;OAIG;IACH,eAAe,oBAAoB;IACnC;;;;;;;;;;;;OAYG;IACH,kBAAkB,uBAAuB;CAC1C;AAED;;GAEG;AACH,oBAAY,kBAAkB;IAC5B,KAAK,UAAU;IACf,YAAY,iBAAiB;IAC7B,UAAU,eAAe;IACzB,MAAM,WAAW;IACjB,WAAW,gBAAgB;CAC5B;AAED;;;GAGG;AACH,oBAAY,kBAAkB;IAC5B,YAAY,iBAAiB;IAC7B,OAAO,YAAY;IACnB,KAAK,UAAU;IACf,QAAQ,aAAa;CACtB;AAMD;;GAEG;AACH,eAAO,MAAM,sBAAsB,EAAE,MAAM,CAAC,UAAU,EAAE,cAAc,CAmBrE,CAAC;AAEF;;GAEG;AACH,eAAO,MAAM,wBAAwB,EAAE,MAAM,CAAC,UAAU,EAAE,kBAAkB,CAU3E,CAAC;AAEF;;;;;GAKG;AACH,oBAAY,aAAa;IACvB,YAAY,iBAAiB;IAC7B,WAAW,gBAAgB;CAC5B;AAED;;;;;;;GAOG;AACH,eAAO,MAAM,2BAA2B;;;;;;;;;iBAStC,CAAC;AAEH,MAAM,MAAM,qBAAqB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,2BAA2B,CAAC,CAAC;AAEhF,eAAO,MAAM,qBAAqB;;;;;;;;;;;;;;;;;;;;;;iBAmBhC,CAAC;AAGH,MAAM,MAAM,eAAe,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,qBAAqB,CAAC,CAAC;AAMpE;;;GAGG;AACH,oBAAY,qBAAqB;IAC/B,iBAAiB,sBAAsB;IACvC,gBAAgB,qBAAqB;IACrC,eAAe,oBAAoB;IACnC,cAAc,mBAAmB;IACjC,YAAY,iBAAiB;CAC9B;AAED;;;;;;GAMG;AACH,oBAAY,iBAAiB;IAC3B,MAAM,WAAW;IACjB,UAAU,eAAe;CAC1B;AAED;;;;;GAKG;AACH,oBAAY,sBAAsB;IAChC,MAAM,WAAW;IACjB,IAAI,SAAS;IACb,IAAI,SAAS;IACb,IAAI,SAAS;CACd"}
+{"version":3,"file":"authentication.shared.schemas.d.ts","sourceRoot":"","sources":["../../../../../src/security/authentications/authentication.shared.schemas.ts"],"names":[],"mappings":"AAAA;;;;GAIG;AAEH,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAGxB,OAAO,KAAK,EAAE,4BAA4B,EAAE,MAAM,qDAAqD,CAAC;AAExG;;;;;;;GAOG;AAGH,eAAO,MAAM,mBAAmB,EAAE,4BAA4B,EAG7D,CAAC;AAOF;;;GAGG;AACH,oBAAY,cAAc;IACxB,UAAU,eAAe,CAAQ,kDAAkD;IACnF,WAAW,gBAAgB,CAAM,0CAA0C;IAC3E,eAAe,oBAAoB,CAAE,+CAA+C;IACpF,GAAG,QAAQ;CACZ;AAED;;;GAGG;AACH,oBAAY,kBAAkB;IAC5B,UAAU,eAAe,CAAY,6BAA6B;IAClE,eAAe,oBAAoB,CAAE,yDAAyD;IAC9F,OAAO,YAAY,CAAiB,oDAAoD;IACxF,SAAS,cAAc,CAAa,yCAAyC;IAC7E,SAAS,cAAc;CACxB;AAED;;;;;;;;;;;;;;;;GAgBG;AACH;;;GAGG;AACH,eAAO,MAAM,sBAAsB,EAAG,mBAA4B,CAAC;AAEnE,oBAAY,cAAc;IACtB,wDAAwD;IACxD,4BAA4B,iCAAiC;IAC7D,sDAAsD;IACtD,0BAA0B,+BAA+B;IACzD,mCAAmC;IACnC,mBAAmB,wBAAwB;IAC3C,sCAAsC;IACtC,sBAAsB,2BAA2B;CACpD;AAED;;;;;;GAMG;AACH,oBAAY,aAAa;IACrB,qEAAqE;IACrE,qBAAqB,0BAA0B;IAE/C,0EAA0E;IAC1E,iCAAiC,sCAAsC;CAC1E;AAED;;;;;;;;;;GAUG;AACH,eAAO,MAAM,kCAAkC,EAAE,WAAW,CAAC,MAAM,CAKjE,CAAC;AAEH;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA+EG;AACH,oBAAY,UAAU;IAEpB,QAAQ,aAAa;IAGrB,eAAe,oBAAoB,CAAE,qCAAqC;IAG1E,QAAQ,aAAa,CAAsB,wBAAwB;IACnE,kBAAkB,uBAAuB,CAAE,kCAAkC;IAG7E,UAAU,eAAe,CAAO,uBAAuB;IAGvD,IAAI,SAAS,CAAqB,+BAA+B;IACjE,OAAO,YAAY,CAAc,wBAAwB;IACzD,SAAS,cAAc,CAAU,0BAA0B;IAG3D,OAAO,YAAY;CACpB;AACD;;;;;;;;;;;;;;;;;;;;;;;GAuBG;AACH,wBAAgB,oBAAoB,CAAC,MAAM,EAAE,UAAU,GAAG,OAAO,CAEhE;AACD,sDAAsD;AAEtD;;GAEG;AACH,oBAAY,UAAU;IACpB,MAAM,WAAW,CAAQ,+BAA+B;IACxD,KAAK,UAAU;CAChB;AAED;;GAEG;AACH,oBAAY,eAAe;IACzB,cAAc,mBAAmB,CAAE,sBAAsB;IACzD,KAAK,UAAU,CAAU,8BAA8B;IACvD,MAAM,WAAW;CAClB;AAED;;;GAGG;AACH,oBAAY,YAAY;IACtB,cAAc,mBAAmB;IACjC,UAAU,eAAe;IACzB,QAAQ,aAAa;IACrB,kBAAkB,uBAAuB;IACzC,eAAe,oBAAoB;IACnC;;;;OAIG;IACH,eAAe,oBAAoB;IACnC;;;;;;;;;;;;OAYG;IACH,kBAAkB,uBAAuB;IACzC;;;;OAIG;IACH,gBAAgB,qBAAqB;CACtC;AAED;;;;;;;;GAQG;AACH,oBAAY,uBAAuB;IACjC,OAAO,YAAY;IACnB,kBAAkB,uBAAuB;CAC1C;AAED;;;;;GAKG;AACH,eAAO,MAAM,mCAAmC,0BAA0B,CAAC;AAE3E;;;;GAIG;AACH,MAAM,WAAW,4BAA4B;IAC3C,cAAc,EAAE,MAAM,CAAC;IACvB,WAAW,EAAE,MAAM,CAAC;IACpB,6EAA6E;IAC7E,WAAW,EAAE,MAAM,CAAC;IACpB,kDAAkD;IAClD,MAAM,EAAE,+BAA+B,CAAC;CACzC;AAED;;;GAGG;AACH,MAAM,MAAM,+BAA+B,GAAG,UAAU,CAAC,eAAe,GAAG,UAAU,CAAC,kBAAkB,GAAG,UAAU,CAAC,QAAQ,CAAC;AAE/H;;GAEG;AACH,oBAAY,kBAAkB;IAC5B,KAAK,UAAU;IACf,YAAY,iBAAiB;IAC7B,UAAU,eAAe;IACzB,MAAM,WAAW;IACjB,WAAW,gBAAgB;CAC5B;AAED;;;GAGG;AACH,oBAAY,kBAAkB;IAC5B,YAAY,iBAAiB;IAC7B,OAAO,YAAY;IACnB,KAAK,UAAU;IACf,QAAQ,aAAa;CACtB;AAMD;;;;;;;;;;;;GAYG;AAEH;;GAEG;AACH,eAAO,MAAM,sBAAsB,EAAE,MAAM,CAAC,UAAU,EAAE,cAAc,CAmBrE,CAAC;AAEF;;;;;;;;;;;;;;;;;;;;;;;;;;GA0BG;AACH,eAAO,MAAM,sBAAsB,EAAE,SAAS,UAAU,EAU9C,CAAC;AAEX;;GAEG;AACH,eAAO,MAAM,wBAAwB,EAAE,MAAM,CAAC,UAAU,EAAE,kBAAkB,CAU3E,CAAC;AAEF;;;;;;;GAOG;AACH,oBAAY,kBAAkB;IAC5B,0BAA0B;IAC1B,SAAS,cAAc;IACvB,0BAA0B;IAC1B,UAAU,eAAe;IACzB,yBAAyB;IACzB,SAAS,cAAc;IACvB,+DAA+D;IAC/D,SAAS,cAAc;CACxB;AAED;;;;;;;;;;;;;;;;;GAiBG;AACH,oBAAY,gBAAgB;IAC1B,8DAA8D;IAC9D,IAAI,SAAS;IACb,8BAA8B;IAC9B,KAAK,UAAU;IACf,4DAA4D;IAC5D,IAAI,SAAS;IACb,yEAAyE;IACzE,mBAAmB,wBAAwB;IAC3C,yDAAyD;IACzD,SAAS,cAAc;CACxB;AAED;;;;;;;;;;;;;GAaG;AACH,oBAAY,6BAA6B;IACvC,yCAAyC;IACzC,KAAK,UAAU;IACf,2FAA2F;IAC3F,kBAAkB,uBAAuB;CAC1C;AAED,+EAA+E;AAC/E,MAAM,WAAW,kBAAkB;IACjC,QAAQ,CAAC,cAAc,EAAE,kBAAkB,CAAC;IAC5C,QAAQ,CAAC,OAAO,EAAE,gBAAgB,CAAC;IACnC;;;;;;;;;;;;;OAaG;IACH,QAAQ,CAAC,iBAAiB,EAAE,OAAO,CAAC;IACpC,QAAQ,CAAC,yBAAyB,EAAE,6BAA6B,CAAC;CACnE;AAED;;;;;;;;;;;;;;;;;;;;;;;;;GAyBG;AACH,eAAO,MAAM,oBAAoB,EAAE,MAAM,CAAC,UAAU,EAAE,kBAAkB,CAuDvE,CAAC;AAEF;;;;;;;;;;GAUG;AACH,wBAAgB,kBAAkB,CAAC,KAAK,EAAE,UAAU,EAAE,MAAM,EAAE,UAAU,GAAG,OAAO,CAMjF;AACD;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAgCG;AACH,eAAO,MAAM,eAAe,EAAE,MAAM,CAAC,UAAU,EAAE,SAAS,MAAM,EAAE,CAUjE,CAAC;AAEF;;;;;;;;;;;;;;;;;;;;;GAqBG;AACH,wBAAgB,oCAAoC,CAClD,gBAAgB,EAAE,SAAS,UAAU,EAAE,EACvC,QAAQ,CAAC,EAAE;IAAE,mBAAmB,CAAC,EAAE,OAAO,CAAA;CAAE,GAC3C,MAAM,EAAE,CAcV;AAED,sDAAsD;AAEtD;;;;;GAKG;AACH,oBAAY,aAAa;IACvB,YAAY,iBAAiB;IAC7B,WAAW,gBAAgB;CAC5B;AAED;;;;;;;GAOG;AACH,eAAO,MAAM,2BAA2B;;;;;;;;;iBAStC,CAAC;AAEH,MAAM,MAAM,qBAAqB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,2BAA2B,CAAC,CAAC;AAEhF,eAAO,MAAM,qBAAqB;;;;;;;;;;;;;;;;;;;;;;;iBAmDhC,CAAC;AAGH,MAAM,MAAM,eAAe,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,qBAAqB,CAAC,CAAC;AAMpE;;;GAGG;AACH,oBAAY,qBAAqB;IAC/B,iBAAiB,sBAAsB;IACvC,gBAAgB,qBAAqB;IACrC,eAAe,oBAAoB;IACnC,cAAc,mBAAmB;IACjC,YAAY,iBAAiB;CAC9B;AAED;;;;;;GAMG;AACH,oBAAY,iBAAiB;IAC3B,MAAM,WAAW;IACjB,UAAU,eAAe;CAC1B;AAED;;;;;GAKG;AACH,oBAAY,sBAAsB;IAChC,MAAM,WAAW;IACjB,IAAI,SAAS;IACb,IAAI,SAAS;IACb,IAAI,SAAS;CACd"}