​

Auth model

Sumvin has three auth primitives. They are not interchangeable — each one fits a specific surface and caller.

​

The three primitives

​

Decision tree

• I’m calling the Platform API on behalf of a user I authenticated → auth-provider JWT in x-juno-jwt.
• I’m exchanging a signed PINT, fetching JWKS, or looking up a user by SRI at SIS → SIS API key.
• I’m receiving a credential from a user’s browser or agent on an inbound request → PINT JWT (I verify it; I don’t issue it).

​

What each credential proves

• The auth-provider JWT proves the caller is an authenticated user of your app.
• The SIS API key proves the caller is a registered Sumvin partner with known permissions.
• The PINT JWT proves a specific user signed a specific authorisation, attested by SIS.

The three don’t stack on the same request. An inbound verifier request carries a PINT JWT — the verifier’s outbound calls to SIS then carry its own SIS API key.

​

See also

• Platform API authentication — how x-juno-jwt works
• SIS Dashboard authentication model — how auth providers attach to environments
• Identity authentication — issuer, audience, key identifiers
• Verifier headers — every header on an inbound verifier request

​

Referenced from

• Introduction
• Platform API vs SIS
• Environments, organisations, and CORS