ForjioHuudisIdentityPlugipayPaymentsStorlaunchE-commerceFulkrumaFulfilmentRiplloMarketingLinkSnapShort URLsPawpadoGPU streaming
Storlaunch Docs
⌘K

Authentication overview

Storlaunch doesn't have its own login system. We use Huudis — Forjio's shared identity provider — so you can use the same email and password (or Google, or Apple account) across Storlaunch, Plugipay, Fulkruma, LinkSnap, Pawpado, Catentio, and any other Forjio product.

If you've signed up for a Forjio product before, you can sign in to Storlaunch with that same account.

One identity, many products. Your Huudis account is yours, not Storlaunch's. We don't store your password — Huudis does. We just trust the bearer tokens Huudis issues us when you sign in.

How it works (the short version)

Sign-in is a standard OpenID Connect (OIDC) flow. The five steps are:

  1. You click Sign in on storlaunch.forjio.com.
  2. Storlaunch redirects you to huudis.com/api/v1/oidc/authorize with a request to authenticate.
  3. You enter your email and password (or click Google/Apple) on Huudis.
  4. Huudis redirects you back to storlaunch.forjio.com/callback with a one-time code.
  5. Storlaunch's backend exchanges the code for a session token, sets a secure cookie on your browser, and you're in.

You never see steps 2-4 visually; they happen in two HTTP redirects.

If you want the full protocol-level walk-through (PKCE, state, nonce, refresh-token rotation), see the Plugipay authentication overview — the OIDC machinery is identical across every Forjio product, so we don't repeat it here.

Who uses this flow?

Audience Auth path
Merchant signing into the portal OIDC flow above. Cookie session in the browser.
You, calling the Storlaunch API server-to-server Not OIDC. Use a Bearer API key you mint in the dashboard.
A buyer signing into a storefront Optional. Storefronts support OTP-based buyer login (email or phone) backed by Huudis; carts and orders also work fully anonymously.

The portal cookie and the API key are independent. Revoking one doesn't affect the other.

What goes in the cookie

The Storlaunch session cookie (storlaunch_session) is a base64url payload signed with HMAC-SHA256 by Storlaunch's backend. It contains:

  • huudisAccessToken — the active access token, used to call Huudis APIs on your behalf.
  • huudisRefreshToken — used to mint new access tokens when the current one expires.
  • huudisUserId — your Huudis user ID, used as the durable identifier.
  • accountId — the active Storlaunch workspace.
  • accessExpAt — epoch millis when the access token expires (triggers proactive refresh).

The cookie is httpOnly (no JavaScript can read it) and Secure (HTTPS-only). It can't be inspected from the browser console.

The shape mirrors Plugipay's session cookie deliberately — every Forjio frontend uses the same envelope so a single auth library can power all of them.

Single sign-on across products

Because every Forjio product points at the same Huudis instance, you're already signed in to all of them once Huudis has an active session for you. Visit Plugipay after signing into Storlaunch — you skip the password screen.

You can sign out of one product without signing out of the others: each product owns its own session cookie. To sign out everywhere, click Sign out of all products in Settings → Security.

Multi-workspace

A single Huudis identity can own (or be a member of) multiple Storlaunch workspaces. We treat each workspace as a tenant boundary — storefronts, products, orders, API keys, and team members are scoped to one workspace at a time.

After signing in you land in your active workspace. The dashboard's workspace switcher (top-left) lets you change it; we store your last active choice per-product in a cookie.

Refresh-token single-flight

Storlaunch implements the same single-flight refresh cache as every other Forjio frontend. Huudis revokes the entire token family if the same refresh token is presented twice in close succession (reuse-detection), so when multiple browser tabs hit a protected endpoint at the same moment, Storlaunch's backend collapses them into a single refresh call.

You won't notice this unless something breaks — symptom of a broken single-flight is a "session expired" bounce a few minutes after sign-in. If you're forking Storlaunch's auth, preserve this behavior.

What can go wrong

  • Email not verified. If you signed up via email and didn't click the verification link, you can't sign in. Re-request the link from Sign in → Resend verification.
  • Social provider not enabled. The Google and Apple buttons only appear when the Huudis instance has those providers configured. If you see an error after clicking, the provider isn't wired — fall back to email/password.
  • Forgot password. Storlaunch can't reset it — Huudis owns passwords. Follow the Forgot password flow.
  • Session expired. Cookies live for 30 days of inactivity. After that, you'll be sent back through the OIDC flow on your next page load. No data is lost — this is just a re-auth.

Next