@greensecurity/javascript-sdk 0.45.0-beta.16 → 0.45.0-beta.17

package/src/models/components/authenticatesuccessresponse.ts

@@ -0,0 +1,189 @@
+/*
+ * Code generated by Speakeasy (https://speakeasy.com). DO NOT EDIT.
+ */
+
+import * as z from "zod/v3";
+import { remap as remap$ } from "../../lib/primitives.js";
+import { safeParse } from "../../lib/schemas.js";
+import * as openEnums from "../../types/enums.js";
+import { OpenEnum } from "../../types/enums.js";
+import { Result as SafeParseResult } from "../../types/fp.js";
+import * as types from "../../types/primitives.js";
+import { SDKValidationError } from "../errors/sdkvalidationerror.js";
+import { Company, Company$inboundSchema } from "./company.js";
+import { Contact, Contact$inboundSchema } from "./contact.js";
+import {
+  SsoContinuation,
+  SsoContinuation$inboundSchema,
+} from "./ssocontinuation.js";
+import { UserDetails, UserDetails$inboundSchema } from "./userdetails.js";
+import { Vendor, Vendor$inboundSchema } from "./vendor.js";
+
+/**
+ * A `permanent` user token can be used to access any API endpoint as the logged in user. A `one time` token is used to authenticate the user once.
+ */
+export const AuthenticateSuccessResponseTokenType = {
+  Permanent: "permanent",
+  OneTime: "one time",
+} as const;
+/**
+ * A `permanent` user token can be used to access any API endpoint as the logged in user. A `one time` token is used to authenticate the user once.
+ */
+export type AuthenticateSuccessResponseTokenType = OpenEnum<
+  typeof AuthenticateSuccessResponseTokenType
+>;
+
+export type AuthenticateSuccessResponseUserToken = {
+  /**
+   * This token can be passed in authorization headers for this user.
+   */
+  token: string;
+  /**
+   * A `permanent` user token can be used to access any API endpoint as the logged in user. A `one time` token is used to authenticate the user once.
+   */
+  tokenType: AuthenticateSuccessResponseTokenType;
+};
+
+export type AuthenticateSuccessResponseInventoryManager = {};
+
+/**
+ * A completed login. Identical to the `User` object returned everywhere
+ *
+ * @remarks
+ * else, plus an `sso` object when the request carried a valid `sso_state`
+ * and the login therefore has a SAML flow waiting to be finished.
+ */
+export type AuthenticateSuccessResponse = {
+  /**
+   * A `gatekeeper` is a special type of service user. This type of service user is assigned to Kiosks and Apps to verify Vendors using APIs that have some access to facility data.
+   */
+  isGatekeeper?: boolean | undefined;
+  success: boolean;
+  /**
+   * Core user profile fields returned by user detail and update endpoints.
+   */
+  user: UserDetails;
+  userToken: AuthenticateSuccessResponseUserToken;
+  /**
+   * Vendor details
+   */
+  vendor?: Vendor | undefined;
+  inventoryManager?: AuthenticateSuccessResponseInventoryManager | undefined;
+  /**
+   * This object represents a contact at the system or facility level. Use it to verify vendors, create appointments, or check in visitors.
+   */
+  contact?: Contact | null | undefined;
+  /**
+   * A simplified representation of a Company, typically used in list views.
+   */
+  company?: Company | null | undefined;
+  /**
+   * Where to send the browser to finish a "Login with Green Security" flow.
+   *
+   * @remarks
+   *
+   * Present on a `200` from `POST /users/authenticate` only when the request
+   * carried a valid, unexpired `sso_state`. Its absence means the login
+   * succeeded but the SAML flow did not resume — treat the login as an
+   * ordinary one rather than retrying.
+   *
+   * This object is additive. The login itself is unaffected by it: the
+   * caller's own permanent token is in `user_token` exactly as it would be on
+   * any other successful authentication, and it is not the token embedded in
+   * `continue_url`.
+   */
+  sso?: SsoContinuation | undefined;
+};
+
+/** @internal */
+export const AuthenticateSuccessResponseTokenType$inboundSchema: z.ZodType<
+  AuthenticateSuccessResponseTokenType,
+  z.ZodTypeDef,
+  unknown
+> = openEnums.inboundSchema(AuthenticateSuccessResponseTokenType);
+
+/** @internal */
+export const AuthenticateSuccessResponseUserToken$inboundSchema: z.ZodType<
+  AuthenticateSuccessResponseUserToken,
+  z.ZodTypeDef,
+  unknown
+> = z.object({
+  token: types.string(),
+  token_type: AuthenticateSuccessResponseTokenType$inboundSchema.default(
+    "permanent",
+  ),
+}).transform((v) => {
+  return remap$(v, {
+    "token_type": "tokenType",
+  });
+});
+
+export function authenticateSuccessResponseUserTokenFromJSON(
+  jsonString: string,
+): SafeParseResult<AuthenticateSuccessResponseUserToken, SDKValidationError> {
+  return safeParse(
+    jsonString,
+    (x) =>
+      AuthenticateSuccessResponseUserToken$inboundSchema.parse(JSON.parse(x)),
+    `Failed to parse 'AuthenticateSuccessResponseUserToken' from JSON`,
+  );
+}
+
+/** @internal */
+export const AuthenticateSuccessResponseInventoryManager$inboundSchema:
+  z.ZodType<
+    AuthenticateSuccessResponseInventoryManager,
+    z.ZodTypeDef,
+    unknown
+  > = z.object({});
+
+export function authenticateSuccessResponseInventoryManagerFromJSON(
+  jsonString: string,
+): SafeParseResult<
+  AuthenticateSuccessResponseInventoryManager,
+  SDKValidationError
+> {
+  return safeParse(
+    jsonString,
+    (x) =>
+      AuthenticateSuccessResponseInventoryManager$inboundSchema.parse(
+        JSON.parse(x),
+      ),
+    `Failed to parse 'AuthenticateSuccessResponseInventoryManager' from JSON`,
+  );
+}
+
+/** @internal */
+export const AuthenticateSuccessResponse$inboundSchema: z.ZodType<
+  AuthenticateSuccessResponse,
+  z.ZodTypeDef,
+  unknown
+> = z.object({
+  is_gatekeeper: types.optional(types.boolean()),
+  success: types.boolean(),
+  user: UserDetails$inboundSchema,
+  user_token: z.lazy(() => AuthenticateSuccessResponseUserToken$inboundSchema),
+  vendor: types.optional(Vendor$inboundSchema),
+  inventory_manager: types.optional(
+    z.lazy(() => AuthenticateSuccessResponseInventoryManager$inboundSchema),
+  ),
+  contact: z.nullable(Contact$inboundSchema).optional(),
+  company: z.nullable(Company$inboundSchema).optional(),
+  sso: types.optional(SsoContinuation$inboundSchema),
+}).transform((v) => {
+  return remap$(v, {
+    "is_gatekeeper": "isGatekeeper",
+    "user_token": "userToken",
+    "inventory_manager": "inventoryManager",
+  });
+});
+
+export function authenticateSuccessResponseFromJSON(
+  jsonString: string,
+): SafeParseResult<AuthenticateSuccessResponse, SDKValidationError> {
+  return safeParse(
+    jsonString,
+    (x) => AuthenticateSuccessResponse$inboundSchema.parse(JSON.parse(x)),
+    `Failed to parse 'AuthenticateSuccessResponse' from JSON`,
+  );
+}

package/src/models/components/index.ts

@@ -5,6 +5,7 @@
 export * from "./activestatus.js";
 export * from "./alert.js";
 export * from "./appointmentsummary.js";
+export * from "./authenticatesuccessresponse.js";
 export * from "./backgroundcheckresult.js";
 export * from "./company.js";
 export * from "./companycredentiallistitem.js";
@@ -89,6 +90,7 @@ export * from "./screeningansweractionsummary.js";
 export * from "./screeningquestion.js";
 export * from "./screeningresponse.js";
 export * from "./security.js";
+export * from "./ssocontinuation.js";
 export * from "./standingappointment.js";
 export * from "./state.js";
 export * from "./subscription.js";

package/src/models/components/loginemailandpassword.ts

@@ -21,6 +21,39 @@ export type LoginEmailAndPassword = {
    * Password as entered by the user
    */
   password: string;
+  /**
+   * Opaque, signed state that Green Security issues when a third-party service
+   *
+   * @remarks
+   * provider starts a "Login with Green Security" SAML flow at
+   * `/saml/idp/sso`. The login screen receives it as the `sso_state` query
+   * string parameter and must pass it back, byte for byte, on every call to
+   * this endpoint for the remainder of the login journey — including the
+   * second call that carries an `mfa_code`.
+   *
+   * The blob is signed, not encrypted, and it expires five minutes after the
+   * service provider's request arrives. Do not parse it, shorten it, decode
+   * it, or re-encode it.
+   *
+   * **An invalid blob does not fail the login.** This is the opposite of what
+   * most integrators assume, so it is worth stating plainly: a forged, edited
+   * or expired `sso_state` is silently discarded, and the request then
+   * proceeds as an ordinary login. Valid credentials still authenticate and
+   * still return `200` — just with no `sso` object, leaving the user signed in
+   * to Green Security with no way back to the service provider that sent them.
+   * Never treat a `200` as proof that the SSO hand-off survived; check for
+   * `sso` explicitly.
+   *
+   * Every `202` response echoes the *verified* blob back in its own
+   * `sso_state` field. Always send back the value from the response you just
+   * received rather than the one you started with, so that a blob the server
+   * has already rejected is never resent, and so a client does not have to
+   * hold state of its own across the login journey.
+   *
+   * Omit this field entirely for an ordinary login that did not originate
+   * from a service provider.
+   */
+  ssoState?: string | undefined;
 };
 
 /** @internal */
@@ -28,6 +61,7 @@ export type LoginEmailAndPassword$Outbound = {
   email: string;
   mfa_code?: string | undefined;
   password: string;
+  sso_state?: string | undefined;
 };
 
 /** @internal */
@@ -39,9 +73,11 @@ export const LoginEmailAndPassword$outboundSchema: z.ZodType<
   email: z.string(),
   mfaCode: z.string().optional(),
   password: z.string(),
+  ssoState: z.string().optional(),
 }).transform((v) => {
   return remap$(v, {
     mfaCode: "mfa_code",
+    ssoState: "sso_state",
   });
 });
 

package/src/models/components/loginrequirementsfromemail.ts

@@ -17,12 +17,46 @@ export type LoginRequirementsFromEmail = {
    * A proper URI where the user should be sent after completing a SAML login. This is encoded into the response you will get if the user requires a SAML login.
    */
   returnUrl: string;
+  /**
+   * Opaque, signed state that Green Security issues when a third-party service
+   *
+   * @remarks
+   * provider starts a "Login with Green Security" SAML flow at
+   * `/saml/idp/sso`. The login screen receives it as the `sso_state` query
+   * string parameter and must pass it back, byte for byte, on every call to
+   * this endpoint for the remainder of the login journey — including the
+   * second call that carries an `mfa_code`.
+   *
+   * The blob is signed, not encrypted, and it expires five minutes after the
+   * service provider's request arrives. Do not parse it, shorten it, decode
+   * it, or re-encode it.
+   *
+   * **An invalid blob does not fail the login.** This is the opposite of what
+   * most integrators assume, so it is worth stating plainly: a forged, edited
+   * or expired `sso_state` is silently discarded, and the request then
+   * proceeds as an ordinary login. Valid credentials still authenticate and
+   * still return `200` — just with no `sso` object, leaving the user signed in
+   * to Green Security with no way back to the service provider that sent them.
+   * Never treat a `200` as proof that the SSO hand-off survived; check for
+   * `sso` explicitly.
+   *
+   * Every `202` response echoes the *verified* blob back in its own
+   * `sso_state` field. Always send back the value from the response you just
+   * received rather than the one you started with, so that a blob the server
+   * has already rejected is never resent, and so a client does not have to
+   * hold state of its own across the login journey.
+   *
+   * Omit this field entirely for an ordinary login that did not originate
+   * from a service provider.
+   */
+  ssoState?: string | undefined;
 };
 
 /** @internal */
 export type LoginRequirementsFromEmail$Outbound = {
   email: string;
   return_url: string;
+  sso_state?: string | undefined;
 };
 
 /** @internal */
@@ -33,9 +67,11 @@ export const LoginRequirementsFromEmail$outboundSchema: z.ZodType<
 > = z.object({
   email: z.string(),
   returnUrl: z.string(),
+  ssoState: z.string().optional(),
 }).transform((v) => {
   return remap$(v, {
     returnUrl: "return_url",
+    ssoState: "sso_state",
   });
 });
 

package/src/models/components/mfarequiredresponse.ts

@@ -36,6 +36,39 @@ export type MfaRequiredResponse = {
    */
   mobilePhone?: string | undefined;
   mfaMethod?: MfaMethod | undefined;
+  /**
+   * Opaque, signed state that Green Security issues when a third-party service
+   *
+   * @remarks
+   * provider starts a "Login with Green Security" SAML flow at
+   * `/saml/idp/sso`. The login screen receives it as the `sso_state` query
+   * string parameter and must pass it back, byte for byte, on every call to
+   * this endpoint for the remainder of the login journey — including the
+   * second call that carries an `mfa_code`.
+   *
+   * The blob is signed, not encrypted, and it expires five minutes after the
+   * service provider's request arrives. Do not parse it, shorten it, decode
+   * it, or re-encode it.
+   *
+   * **An invalid blob does not fail the login.** This is the opposite of what
+   * most integrators assume, so it is worth stating plainly: a forged, edited
+   * or expired `sso_state` is silently discarded, and the request then
+   * proceeds as an ordinary login. Valid credentials still authenticate and
+   * still return `200` — just with no `sso` object, leaving the user signed in
+   * to Green Security with no way back to the service provider that sent them.
+   * Never treat a `200` as proof that the SSO hand-off survived; check for
+   * `sso` explicitly.
+   *
+   * Every `202` response echoes the *verified* blob back in its own
+   * `sso_state` field. Always send back the value from the response you just
+   * received rather than the one you started with, so that a blob the server
+   * has already rejected is never resent, and so a client does not have to
+   * hold state of its own across the login journey.
+   *
+   * Omit this field entirely for an ordinary login that did not originate
+   * from a service provider.
+   */
+  ssoState?: string | undefined;
 };
 
 /** @internal */
@@ -56,10 +89,12 @@ export const MfaRequiredResponse$inboundSchema: z.ZodType<
   error: types.string(),
   mobile_phone: types.optional(types.string()),
   mfa_method: types.optional(MfaMethod$inboundSchema),
+  sso_state: types.optional(types.string()),
 }).transform((v) => {
   return remap$(v, {
     "mobile_phone": "mobilePhone",
     "mfa_method": "mfaMethod",
+    "sso_state": "ssoState",
   });
 });
 

package/src/models/components/passwordnotsetresponse.ts

@@ -20,9 +20,42 @@ export type PasswordNotSetResponse = {
    */
   error: string;
   /**
-   * URL to redirect the user to set their password (forgot password flow). Includes return_url query param when provided in the request.
+   * URL to redirect the user to set their password (forgot password flow). Carries the `return_url` and `sso_state` query params when those were provided on the request, because the browser follows this redirect and leaves the JSON body behind.
    */
   redirectUrl: string;
+  /**
+   * Opaque, signed state that Green Security issues when a third-party service
+   *
+   * @remarks
+   * provider starts a "Login with Green Security" SAML flow at
+   * `/saml/idp/sso`. The login screen receives it as the `sso_state` query
+   * string parameter and must pass it back, byte for byte, on every call to
+   * this endpoint for the remainder of the login journey — including the
+   * second call that carries an `mfa_code`.
+   *
+   * The blob is signed, not encrypted, and it expires five minutes after the
+   * service provider's request arrives. Do not parse it, shorten it, decode
+   * it, or re-encode it.
+   *
+   * **An invalid blob does not fail the login.** This is the opposite of what
+   * most integrators assume, so it is worth stating plainly: a forged, edited
+   * or expired `sso_state` is silently discarded, and the request then
+   * proceeds as an ordinary login. Valid credentials still authenticate and
+   * still return `200` — just with no `sso` object, leaving the user signed in
+   * to Green Security with no way back to the service provider that sent them.
+   * Never treat a `200` as proof that the SSO hand-off survived; check for
+   * `sso` explicitly.
+   *
+   * Every `202` response echoes the *verified* blob back in its own
+   * `sso_state` field. Always send back the value from the response you just
+   * received rather than the one you started with, so that a blob the server
+   * has already rejected is never resent, and so a client does not have to
+   * hold state of its own across the login journey.
+   *
+   * Omit this field entirely for an ordinary login that did not originate
+   * from a service provider.
+   */
+  ssoState?: string | undefined;
 };
 
 /** @internal */
@@ -35,9 +68,11 @@ export const PasswordNotSetResponse$inboundSchema: z.ZodType<
   success: types.boolean(),
   error: types.string(),
   redirect_url: types.string(),
+  sso_state: types.optional(types.string()),
 }).transform((v) => {
   return remap$(v, {
     "redirect_url": "redirectUrl",
+    "sso_state": "ssoState",
   });
 });
 

package/src/models/components/passwordrequiredresponse.ts

@@ -3,6 +3,7 @@
  */
 
 import * as z from "zod/v3";
+import { remap as remap$ } from "../../lib/primitives.js";
 import { safeParse } from "../../lib/schemas.js";
 import { Result as SafeParseResult } from "../../types/fp.js";
 import * as types from "../../types/primitives.js";
@@ -18,6 +19,39 @@ export type PasswordRequiredResponse = {
    * Error describing the exact condition of what further steps are needed to finish the login process.
    */
   error: string;
+  /**
+   * Opaque, signed state that Green Security issues when a third-party service
+   *
+   * @remarks
+   * provider starts a "Login with Green Security" SAML flow at
+   * `/saml/idp/sso`. The login screen receives it as the `sso_state` query
+   * string parameter and must pass it back, byte for byte, on every call to
+   * this endpoint for the remainder of the login journey — including the
+   * second call that carries an `mfa_code`.
+   *
+   * The blob is signed, not encrypted, and it expires five minutes after the
+   * service provider's request arrives. Do not parse it, shorten it, decode
+   * it, or re-encode it.
+   *
+   * **An invalid blob does not fail the login.** This is the opposite of what
+   * most integrators assume, so it is worth stating plainly: a forged, edited
+   * or expired `sso_state` is silently discarded, and the request then
+   * proceeds as an ordinary login. Valid credentials still authenticate and
+   * still return `200` — just with no `sso` object, leaving the user signed in
+   * to Green Security with no way back to the service provider that sent them.
+   * Never treat a `200` as proof that the SSO hand-off survived; check for
+   * `sso` explicitly.
+   *
+   * Every `202` response echoes the *verified* blob back in its own
+   * `sso_state` field. Always send back the value from the response you just
+   * received rather than the one you started with, so that a blob the server
+   * has already rejected is never resent, and so a client does not have to
+   * hold state of its own across the login journey.
+   *
+   * Omit this field entirely for an ordinary login that did not originate
+   * from a service provider.
+   */
+  ssoState?: string | undefined;
 };
 
 /** @internal */
@@ -29,6 +63,11 @@ export const PasswordRequiredResponse$inboundSchema: z.ZodType<
   requires: types.literal("password"),
   success: types.boolean(),
   error: types.string(),
+  sso_state: types.optional(types.string()),
+}).transform((v) => {
+  return remap$(v, {
+    "sso_state": "ssoState",
+  });
 });
 
 export function passwordRequiredResponseFromJSON(

package/src/models/components/samlloginrequiredresponse.ts

@@ -28,6 +28,39 @@ export type SamlLoginRequiredResponse = {
    * This is the URL that should be opened to initiate the SAML login flow
    */
   ssoUrl: string;
+  /**
+   * Opaque, signed state that Green Security issues when a third-party service
+   *
+   * @remarks
+   * provider starts a "Login with Green Security" SAML flow at
+   * `/saml/idp/sso`. The login screen receives it as the `sso_state` query
+   * string parameter and must pass it back, byte for byte, on every call to
+   * this endpoint for the remainder of the login journey — including the
+   * second call that carries an `mfa_code`.
+   *
+   * The blob is signed, not encrypted, and it expires five minutes after the
+   * service provider's request arrives. Do not parse it, shorten it, decode
+   * it, or re-encode it.
+   *
+   * **An invalid blob does not fail the login.** This is the opposite of what
+   * most integrators assume, so it is worth stating plainly: a forged, edited
+   * or expired `sso_state` is silently discarded, and the request then
+   * proceeds as an ordinary login. Valid credentials still authenticate and
+   * still return `200` — just with no `sso` object, leaving the user signed in
+   * to Green Security with no way back to the service provider that sent them.
+   * Never treat a `200` as proof that the SSO hand-off survived; check for
+   * `sso` explicitly.
+   *
+   * Every `202` response echoes the *verified* blob back in its own
+   * `sso_state` field. Always send back the value from the response you just
+   * received rather than the one you started with, so that a blob the server
+   * has already rejected is never resent, and so a client does not have to
+   * hold state of its own across the login journey.
+   *
+   * Omit this field entirely for an ordinary login that did not originate
+   * from a service provider.
+   */
+  ssoState?: string | undefined;
 };
 
 /** @internal */
@@ -41,10 +74,12 @@ export const SamlLoginRequiredResponse$inboundSchema: z.ZodType<
   error: types.string(),
   sso_instructions: types.optional(types.string()),
   sso_url: types.string(),
+  sso_state: types.optional(types.string()),
 }).transform((v) => {
   return remap$(v, {
     "sso_instructions": "ssoInstructions",
     "sso_url": "ssoUrl",
+    "sso_state": "ssoState",
   });
 });
 

package/src/models/components/ssocontinuation.ts

@@ -0,0 +1,71 @@
+/*
+ * Code generated by Speakeasy (https://speakeasy.com). DO NOT EDIT.
+ */
+
+import * as z from "zod/v3";
+import { remap as remap$ } from "../../lib/primitives.js";
+import { safeParse } from "../../lib/schemas.js";
+import { Result as SafeParseResult } from "../../types/fp.js";
+import * as types from "../../types/primitives.js";
+import { SDKValidationError } from "../errors/sdkvalidationerror.js";
+
+/**
+ * Where to send the browser to finish a "Login with Green Security" flow.
+ *
+ * @remarks
+ *
+ * Present on a `200` from `POST /users/authenticate` only when the request
+ * carried a valid, unexpired `sso_state`. Its absence means the login
+ * succeeded but the SAML flow did not resume — treat the login as an
+ * ordinary one rather than retrying.
+ *
+ * This object is additive. The login itself is unaffected by it: the
+ * caller's own permanent token is in `user_token` exactly as it would be on
+ * any other successful authentication, and it is not the token embedded in
+ * `continue_url`.
+ */
+export type SsoContinuation = {
+  /**
+   * An absolute, single-use URL on Green Security's domain. Navigate the
+   *
+   * @remarks
+   * browser to it (a full page navigation, not `fetch`); it answers with a
+   * self-submitting form that POSTs the signed `SAMLResponse` and the
+   * original `RelayState` to the service provider's assertion consumer
+   * service URL.
+   *
+   * The `token` in this URL is a separate **one-time** token that is
+   * consumed the first time the URL is followed, so the URL is good for
+   * exactly one navigation. It is not the caller's permanent token, which
+   * is returned unchanged in `user_token`. Treat the URL as a secret:
+   * whoever follows it first receives that user's assertion.
+   *
+   * Never fetch this URL from your own back end: the response is meant for
+   * the user's browser, and posting the assertion from anywhere else
+   * breaks the flow.
+   */
+  continueUrl: string;
+};
+
+/** @internal */
+export const SsoContinuation$inboundSchema: z.ZodType<
+  SsoContinuation,
+  z.ZodTypeDef,
+  unknown
+> = z.object({
+  continue_url: types.string(),
+}).transform((v) => {
+  return remap$(v, {
+    "continue_url": "continueUrl",
+  });
+});
+
+export function ssoContinuationFromJSON(
+  jsonString: string,
+): SafeParseResult<SsoContinuation, SDKValidationError> {
+  return safeParse(
+    jsonString,
+    (x) => SsoContinuation$inboundSchema.parse(JSON.parse(x)),
+    `Failed to parse 'SsoContinuation' from JSON`,
+  );
+}

package/src/models/operations/postauthenticate.ts

@@ -26,7 +26,7 @@ export type PostAuthenticateResponseBody =
   | components.PasswordNotSetResponse;
 
 export type PostAuthenticateResponse =
-  | components.User
+  | components.AuthenticateSuccessResponse
   | components.MfaRequiredResponse
   | components.SamlLoginRequiredResponse
   | components.PasswordRequiredResponse
@@ -85,7 +85,7 @@ export const PostAuthenticateResponse$inboundSchema: z.ZodType<
   z.ZodTypeDef,
   unknown
 > = smartUnion([
-  components.User$inboundSchema,
+  components.AuthenticateSuccessResponse$inboundSchema,
   z.union([
     components.MfaRequiredResponse$inboundSchema,
     components.SamlLoginRequiredResponse$inboundSchema,

package/src/react-query/usersPostAuthenticate.ts

@@ -81,6 +81,43 @@ export type UsersPostAuthenticateMutationError =
  * 3. Site redirects to your selected `return_url`
  * 4. The `user_token` will be appended as a query string parameter to your `return_url` - you must parse this token and store it
  * 5. Fetch the user object from `/users/me` using the token
+ *
+ * ## Finishing a "Login with Green Security" flow
+ *
+ * Green Security is also a SAML2 **identity provider**. When a third-party service provider sends a user to
+ * `/saml/idp/sso` to sign in with their Green Security account, the user lands on a Green Security login screen
+ * carrying an `sso_state` query string parameter. That parameter is a signed, five-minute record of which service
+ * provider is waiting, where its assertion consumer service lives, and what `RelayState` it sent.
+ *
+ * Authentication itself is unchanged - the user may still need a password, an MFA code, a magic link or a round trip
+ * to their own SAML IdP, and every `requires` value above applies as normal. The only difference is that you must
+ * echo `sso_state` back on **every** call in the sequence, unchanged, including the follow-up that carries the
+ * `mfa_code`.
+ *
+ * Each `202` response carries the verified blob back to you in its own top-level `sso_state` field. Send back the
+ * value from the response you just received rather than the one you started with. The two are normally the same
+ * string, but re-sending your original copy is how a blob the server has already rejected gets resent, and it forces
+ * you to hold login state you would otherwise not need.
+ *
+ * 1. Read `sso_state` from the query string of the login screen you were sent to
+ * 2. Run the login exactly as you would otherwise, adding `sso_state` to each request body and taking the value for
+ *    the next request from the previous `202` response
+ * 3. On the `200` response, read `sso.continue_url`
+ * 4. Navigate the browser to `sso.continue_url` - a full page navigation, not a background fetch. It answers with a
+ *    self-submitting form that delivers the signed `SAMLResponse` and the original `RelayState` to the service
+ *    provider
+ * 5. The service provider validates the assertion and the user is signed in on their side
+ *
+ * On the `password_reset` leg the blob is **also** appended to `redirect_url` as a query parameter, alongside
+ * `return_url`. The browser follows that redirect and leaves the JSON body behind, so anything the remaining legs of
+ * the login still need has to ride the URL. Preserve the query string exactly as given.
+ *
+ * An invalid `sso_state` never fails a login. A forged, edited or expired blob is silently dropped and the request is
+ * then treated as an ordinary login, so valid credentials still return `200` - just with no `sso` object. Check for
+ * `sso` explicitly rather than reading `200` as proof the hand-off survived. When it is absent, do not retry with the
+ * same blob; the user has to start again from the service provider. See the
+ * [Login with Green Security](https://greensecurity.apidocumentation.com/guides/sso-login-with-green-security)
+ * guide for the service provider half of this flow.
  */
 export function useUsersPostAuthenticateMutation(
   options?: MutationHookOptions<