November 2026 Summaries

Active Directory Federation Services (AD FS) can be connected to WorkOS through SAML by having an administrator create a claims-aware relying party trust from WorkOS service provider metadata, configure LDAP-based claims for required user attributes, and provide AD FS federation metadata back to WorkOS. The setup depends on correctly matching the SAML Assertion Consumer Service URL, mapping email, first name, surname, and especially User-Principal-Name to the expected outgoing claim types, as UPN provides the required identity-provider identifier. Group claims are optional for authentication but necessary for role assignment, with roles determined by mapped group IDs and refreshed when users sign in; Directory Sync may be preferable for more current group-based roles. Common failures include incorrect ACS endpoints, inaccessible or improperly addressed metadata URLs, missing UPN claims, incomplete attribute mappings, and absent or mismatched group claims. Administrators should use a fully qualified domain name for AD FS metadata, test with a user in a mapped group, and may configure connections through the WorkOS Admin Portal, which provides time-limited setup links for IT contacts.

GitHub App installation access tokens have transitioned from 40-character opaque strings to variable-length, roughly 520-character stateless tokens in a `ghs_APPID_JWT` format, while retaining the same prefix, permissions, repository scope, endpoint, and one-hour expiration. The change affects GitHub Enterprise Cloud and Data Residency installation tokens, including Actions `GITHUB_TOKEN`, but not GitHub Enterprise Server or currently `ghu_` user tokens. Organizations should treat tokens as opaque values and audit validation patterns, secret-redaction rules, database and secret-store field sizes, environment variables, and proxy or gateway header limits, since assumptions about fixed length or alphanumeric-only content can cause rejections, truncation, authentication failures, or unredacted credentials in logs. GitHub recommends supporting token patterns that allow dots, hyphens, underscores, and open-ended length, while testing with genuine stateless tokens rather than legacy fixtures. Until November 30, 2026, applications can request either format through the `X-GitHub-Stateless-S2S-Token` header, but GitHub will then ignore the header and always issue stateless tokens, making it important to remove temporary opt-out settings and complete compatibility checks before that deadline.

IdP-initiated SSO for SAML begins when an employee clicks an application tile in their identity provider’s dashboard, unlike SP-initiated flows that begin within the application and offer stronger control over request validation and session handling. WorkOS recommends configuring an application sign-in endpoint so that, after a tile click, it redirects the user to that endpoint with a connection_id; the application then initiates a normal authorization request and processes the usual callback, reducing the security concerns associated with unsolicited SAML responses. The endpoint should pass the connection ID to WorkOS’s authorization URL method, while ordinary application-initiated sign-ins can continue using their existing organization or connection selection logic. Callback handling remains unchanged, but applications should validate the returned profile’s organization ID against their own records rather than relying on email domains. Without a sign-in endpoint, WorkOS sends the authorization code directly to the default redirect URI, requiring the application to identify the tenant only after exchanging the code and reading the profile’s connection information. Customers can use SAML RelayState with a client_id to target a particular application in environments containing multiple WorkOS applications. Implementations should be tested through a real IdP tile, monitored through WorkOS session records or authentication events, and checked for redirect URI configuration, since misconfigured endpoints can cause sessions to time out.

Just-in-time provisioning for SSO resolves an incoming profile by first finding an existing identity using the identity provider ID scoped to its SSO connection, then conditionally linking it to an existing user by email, or finally creating a new user, identity, and organization membership. The central security concern is the email-linking step, because an identity provider may assert an email address that its administrator does not control; applications should link by email only when the organization has verified the email domain or the identity provider authoritatively verifies the address. Persistent identity records should use the connection ID and opaque IdP-issued ID rather than email, which can change and is not globally unique. WorkOS performs domain checks during authentication, but applications using its standalone SSO API should retain their own explicit linking safeguards, synchronize verified-domain data, and require inbox proof or preserve separate accounts when trust cannot be established. The guidance notes that similar email-based auto-linking flaws have led to account-takeover vulnerabilities and that AuthKit follows the same identity-first, verified-email-second resolution model while handling verification and unsafe-linking cases by default.

Sending custom AuthKit emails requires disabling WorkOS’s default invitation, Magic Auth, email verification, and password reset messages at the environment level, then implementing handlers that receive an event, retrieve the complete object through its corresponding API endpoint, and send an email containing the withheld secret such as a link, token, or code. This approach supports objects created through the Dashboard and hosted AuthKit interfaces, while backend-created objects can usually be emailed directly from the API response. Invitation handling must cover both creation and resend events, while custom links may require configured redirects and token handling in an application’s own authentication pages. Email verification requires particular attention because it is always enabled and invited users who sign up with passwords may need verification when WorkOS no longer sends the invitation email. Teams should test these flows in staging, account for Directory Provisioning behavior, localize emails themselves where needed, and consider Custom Email Providers instead if they only need a branded sender domain rather than full control over message content and delivery logic.

WorkOS organization-scoped custom roles allow individual organizations to define tenant-specific permissions without adding role options for every organization in an environment, complementing environment roles that are inherited across all organizations. Custom roles can be created and managed through an organization’s Roles tab or the Custom Roles API, assigned through existing membership, directory, and SSO workflows, and identified by the `OrganizationRole` type, while environment roles use `EnvironmentRole`. Role slugs are permanent and must be unique within their scope; API-supplied custom role slugs require an `org-` prefix, making deliberate, stable naming important for application logic. Permissions are managed separately through declarative replacement requests, and excessive fine-grained permissions may increase access-token size. Creating an organization’s first custom role also creates independent copies of its default role and role-priority configuration, meaning later environment-level changes no longer automatically apply, so administrators should review both settings. Custom roles cannot be deleted while assignments or identity-provider group mappings remain, although their names and descriptions can be updated without changing their slugs.

WorkOS’s React UsersManagement widget provides a ready-made organization members page that lets authorized customer administrators list and filter members, invite users, manage pending invitations, change roles, and remove members without requiring an application to build its own API endpoints. Access requires the all-or-nothing `widgets:users-table:manage` permission, which should be assigned through appropriate organization roles and validated in the rendered widget because authorization is checked when the token is used. The widget can be authorized either with a one-hour widget token minted server-side through the WorkOS SDK or with an AuthKit access-token function from an existing client session, with the latter requiring a token scoped to the active organization and containing the relevant permission. Implementation requires the WorkOsWidgets provider, the widgets package and peer dependencies, and an allowed web origin configured for browser API calls. For Directory Sync-provisioned members, administrators can edit roles in the widget, but removals must occur in the identity provider, and directory synchronization may later overwrite manually assigned roles.

Password spraying is a brute-force sub-technique in which attackers try one or a few common passwords across many valid accounts, avoiding the per-account failure thresholds and lockouts designed to stop repeated guesses against a single user. Unlike credential stuffing, which uses stolen username-password pairs, spraying relies on weak or reused passwords and is often deliberately paced over days or weeks to evade alerts. Effective detection therefore requires correlating failures across accounts, such as identifying many users submitting the same password fingerprint with few attempts per account, while accounting for legitimate patterns like bulk password resets and distributed traffic from proxies or cloud infrastructure. Recommended defenses include blocking commonly used and breached passwords during password creation, using sufficiently long passwords without rigid composition rules, maintaining both per-account and tenant-level velocity controls, applying risk-based challenges, and deploying MFA where possible. IP-based limits and account lockouts remain useful but are insufficient alone because attackers can distribute requests across many sources and exploit thresholds that are too high to detect sprays or too low to avoid denial-of-service risks. Service accounts require special attention because they often cannot use MFA, while SSO shifts password verification to identity providers rather than eliminating the threat. Public reporting on APT29 and other groups illustrates that password spraying remains a practical initial-access technique, particularly against overlooked personal and service accounts, making cross-account authentication telemetry and password-fingerprint analysis important starting points for detection.

Security questions, a form of knowledge-based authentication, are no longer accepted by NIST SP 800-63B because their answers are often discoverable, easily guessed, or difficult for legitimate users to remember, with research showing they provide weaker security and usability than alternatives such as SMS recovery codes. NIST instead recognizes saved recovery codes, issued codes sent to verified recovery addresses, recovery contacts, and repeated identity proofing for eligible accounts, with requirements that vary by assurance level. These methods require safeguards including cryptographically random codes, hashed storage for saved codes, expiration limits, rate limiting, verified recovery addresses, and notifications for recovery and authenticator-binding events. Providers must support at least one approved method, while any custom approach requires documented risk analysis. Organizations migrating away from security questions should stop collecting answers, verify existing recovery channels, encourage multiple authenticators and recovery options, delete stored answers, and treat account recovery with security controls comparable to sign-in workflows.

AuthKit distinguishes between deactivating and deleting organization memberships: deactivation changes an active membership to inactive while preserving its record, roles, and potential for reactivation, whereas deletion permanently removes the membership and associated roles, consents, invitations, and related resources. Memberships can be pending, active, or inactive, with non-active records requiring explicit status filters when listed. Deactivation revokes organization-specific sessions and pending invitations and emits an update event, but already issued access tokens remain valid until expiration and authorized WorkOS Connect applications may need separate revocation. Reactivation restores prior roles, while changing roles requires an additional update or recreating the membership with specified roles. Pending invitations cannot be deactivated and should instead be deleted to avoid orphaned pending records. Deletion is suited to applications that do not need membership history, while deactivation is preferable when former members, associated content, or future restoration matter. Directory Sync-managed memberships must be changed through the organization’s identity provider rather than the membership API. Applications should consistently use one removal model across interfaces and include token-lifetime and authorized-application cleanup in their offboarding processes.

WorkOS Agent Auth uses revocable agent instance sessions to control access tokens and refresh tokens issued to autonomous or delegated AI agents, making session revocation an essential part of customer and agent offboarding. Sessions are created when tokens are minted, may form parent-child chains when agents mint child sessions, and revoking a parent cascades to all descendants while leaving parent sessions and other instances unaffected. Organizations can list sessions by organization, blueprint, or instance and revoke individual sessions through the API or SDK; deleting an instance or blueprint permanently removes broader sets of sessions and configuration. Revocation immediately invalidates refresh tokens, but already-issued JWT access tokens remain valid until expiration when services verify them locally, typically five minutes by default and up to one hour, whereas the token validation endpoint checks the backing session and can reject revoked tokens immediately. The recommended approach is to page through session listings, revoke the appropriate root session, confirm the recorded revocation timestamp, use immediate validation for sensitive operations, and capture lifecycle events through webhooks or the Events API for audit purposes. Revocation is idempotent, but it does not automatically result from every offboarding action or undo data an agent has already accessed or changed.

Account takeover occurs when an attacker gains control of a legitimate user account, potentially enabling fraud, data exposure, and reputational harm, and it can result from attacks on four main access points: sign-in, MFA, account recovery, and already active sessions. Credential stuffing, brute-force attempts, phishing, SIM swapping, weak recovery processes, OAuth account-linking flaws, and stolen cookies or tokens are methods that target these entry points rather than synonyms for takeover itself. Recommended defenses include blocking breached passwords, using layered bot and abuse controls, adopting phishing-resistant authenticators such as passkeys or WebAuthn, minimizing SMS and other vulnerable MFA fallbacks, requiring stronger multi-step recovery verification, treating changes to recovery information as authenticator binding events, and applying secure session-cookie settings, short token lifetimes, inactivity limits, and session revocation capabilities. Detection should evaluate session behavior through signals such as new devices, impossible travel, unusual concurrent sessions, recovery or MFA changes, and failed MFA following successful password entry, while notifying users through independent channels and allowing them to review and terminate active sessions. Risk indicators can trigger additional verification but should not replace authentication factors, and effective investigation depends on logging device, location, IP, user-agent, timing, authentication events, and recovery or authenticator changes.

OWASP A07:2025 Authentication Failures, ranked seventh in the OWASP Top 10, covers weaknesses that allow systems to authenticate invalid users, including credential stuffing, brute-force attacks, weak or breached passwords, ineffective MFA and fallback processes, insecure account recovery, and unsafe session or token handling. Renamed from Identification and Authentication Failures in 2021, the category now contains 36 CWEs and adds explicit attention to hybrid password spraying, breached credentials used during account creation, weak MFA fallback paths, and failures to validate a credential’s intended scope and audience. Recommended defenses include rate limiting and monitoring login attempts, enforcing MFA, eliminating default credentials, checking passwords against breached-password and common-password lists, avoiding routine password rotation, preventing account enumeration in recovery flows, and securely generating, storing, rotating, and invalidating session identifiers. Applications using JWTs should validate issuer, audience, and scopes rather than relying only on a valid signature. The text also describes how WorkOS AuthKit and Radar address some of these areas through password policies, MFA, bot and brute-force detection, event logging, session controls, and token validation, while emphasizing that audits should examine actual implementation weaknesses across passwords, MFA, recovery, sessions, and token validation.

WorkOS Airlock now supports Fireworks AI as a bring-your-own-key inference provider for governing-agent reviews of proposed agent actions. Airlock combines non-overridable fixed rules with model-based assessments of tasks and context, allowing actions to be approved, denied, or escalated for human approval according to team-defined policies, while logging requests and decisions for later review. Administrators can enable Fireworks in Airlock settings by selecting a supported model and providing an API key; this configuration affects only governing action reviews, while policy translation, initial intent review, and approval summaries continue using existing models. Relevant policies, request context, and lookup results are sent to Fireworks for reviews, whereas credentials for agent tools remain separately managed. Airlock is currently available through early access.

Account takeover in B2B SaaS has a tenant-wide impact because a compromised user account can expose an organization’s data, integrations, and role-based administrative controls. Key risks include password login remaining enabled alongside SSO, unsafe identity linking across providers, uneven MFA coverage, long-lived sessions that retain outdated privileges, and broadly available support impersonation. The guidance describes using AuthKit and WorkOS controls such as organization-specific SSO or MFA policies, verified-email identity linking, passkeys, short access-token lifetimes, session revocation, time-limited audited impersonation, and Radar detections for threats such as brute-force attempts, impossible travel, unfamiliar devices, bots, stale accounts, and risky email domains. It emphasizes that MFA requirements differ for SSO and non-SSO users, while passkeys can reduce reliance on phishable passwords. Effective incident response also depends on enabling and retaining audit logs for session and membership changes, since administrators need evidence of how an account was accessed, what sessions were active, and what actions may have followed. Overall, the recommended approach is to configure controls per customer organization rather than applying a single global security posture, ensuring each active sign-in method has an appropriate safeguard.