Auth And Hosted Staging
SPAPS authentication has two identities: the application is identified by an API key, and the user is identified by a signed session or JWT. Develop your application against a hosted staging application so those boundaries match production without operating a SPAPS backend.
Environment Model
| Environment | SPAPS host | Credentials | Consumer responsibility |
|---|---|---|---|
| Staging | https://api.sweetpotato.dev | Staging application keys and allowed origins | Run and test your own app |
| Production | https://api.sweetpotato.dev | Separate production application keys and allowed origins | Deploy your own app |
Your application may run on localhost. Add its exact development origin to the staging
application; do not replace SPAPS with a local backend.
Publishable keys belong in browser applications. Secret keys belong only in server-side secret storage. Never copy a production key into a local environment.
Request Shape
An application-bound user token must match the application selected by the API key. Global human sessions remain subject to the selected application’s account-erasure and route-specific access checks. Protected session reads and credential changes recheck current session authority, including revocation.
Promotion Checklist
- Prove sign-in and refresh with staging credentials.
- Verify browser requests from every declared development and preview origin.
- Verify privileged calls from your server with a staging secret key.
- Provision separate production credentials.
- Replace keys through environment configuration; do not change application code.