Explain every decision
Every allow or deny response carries actor, resource, candidate permission, scope check, and audit metadata.
Self-hosted authorization core
Explainable permissions for systems with real business identity.
Plystra separates login accounts from the actors that operate inside a tenant, evaluates scoped resource permissions, and writes the decision trace your team can inspect later.
authz/checktrace v1.0
actor.user_id user_alice actor.member_id member_finance_reviewer resource.type invoice resource.id invoice_001 action approve
decision
allow
scope
group_tree
Core model
Built for account-identity separation.
01UserLogin account and audit subject
02UserMemberActive bridge between account and business identity
03MemberActor inside a Space
04SpaceTenant boundary for identity, resources, and audit
Capabilities
Authorization you can debug under pressure.
The v1.0 core keeps the permission model explicit: resource registry, scope resolver, role grants, active bindings, and append-only audit logs are first-class pieces of the same system.
Scope without guesswork
Self, group, group_tree, and space scopes are explicit. Global scope is reserved and disabled in v1.0.
Resource registry
Register resource types, actions, mappings, risk levels, and audit defaults as governed metadata.
Protected API surface
Core management APIs require a Bearer session or scoped API key with instance, Space, or Group admin grants. Data Console and metrics are closed unless enabled.
Workflow
One request before the business mutation.
Your application stays the system of record for business data. Plystra stores the authorization graph, resource mirror, and audit trace needed to make the decision inspectable.
backend guard
POST /api/v1/authz/check
{
"actor": {
"user_id": "user_alice",
"member_id": "member_finance_reviewer",
"user_member_id": "um_alice_finance_reviewer",
"space_id": "space_acme"
},
"resource_type": "invoice",
"resource_id": "invoice_001",
"action": "approve"
}
=> decision: allow
=> audit: append-only traceSDKs
Production clients for backend services and admin tools.
Each SDK follows the same production path: browser or gateway login supplies access tokens, while backend jobs and service-to-service checks use scoped API keys with explicit permission keys.
TypeScript
@plystra/sdk
Browser and admin clients with access-token and API-key modes
Python
plystra
Plystra and AsyncPlystra on top of httpx with token or API-key auth
Go
github.com/plystra/go-plystra
Server-side client with context-aware requests and scoped API keys
Production baseline
Self-hosted, guarded, observable.
01
Ent schema and migration guardrails
02
PostgreSQL first, self-hosted by default
03
Append-only audit log traces
04
Argon2id password hashing
05
Rotating refresh tokens stored as HMAC hashes
06
Scoped API keys for service-to-service Core access
07
Official TypeScript, Python, and Go SDKs
08
Docker Compose local baseline
09
Production guards for secrets, CORS, and public URL