Key facts
| Developer fit | Authorization-code flow in your app; keys stay server-side |
| API auth | Bearer API keys, scoped per environment and revocable on rotation |
| OAuth pattern | User-delegated OAuth runs in your app, not against the model API |
| Workforce identity | SSO with SCIM provisioning for console and admin access |
| Audit | Authentication, key lifecycle and admin events exportable to SIEM |
| Models | 30+ models behind one OpenAI-compatible API |
| Pricing | Flat monthly self-serve plans; no per-token billing |
| Free plan | plugsky-micro and plugsky-lite, no card; 14-day full-access trial |
TL;DR
- Separate user identity (OAuth in your app) from model access (scoped Plugsky keys).
- Use authorization code with PKCE for web and mobile, exchanging tokens server-side.
- Never ship a Plugsky key to the browser, a mobile binary or a third-party script.
- Issue one scoped key per environment and rotate on deploy or schedule.
- Log model, user and token usage in your own system so spend stays attributable.
How it works, step by step
- Register an OAuth client with your identity provider or authorization server, using authorization code with PKCE for public clients.
- Exchange the code server-side and store refresh tokens in an encrypted vault, never in local storage.
- Keep a scoped Plugsky key per environment in your secrets manager and load it only in backend processes.
- Map the authenticated user or tenant session to a key or quota bucket in your own broker before calling the API.
- Call the OpenAI-compatible endpoint with your usual SDK; stream responses over server-sent events where the UI waits.
- Log user, model, token count and latency on every call, and add an eval suite that runs on each prompt change.
- Rotate keys on schedule and revoke immediately when a developer or integration is removed.
Try it yourself
Open the OpenAI-compatible API tester →
Two token problems, not one
Most OAuth confusion in AI apps comes from conflating two questions: who is using the product, and what is allowed to call the model. Your application answers the first with OAuth or OIDC against your IdP. Plugsky answers the second with scoped bearer keys. A user access token should never be the credential that authorises provider spend directly, because then revocation, quotas and model allow-lists all become the client's responsibility.
Keep the model key server-side, and let your backend decide which key or plan a request is allowed to use. That also means you can change models, caps or providers behind the same user session without re-issuing tokens.
The flow to implement
The practical sequence is: the user authenticates through your authorization-code flow, your backend exchanges the code and stores refresh tokens, and a small broker resolves the session to a scoped Plugsky key. Only then does your service call /v1/chat/completions, using streaming for user-facing output and JSON mode or function calling for structured work.
- Per environment: dev, staging and production keys are different keys with different quotas.
- Per service: a summarisation worker does not share a key with a billing job.
- Rotation: rotate on a schedule, and immediately after any staff or vendor change.
- Observability: record user, tenant, model, tokens and latency on every call.
Small-team defaults that scale
Start with the free plan and its two models — plugsky-micro and plugsky-lite — to build and test without a card, then move to a paid plan or the 14-day full-access trial when traffic is real. See the live pricing page for tiers.
Because the API is OpenAI-compatible, there is no bespoke auth SDK to learn: your existing SDK, retry logic and evaluation tooling work after changing the base URL and model name. Where you need service-to-service identity, issue scoped keys per workload, or broker tokens in your gateway. Where you need console SSO for the team, Plugsky supports SSO with SCIM.
Honest comparison
| Concern | Plugsky | OAuth-first AI platforms | Do-it-yourself |
|---|---|---|---|
| User sign-in | OAuth/OIDC handled by your app or IdP | Platform-managed users | You build or buy identity |
| Model access | Scoped bearer keys, server-side | Platform tokens proxy the model | Your own gateway to any model |
| SDK support | OpenAI-compatible: keep your SDK | Vendor SDK and formats | Custom client code |
| Rotation | Per-key revoke and rotate | Platform-managed | Manual unless automated |
| Audit | Auth and key events exportable to SIEM | Platform dashboards | Your own logging stack |
Frequently asked questions
Do I need OAuth at all to use Plugsky?
No. If you are calling the API from a backend with no end users, a scoped API key is enough. Add OAuth when you have users who need to sign in to your product.
Can my front end call Plugsky directly?
No. Keep the key server-side. Front-end calls would expose a credential that can spend your quota; proxy through your backend or an edge function that holds the key.
How do I rotate keys without downtime?
Support two active keys during a rotation window: create the new key, deploy it, confirm traffic has moved off the old key in your analytics, then revoke it.
Does Plugsky offer an OAuth client-credentials flow for service-to-service auth?
The API authenticates with scoped keys. For service-to-service identity, issue a key per service or broker short-lived credentials in your own gateway so policy stays in one place.
Is SSO available for my team?
Yes. Console and admin access support SSO with SCIM provisioning, mapped to RBAC roles.
How do I test without spending?
Use the free plan, which includes plugsky-micro and plugsky-lite with no card. For higher tiers, the 14-day full-access trial covers a realistic load test before signing up.
Where do I start reading?
The quickstart in the docs covers key creation and your first OpenAI-compatible call; the security docs cover key scopes, RBAC and audit export.