The parts of StepAuth, how a request travels through them, and what a decision proves.
The three roles
| Role | Who it is |
|---|---|
| Service provider | Your application. It asks for approval, and it runs the action after the approval. |
| Hub | Your SplitSecure organization. It routes each request and collects the decision. |
| Approver | A member of that organization. The member approves or denies the request. |
These guides use one example throughout. Acme MDM, at acme.example.com, manages company laptops. Before it wipes a laptop, it asks the IT lead for approval.
The flow
- Your application signs an authorization request and posts it to the hub.
- The hub accepts the request and notifies the approver that the request names.
- The approver reads the request and decides.
- The hub posts a signed decision to the callback URL of your application.
- Your application verifies the decision. For an approval, it runs the action. It then returns a result.
The decision arrives later, at your callback URL. Your application does not wait on the submission.
What each side registers
The two sides exchange metadata documents before the first request.
| Document | Holds | Goes to |
|---|---|---|
| Hub metadata | The hub entity, its public keysets, and its transport host | Your application, so that it can verify decisions |
| Service provider metadata | Your entity, your public keysets, and your default callback URL | The hub, so that it can verify your requests |
A hub accepts a signature only from a keyset that it has on record. To replace your keyset, see Rotate the keyset .
What a decision proves
Every message in both directions is a signed envelope. There is no session, no API key, and no polling. Each party signs with a keyset of two keys, an ed25519 key and a post-quantum ml-dsa-65 key, and both signatures must verify. A break of one algorithm is not enough to forge a message.
The signature covers the request bytes exactly as sent, and the decision carries a digest of those bytes. The SDK signs a request once, sends the same bytes on every retry, and keeps them until the decision arrives, so the digest proves that the decision belongs to that request and to the text the approver read.