Authentication overview
Pawpado 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 Pawpado, Plugipay, Storlaunch, Fulkruma, LinkSnap, and any other Forjio product.
If you've signed up for a Forjio product before, you can sign in to Pawpado with that same account.
One identity, many products. Your Huudis account is yours, not Pawpado'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:
- You click Sign in on pawpado.com.
- Pawpado redirects you to
huudis.com/api/v1/oidc/authorizewith a request to authenticate. - You enter your email and password (or click Google/Apple) on Huudis.
- Huudis redirects you back to
pawpado.com/callbackwith a one-timecode. - Pawpado'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.
How it works (the longer version)
Pawpado uses the OIDC authorization code flow with PKCE:
- Authorization request — Pawpado's
/api/v1/auth/startendpoint generates a randomcode_verifier, derives acode_challenge, stores both in an HTTP-only cookie, and redirects you to Huudis with the challenge. - User authentication — Huudis prompts you for credentials (or detects an active Huudis session). When you successfully authenticate, Huudis generates a one-time authorization code.
- Redirect with code — Huudis redirects you to
pawpado.com/callback?code=…&state=…. - Token exchange — The callback page POSTs the code (and the original
code_verifier) to Pawpado's backend. The backend forwards both to Huudis's token endpoint. Huudis validates the PKCE pair and returns access and refresh tokens. - Session cookie — Pawpado's backend signs a session payload containing the Huudis tokens and sets it as an
httpOnly,Securecookie. The browser presents that cookie on every subsequent request.
The refresh token rotates on every use, with reuse detection: if Huudis sees the same refresh token presented twice, it treats it as a stolen-token signal and revokes the whole token family. Pawpado implements a single-flight refresh cache to prevent this from triggering during normal browser polling.
Bearer tokens, not HMAC
Pawpado uses plain bearer tokens for API authentication — the same Huudis access tokens that authenticate browser sessions. There's no HMAC signing, no signature header, no timestamp window. Every authenticated API call carries:
Authorization: Bearer <huudis-access-token>
Access tokens are JWTs issued by Huudis and validated by Pawpado's backend. The token's sub claim is your huudisUserId, which is how Pawpado scopes data to your account.
Tokens have a one-hour lifetime by default. Use the matching refresh token (also issued by Huudis at sign-in) to mint a new access token before the old one expires. The SDKs handle this for you when you pass a Session object instead of a raw apiKey.
Who uses this flow?
| Audience | Auth path |
|---|---|
| You signing into the portal | OIDC flow above. Cookie session in the browser. |
| You, calling the API server-to-server | Same OIDC flow, then send the access token as a Bearer header. See API overview. |
| You, using the CLI on your terminal | OIDC device flow — same Huudis identity, different transport. Run pawpado auth login. |
All three paths end in the same place: a Huudis-issued JWT that Pawpado validates on every request. Revoking the Huudis session (via /api/v1/auth/logout or signing out everywhere on Huudis) invalidates all three.
What goes in the cookie
The Pawpado session cookie (pawpado_session) is a base64url payload signed by Pawpado'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 account identifier.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.
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 Pawpado — 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 on any Forjio product.
Single user, single account
Unlike some Forjio products, Pawpado has no concept of workspaces or team members. Each Huudis identity has exactly one Pawpado account: one credit balance, one storage volume, one session at a time.
If you want shared use, you'd share the Huudis credentials — but we don't recommend it. Two simultaneous Moonlight clients can't share one session anyway, and the second user would need to wait for the first to stop.
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. Pawpado 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
- Sign in — the user-facing flow with screenshots.
- Forgot password — password reset.
- Portal tour — once you're signed in.