For an internal HR tool on Laravel 13 where staff sign in through company SSO and nobody self-registers, which starter kit variant fits and what do you configure?

seniorshould knowfreq 22%

answer

a variant of each kit
--workos on laravel new
WORKOS_CLIENT_ID, WORKOS_API_KEY, WORKOS_REDIRECT_URL
turn off Email + Password in AuthKit
match the session timeouts

basics

~20 s

Use the WorkOS AuthKit variant of whichever kit suits the team (laravel new --workos). It delegates sign-in to AuthKit, which supports SSO, so you set the WORKOS_* variables, disable email-and-password in AuthKit and align AuthKit's inactivity timeout with Laravel's session lifetime.

solid answer

~40 s

Every official kit — React, Vue, Svelte and Livewire — has a WorkOS AuthKit variant, chosen at the laravel new prompt or with --workos; the installer creates the kit from its dev-workos branch. Instead of Fortify's password screens, sign-in goes through AuthKit, which offers SSO, social login, passkeys and email-based Magic Auth. You then set WORKOS_CLIENT_ID, WORKOS_API_KEY and WORKOS_REDIRECT_URL (for example ${APP_URL}/authenticate) from the WorkOS dashboard, and configure the homepage URL there for post-logout redirects. The docs recommend turning off Email + Password in AuthKit so the app never handles passwords, and matching AuthKit's inactivity timeout to Laravel's session lifetime (120 minutes by default). Email verification is not needed in this variant. The front-end kit itself is then chosen on team skills.

Every official kit — React, Vue, Svelte and Livewire — has a WorkOS AuthKit variant, chosen at the `laravel new` prompt or with `--workos`; the installer creates the kit from its `dev-workos` branch. Instead of Fortify's password screens, sign-in goes through AuthKit, which offers SSO, social login, passkeys and email-based Magic Auth. You then set `WORKOS_CLIENT_ID`, `WORKOS_API_KEY` and `WORKOS_REDIRECT_URL` (for example `${APP_URL}/authenticate`) from the WorkOS dashboard, and configure the homepage URL there for post-logout redirects. The docs recommend turning off Email + Password in AuthKit so the app never handles passwords, and matching AuthKit's inactivity timeout to Laravel's session lifetime (120 minutes by default). Email verification is not needed in this variant. The front-end kit itself is then chosen on team skills.

code

bash · 5 lines

bash

# Livewire front end, WorkOS AuthKit sign-in
laravel new hr-portal --livewire --workos

# the same with team support (dev-workos-teams branch)
laravel new hr-portal --livewire --workos --teams

go deeper

for a junior

Know that every official kit has a WorkOS AuthKit variant for SSO and social sign-in, chosen with --workos.

for a middle

Walk through the setup: the three WORKOS_* variables, the redirect URL, the homepage URL and what replaces Fortify's screens.

for a senior

Justify the choice for an internal tool: no passwords, no public sign-up, aligned session timeouts, and the UI kit picked on team skills.

for a principal

Weigh outsourcing identity to a hosted provider against owning Fortify-based auth: vendor dependency versus operating credentials yourself.

The requirement, restated

An internal HR tool has two authentication constraints that change which scaffold you start from:

Staff sign in with the company's existing identity provider (SSO) — no separate password to manage for this app.
No public registration — every user is an employee who already exists in the directory.

The default starter kits answer a different question: they use Laravel Fortify to give a public app its own registration, login, password reset and two-factor screens. You could strip those down, but Laravel offers a variant built for the SSO case.

The WorkOS AuthKit variants

Each official kit (React, Vue, Svelte, Livewire) exists in a WorkOS AuthKit version. You get it by choosing WorkOS as the authentication provider at the laravel new prompt, or with the --workos flag; the installer then creates the kit from its dev-workos branch (or dev-workos-teams if you also pass --teams).

What changes compared with the default kit:

	Default kit	WorkOS variant
Who authenticates the user	your app, through Fortify	WorkOS AuthKit, hosted outside your app
Sign-in methods	email + password, 2FA, passkeys	SSO, social login (Google, Microsoft, GitHub, Apple), passkeys, Magic Auth
Passwords stored in your database	yes	no, if you disable Email + Password in AuthKit
Email verification	a Fortify feature you enable	not required
Front end	unchanged	unchanged

Like every kit, the result is code you own; only the sign-in mechanism differs.

Configuration after creation

Environment variables from the WorkOS dashboard:

ini

WORKOS_CLIENT_ID=your-client-id
WORKOS_API_KEY=your-api-key
WORKOS_REDIRECT_URL="${APP_URL}/authenticate"

Homepage URL in the WorkOS dashboard — where users land after logging out.
Authentication methods: the docs recommend disabling Email + Password in AuthKit, leaving SSO, social, passkeys and Magic Auth, so the app never handles a password at all.
Session timeouts: set AuthKit's inactivity timeout to match Laravel's session lifetime — SESSION_LIFETIME, 120 minutes by default — so the two sessions expire together instead of one outliving the other.
Connect the company's identity provider inside WorkOS; that part is vendor configuration, not Laravel code.

Choosing the front-end kit for the HR tool

The authentication decision does not settle the UI stack; each variant exists for all four kits. For an internal tool the usual deciding factor is who maintains it:

a PHP-heavy team with mostly forms and tables → the Livewire variant with Flux UI;
a team already fluent in React, Vue or Svelte, or a tool with rich client-side interaction → the matching Inertia variant.

Other variants worth knowing

--teams adds team membership, a current team, invitations and routes scoped by the team's slug (/{current_team}/dashboard). Useful if HR data must be partitioned by, say, subsidiary; overkill if departments are just an attribute.
--no-authentication creates a "blank" kit with the front-end stack but no auth scaffolding — an option when authentication is handled entirely by something in front of the app.

How the decision reads in an interview

A strong answer separates the two axes explicitly:

Identity: SSO and no self-registration point to the WorkOS variant rather than Fortify's password screens.
UI stack: chosen independently, on who maintains the tool.
Tenancy: --teams only if data really is partitioned by team.
Operations: which secrets the app needs (WORKOS_API_KEY belongs in the deployment's secret store, not in the repository) and how sessions expire.

It also acknowledges the cost: sign-in now depends on an external service being reachable, so the tool's availability includes the identity provider's.

Pitfalls

Starting from the default kit and bolting SSO on later means ripping out registration and password screens you never needed.
Leaving Email + Password enabled in AuthKit reintroduces passwords the variant was meant to avoid.
Mismatched timeouts produce confusing sign-outs, or an app session that outlives the identity session.

## The requirement, restated An internal HR tool has two authentication constraints that change which scaffold you start from: - **Staff sign in with the company's existing identity provider (SSO)** — no separate password to manage for this app. - **No public registration** — every user is an employee who already exists in the directory. The default starter kits answer a different question: they use **Laravel Fortify** to give a public app its own registration, login, password reset and two-factor screens. You could strip those down, but Laravel offers a variant built for the SSO case. ## The WorkOS AuthKit variants Each official kit (React, Vue, Svelte, Livewire) exists in a **WorkOS AuthKit** version. You get it by choosing WorkOS as the authentication provider at the `laravel new` prompt, or with the `--workos` flag; the installer then creates the kit from its `dev-workos` branch (or `dev-workos-teams` if you also pass `--teams`). What changes compared with the default kit: | | Default kit | WorkOS variant | |---|---|---| | Who authenticates the user | your app, through Fortify | WorkOS AuthKit, hosted outside your app | | Sign-in methods | email + password, 2FA, passkeys | SSO, social login (Google, Microsoft, GitHub, Apple), passkeys, Magic Auth | | Passwords stored in your database | yes | no, if you disable Email + Password in AuthKit | | Email verification | a Fortify feature you enable | not required | | Front end | unchanged | unchanged | Like every kit, the result is code you own; only the sign-in mechanism differs. ## Configuration after creation 1. **Environment variables** from the WorkOS dashboard: ```ini WORKOS_CLIENT_ID=your-client-id WORKOS_API_KEY=your-api-key WORKOS_REDIRECT_URL="${APP_URL}/authenticate" ``` 2. **Homepage URL** in the WorkOS dashboard — where users land after logging out. 3. **Authentication methods**: the docs recommend disabling **Email + Password** in AuthKit, leaving SSO, social, passkeys and Magic Auth, so the app never handles a password at all. 4. **Session timeouts**: set AuthKit's inactivity timeout to match Laravel's session lifetime — `SESSION_LIFETIME`, 120 minutes by default — so the two sessions expire together instead of one outliving the other. 5. Connect the company's identity provider inside WorkOS; that part is vendor configuration, not Laravel code. ## Choosing the front-end kit for the HR tool The authentication decision does not settle the UI stack; each variant exists for all four kits. For an internal tool the usual deciding factor is **who maintains it**: - a PHP-heavy team with mostly forms and tables → the **Livewire** variant with Flux UI; - a team already fluent in React, Vue or Svelte, or a tool with rich client-side interaction → the matching **Inertia** variant. ## Other variants worth knowing - **`--teams`** adds team membership, a current team, invitations and routes scoped by the team's slug (`/{current_team}/dashboard`). Useful if HR data must be partitioned by, say, subsidiary; overkill if departments are just an attribute. - **`--no-authentication`** creates a "blank" kit with the front-end stack but no auth scaffolding — an option when authentication is handled entirely by something in front of the app. ## How the decision reads in an interview A strong answer separates the two axes explicitly: 1. **Identity**: SSO and no self-registration point to the WorkOS variant rather than Fortify's password screens. 2. **UI stack**: chosen independently, on who maintains the tool. 3. **Tenancy**: `--teams` only if data really is partitioned by team. 4. **Operations**: which secrets the app needs (`WORKOS_API_KEY` belongs in the deployment's secret store, not in the repository) and how sessions expire. It also acknowledges the cost: sign-in now depends on an external service being reachable, so the tool's availability includes the identity provider's. ## Pitfalls - Starting from the default kit and bolting SSO on later means ripping out registration and password screens you never needed. - Leaving Email + Password enabled in AuthKit reintroduces passwords the variant was meant to avoid. - Mismatched timeouts produce confusing sign-outs, or an app session that outlives the identity session.

Why does the WorkOS variant not need email verification?
Users prove their identity through AuthKit — the company SSO, a social provider, a passkey or a Magic Auth email — before the app ever sees them, so the kit does not run its own verification step. The docs note that email verification is not required for the WorkOS variants.
When would you pick the --no-authentication blank kit instead?
When something in front of the app already authenticates every request and the app should not have its own login at all. The blank kit gives the chosen front-end stack without auth scaffolding. If staff must sign in to the app itself, the WorkOS variant is the better start.

saying these in an interview costs you the question

SSO is only possible by stripping Fortify out of the default kit by hand
The WorkOS variant exists only for the React kit
The WorkOS variant still stores every user's password in the users table
--teams is required whenever users belong to departments
Session timeouts in AuthKit and Laravel are independent and need no alignment

For an internal HR tool on Laravel 13 where staff sign in through company SSO and nobody self-registers, which starter kit variant fits and what do you configure?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~3 min

The requirement, restated

The WorkOS AuthKit variants

Configuration after creation

Choosing the front-end kit for the HR tool

Other variants worth knowing

How the decision reads in an interview

Pitfalls

▾common follow-ups2 questions

▾red flags5 flags

The requirement, restated

The WorkOS AuthKit variants

Configuration after creation

Choosing the front-end kit for the HR tool

Other variants worth knowing

How the decision reads in an interview

Pitfalls

answer

go deeper