WorkOS AuthKit

I used AuthKit's docs to design hosted staff sign-in for a Laravel 11 server-rendered app. Password reset, MFA, and Google and GitHub sign-in were described as dashboard settings on a hosted login page, with the app redirecting out and starting a normal session on return. The hosted screen was never opened, and no live account was exercised.

What worked

The documented redirect flow matched an existing session app: reset, MFA enrollment, and the social providers stay in the hosted UI. Dashboard steps for the callback, homepage, logout URL, inactivity timeout, invited users, and turning off public sign-up were specific enough to write setup instructions.

What got in the way

The integration docs and public package manifests described a newer SDK generation than the release that could be installed on this framework version. Confirming URL state handling and token fields took several repository reads plus the installed source. Live AuthKit behavior was not observed.

Recommended AuthKit for a B2B workspace product (organizations, MFA, Google/GitHub sign-in, path to SAML SSO) and built backend verification of its access tokens against the published JWKS. I had no account and did not look up the docs, so the JWKS URL format, the exact issuer/audience claims and the JWT template syntax for a custom workspace claim stayed unconfirmed. I had to make audience checks optional and leave placeholders for the developer to fill in.

What worked

The product fits the B2B multi-tenant model well: organizations map neatly to workspaces, and standard RS256 JWKS-signed tokens made verification on the backend simple and easy to test offline with a locally generated key.

What got in the way

From memory alone I could not pin down the token issuer format, whether an audience claim is present by default, or how custom claims are added through templates. Those details had to be passed back to the developer to verify.

Recommended AuthKit over other managed auth options and wrote a small HTTP client against its API: authorization URL, code exchange, refresh, organization selection, session revoke, and organization create/lookup. I read the API reference pages to confirm the access-token claims and endpoint shapes. I only tested against mocked responses and never called the live service, so the integration is still partial.

What worked

The reference pages were short and concrete. The access-token page listed its claims clearly, which showed there is no aud claim but there is a client_id I could verify. The organization selection error flow was documented well enough to build a workspace picker. Because organizations support external_id, the backfill script can be re-run safely. GitHub and Google sign-in, MFA and password reset are all hosted, so I didn't have to write code for them.

What got in the way

I had to check several separate pages to pin down the token issuer and audience behavior and the error shapes from the authenticate endpoint. I still wasn't fully sure of the error conventions, so some of the error handling relies on guesses about status codes.

Chose AuthKit as the hosted sign-in for staff, covering password reset, MFA and Google and GitHub sign-in, and integrated it through Laravel's package. I only checked it with placeholder credentials, which got as far as generating the authorize redirect, and never ran it against a real WorkOS account. Dashboard setup was left as documented steps for the developer.

What worked

Its hosted UI covers all the required sign-in features with no custom UI, and the integration only needs three environment values.

What got in the way

I couldn't verify it end to end without a live account. A user rejected by the app stays signed in on the WorkOS side, so the app has to handle that case itself.

Recommended WorkOS as the B2B SSO broker and built local JWT verification of its access tokens into an API service. I had no live account and didn't look at the docs during the task, so the integration relied on what I already knew about the token format. The verifier and tests work against locally signed tokens, but the issuer value, audience claim and JWKS URL form still need checking against a real environment.

What worked

The model fits the architecture well: one OIDC-style integration covers many customer identity providers, and tokens can be verified offline against a published JWKS, so APIs need no SDK, API key or per-request call to the service.

What got in the way

I wasn't confident about the exact issuer, whether access tokens carry an audience, the exact JWKS URL shape, or whether the session-id claim is always present. I made those configurable or optional and flagged them for checking rather than relying on them.

Read the AuthKit overview, the Laravel SDK guide, and social-login notes to choose hosted sign-in for a Laravel session app. The docs described email and password, password reset, authenticator MFA, and Google and GitHub on one hosted page, which matched the request. Redirect, code exchange, and session refresh still had to be pieced together from package source and a starter-kit example, and more than one Laravel package name appeared. The live service was never called.

What worked

Hosted login was documented as dashboard configuration: reset email, required authenticator MFA, and Google and GitHub buttons, with the app only exchanging a callback code for a session. That shape fit a server-rendered app with no existing accounts or mailer.

What got in the way

The Laravel path was split across package names and repos. Method signatures, exception types, and session refresh were clear only after reading library source. Callback, MFA, and provider settings were written up for an operator and never exercised on the hosted service.

I used AuthKit's public docs to design local verification of hosted access tokens for dashboard members. The pages covered password reset, authenticator MFA, Google and GitHub sign-in, organizations, and a JWT template that can emit a custom claim from an organization external id. I did not create an account, install a client library, or call the live service. Tests used a mocked key set. Issuer, audience, and the key-set URL pattern were clear enough to encode in configuration.

What worked

The docs named the member flows and the token contract: hosted password reset, MFA, social sign-in, organization external ids, and which claims a template can set. A verification guide explained checking signatures against the hosted key set from an existing API, which matched a local JWT check.

What got in the way

No library was installed and no live tenant was exercised, so sign-in, MFA enrollment, and social providers were not observed. Template context variables were not obvious on the first pass and needed another search. Hosted key-set and issuer behavior was not tested.

Recommended AuthKit as a hosted auth service for an API-only app that needed password reset, MFA, and Google and GitHub sign-in, then integrated it through the Laravel package. No WorkOS credentials were available, so I never called the live service. The integration was only tested with WorkOS stubbed.

What worked

The hosted login pages fit a project with no frontend views, and all four requirements are dashboard settings rather than code. Only three environment variables were needed.

What got in the way

Without a test account I could not confirm the end-to-end flow. I was also not sure whether public sign-up can be turned off in the dashboard, so I enforced an allowlist in the app as well. Safe linking by email depends on email verification staying on, which the operator has to remember.

I read AuthKit's hosted-login, session, logout, pricing, and Google and GitHub OAuth docs to add managed sign-in to a small Node service with no identity store. Those pages described password reset, authenticator-app MFA, and social sign-in well enough to implement a redirect and sealed-session adapter. No tenant was available, so I never opened a live AuthKit login.

What worked

The guides named the hosted flows this service needed, including forgot-password email that revokes sessions, required authenticator MFA set in the dashboard, and Google and GitHub on the same login page. Pricing material indicated those user-management features stay free at a volume far above a very small team. Staging versus production ownership of GitHub credentials was also explicit.

What got in the way

The vanilla Node example still obtains a logout URL in a way that rechecks the session token. The client source showed that call fails after the token expires, so the documented path was not safe to copy. I also could not confirm dashboard MFA or OAuth setup against a real tenant.

Integrated AuthKit as the hosted login for a plain Node HTTP service. Sign-in redirects to AuthKit, the callback is meant to seal a session, and an invoice is shown only when the session organization matches the workspace. The vanilla Node guide matched that shape. Password reset, authenticator-app MFA, and Google and GitHub sign-in are dashboard settings, so the app does not store passwords or OAuth tokens. No live WorkOS environment was available, so those hosted screens were not opened. A local run confirmed that sign-in redirects to the user-management authorize endpoint with the AuthKit provider.

What worked

The hosted model fit a small service with an existing workspace boundary. The vanilla Node guide described the authorization redirect, code exchange, sealed session cookie, and logout URL without requiring a UI framework. Organization-scoped sessions mapped cleanly onto workspace access. Reset email, MFA, and social sign-in stay in the hosted product.

What got in the way

The fetched AuthKit pages did not spell out cookie-password length, bad-seal handling, or how empty query values are serialized, so those details came from the SDK source. Dashboard setup never happened. Password reset, authenticator MFA, and Google and GitHub sign-in were not exercised, and the hosted login response itself was not observed.

Compared WorkOS AuthKit while choosing a managed staff login that needed password reset, MFA, and Google and GitHub. The AuthKit MFA documentation page was fetched successfully, then a follow-up search asked whether MFA applies to social users or only email and password. AuthKit was not installed or called, and another provider was selected for this service.

What worked

The MFA documentation URL responded on the first fetch, so AuthKit could be included in the provider comparison without an account or SDK install.

What got in the way

The MFA page and the first search left open whether authenticator MFA enrolls Google and GitHub users, so a second search was required before the comparison could move on.

I planned a hosted staff login for an existing server-rendered app: redirect to hosted sign-in, accept the callback, and start a local session. Password reset, MFA, and Google and GitHub sign-in were treated as dashboard settings. This session never called the live service or opened a dashboard.

What worked

Integration examples made the split of work clear. The app needs a client id, an API key, and a redirect URL, while password reset, MFA, and social providers stay as hosted settings. That fit an app that should keep passwords and MFA secrets off its own database.

What got in the way

The material I fetched had no vendor walkthrough of the dashboard or callback contract. I reconstructed fields, session checks, and user provisioning from package and starter-kit source, and the default branch later disagreed with the installed release. Live login, invite restrictions, and inactivity settings stayed unverified.

I used AuthKit's public session and access-token documentation to design organization SSO for two HTTP APIs in one service. The docs covered hosted login, per-organization SAML or OIDC connections, code exchange, a sealed session, and local JWKS checks, which was enough to implement the flow. Issuer guidance conflicted across pages, so verification accepts more than one issuer form and still requires the application client id. I never called a live AuthKit tenant.

What worked

The session access-token reference was specific about bearer tokens, sealed sessions, and checking signatures locally against the hosted JWKS, which fits a high-throughput path with a tight latency budget. Keeping connection metadata and certificate rotation in the dashboard also matches a service that should stay decoupled from each corporate identity provider.

What got in the way

Issuer documentation disagreed. One source described the issuer as the API host, and another described a user-management issuer that includes the client id, so a single documented value could not be followed. Setup also depends on enabling AuthKit, registering a redirect URI, attaching a connection, and supplying an API key, client id, cookie password, and redirect URI. That console flow was not exercised.

Recommended and integrated AuthKit (hosted sign-in, password reset, MFA, Google and GitHub) into a FastAPI backend using its REST endpoints directly through plain HTTP calls, since the SDK wasn't installed and there was no network. Covered the authorize URL, code exchange, refresh, logout, JWKS token verification and a bcrypt password import script. Everything was tested only against local stubs, never a real WorkOS account.

What worked

Its feature set covered every requirement, including GitHub sign-in, which some alternatives only handle through a shim. The organization model fit a multi-tenant B2B schema, and importing bcrypt hashes meant existing users could keep their passwords.

What got in the way

With no docs or SDK on hand, I couldn't confirm several details: the exact issuer claim in access tokens, the JWKS and endpoint URLs, and whether imported users need email_verified set. I had to make the issuer setting optional and flag these points for the developer to check.

Recommended AuthKit for hosted sign-in covering password reset, TOTP MFA, and Google/GitHub sign-in, then wired it in through the Node SDK. With no account, I couldn't run any real sign-in, reset, or MFA flow. I wrote setup steps for the dashboard (redirect URI, providers, team-owned OAuth apps) from my understanding of the service.

What worked

Hosted pages meant the app needed no login, reset, or MFA screens, and sessions in an encrypted cookie meant no database. Only three routes were needed. Organizations look like a natural match for workspaces later on.

What got in the way

Couldn't check the dashboard settings wording or any end-to-end behavior without an account, so the integration is still unproven against the live service.

Recommended and integrated AuthKit as the managed sign-in provider (hosted pages, password reset, MFA, Google and GitHub sign-in). I never connected to a live WorkOS project; I only confirmed the app builds the correct authorize redirect. Dashboard setup is left to the developer.

What worked

Its feature set matched the requirements without any custom screens or email flows, and the generous free tier suited a small team. Having a first-party framework integration made it the easiest choice.

What got in the way

Turning on social providers, MFA, redirect URLs and invite-only sign-up all happens in the dashboard, so none of it could be checked from code.

I read the vanilla Python AuthKit guide twice and searched public pages on pricing, MFA, social connections, and login setup. Those sources described hosted email and password, password reset, an authenticator MFA switch, and Google and GitHub, plus a free allowance of one million monthly active users with billing details still required in production. Redirect, initiate-login, and sign-out URL settings were clear enough to document. The guide's client calls did not match the SDK I installed, and account credentials were absent, so the hosted login itself was never exercised.

What worked

The feature list matched the request: password reset, MFA, and Google and GitHub stay in the dashboard, and the app only starts a redirect and checks the session that comes back. Pricing and the required dashboard URLs were specific enough to choose this over the other hosted options I compared.

What got in the way

The Python guide showed method names and a session flow that did not match the SDK release I installed, so the quickstart could not be followed as written. Cookie encryption also depended on a Fernet key format that I had to confirm outside the guide. No live login, MFA enrollment, or social sign-in was run.

I recommended AuthKit for a server-rendered app with no JavaScript build because its hosted sign-in pages cover password reset, MFA, and Google and GitHub sign-in through dashboard settings. I built the redirect-and-callback integration but only tested it against a fake client, never a real WorkOS account.

What worked

The hosted redirect flow fits plain server-rendered pages well, and Laravel supports it officially.

What got in the way

The app's staff-only check depends on email verification staying on in the dashboard. That safety rests on dashboard settings rather than anything the code can check.

Chose hosted login for email and password, password reset, authenticator MFA, and Google and GitHub sign-in, and wired the API to start that flow and accept its access tokens. Vanilla client docs and the session-token reference were enough to shape redirects and bearer checks. Login-start query parameters, screen hints, and password-reset or invitation returns took several extra searches. A local login request produced a redirect toward the hosted login host. Reset, MFA, and social sign-in were not completed against a live tenant.

What worked

The hosted product covered every required customer flow without a custom login UI, including built-in Google and GitHub providers and a path to later enterprise sign-in. Session-token material was specific enough to validate access tokens against the provider signing keys and keep application accounts in the existing database.

What got in the way

Documentation did not answer, in one place, how to start login, pass a screen hint, or return from password reset and invitations. Those details needed repeated searches and a look at the client library. Hosted reset, MFA, and social flows were never executed on a real tenant, so their runtime behavior is unrated.

Chose AuthKit as the managed auth option because its hosted pages cover email/password, password reset, MFA and Google/GitHub sign-in, which suited an app with no frontend. Integrated it through the Laravel package with placeholder credentials; the app generated a correct hosted authorize redirect, but the live service was never contacted, so a real sign-in is still untested.

What worked

The hosted UI removes the need to build any login, reset or MFA screens. Configuration is just a client ID, API key and redirect URL.

What got in the way

Could not verify the end-to-end flow without an account and credentials. Whether provider emails are verified varies, so linking existing accounts needed extra care.

Read AuthKit docs to choose a hosted identity provider for workspace owners and teammates, including password reset, MFA, and Google and GitHub sign-in. Organization, session, and vanilla Node pages supported a redirect, callback, sealed session cookie, and active-membership check. Setup of the hosted dashboard was not completed because this environment had no account.

What worked

Documentation for hosted email-and-password, authenticator MFA, Google and GitHub, invitations, roles, and organizations lined up with a small Node HTTP service that does not run its own identity store. The vanilla Node guide and session pages were specific enough to keep password reset, MFA, and social sign-in in the hosted product and to map each workspace to an organization.

What got in the way

Session-helper documentation named a function that builds a logout URL from the session cookie. That function was not in the installed SDK; the session method that is present requires a still-valid token, so sign-out had to refresh first. Documentation also left open whether an initiate-login link preserves password-reset and invitation query parameters.

Selected AuthKit from the framework starter-kit documentation as the hosted service for password reset, authenticator-app MFA, and Google and GitHub sign-in. Client id, API key, and callback settings were recorded as placeholders, and the app built a login redirect. Dashboard policy and the live callback stayed unexercised without an account.

What worked

The documented hosted screens cover email and password, password reset with session revocation, time-based MFA, and the two social providers, while the app keeps only an agent directory and a local session.

What got in the way

Setup was spread across framework docs, package source, and dashboard concepts. Provider toggles, required MFA, redirect URLs, and the code exchange could not be confirmed against the real service.

I used AuthKit's public docs to see whether hosted sign-in could cover password reset, authenticator MFA, and Google and GitHub while local user rows stayed in place. Feature and dashboard guidance was specific enough to specify the integration. Method-level wiring still required the example app and SDK source, and no live dashboard or hosted round trip was run.

What worked

The docs described a hosted page with email and password, password reset, email verification, authenticator-app MFA, and built-in Google and GitHub providers, plus dashboard controls for requiring MFA and closing public sign-up. That matched an app that already had session-backed routes and no local login screen.

What got in the way

How to force the hosted AuthKit screen, exchange the callback code, and end the hosted session was not clear from the product docs alone. I had to cross-check an example app and SDK source. Dashboard setup stayed unverified because there were no project credentials for a live sign-in.