Biatec OIDC lets your app delegate sign-in to Google or Microsoft and receive a standard OpenID Connect token carrying an Algorand identity — then, with the right scope, use that same token to sign transaction groups against a spending limit the wallet owner controls. Keys stay in the owner's own Google Drive or OneDrive, never on our servers.
Everything below is anchored at https://oidc.biatec.io. Discovery advertises the exact same set.
Standard OIDC discovery metadata — issuer, endpoints, supported scopes/claims, and jwks_uri. Start integration here.
The RS256 public key(s) used to verify tokens issued by this provider. Rotate your cached copy on kid change.
Standard response_type=code flow with optional PKCE, plus a legacy direct id_token flow. Shows the Google/Microsoft picker unless idp= is set.
grant_type=authorization_code (with PKCE code_verifier) or refresh_token. Confidential clients authenticate with a client secret; public clients rely on PKCE.
Claims for the caller's own access token, sent as Authorization: Bearer. Returns primary_seed_address when the user granted storage access.
RFC 7662-style token introspection. /verify returns the identical shape and also accepts the token via the Authorization header.
Clears the provider session cookie and redirects to an allowlisted post_logout_redirect_uri. Also reachable as /logout.
Request only what you need. sign and manage-limits are wallet-API scopes — they must be explicitly allowlisted for your client, they are never granted implicitly.
Establishes the OIDC flow itself. Grants → sub, iss, aud, exp, iat, nonce.
Grants → name, preferred_username — a short form derived from the Algorand address when one exists.
Grants → email, and (when Drive/OneDrive access was granted) primary_seed_address and biatec_idp (which provider backs the wallet).
Grants → a sign: true claim on the access token. Required to call POST /wallet/sign — see the Wallet API section below.
Grants → a manage-limits: true claim on the access token. Required to read or update the wallet owner's own spending limit.
Claims are explicit, not inferred. The wallet API never re-parses the space-separated scope claim at request time — each granted wallet scope stamps its own dedicated claim onto the access token when it's issued, and every wallet endpoint checks that exact claim before doing anything.
Every call below requires Authorization: Bearer <access_token> from /token, with the matching scope granted at /authorize.
sign scopeThe presented access token must carry the sign claim, or the request is rejected with 403 insufficient_scope.
Assemble your Algorand transaction(s) client-side as usual (assign a group id across them if it's more than one), then base64-encode each transaction's msgpack bytes.
curl -X POST https://oidc.biatec.io/wallet/sign \ -H "Authorization: Bearer <access_token>" \ -H "Content-Type: application/json" \ -d '{ "transactions": ["", " "], "accessToken": " " }'
accessToken is the wallet owner's current Google/Microsoft access token — it's what lets Biatec OIDC read and decrypt the self-custody account file for this one call. It is never stored.
Before anything is signed, each pay or axfer transaction in the group is checked against the owner's spending limit. If any one exceeds it, the whole group is rejected with 403 spending_limit_exceeded and nothing is signed — never a partial group.
{
"signedTransactions": ["", ""]
}
manage-limits scopeReading the limit is gated the same as changing it — a sign-only token cannot call this.
curl https://oidc.biatec.io/wallet/limits \
-H "Authorization: Bearer <access_token>"
{ "maxAmountPerTransaction": 5000000 }
The limit is in microAlgos for a payment, or base units of the relevant asset for an asset transfer. 0 means unbounded (no limit configured yet).
manage-limits scopeOnly the wallet owner's own token can change their own limit — there is no way for a client to set a limit on behalf of a different user.
curl -X PUT https://oidc.biatec.io/wallet/limits \
-H "Authorization: Bearer <access_token>" \
-H "Content-Type: application/json" \
-d '{ "maxAmountPerTransaction": 5000000 }'
Applies immediately to every subsequent /wallet/sign call, from any application the owner has authorized — the limit is per wallet owner, not per relying-party app.
Biatec OIDC is a whitelisted-client provider — every relying party is registered up front with its redirect URIs and allowed scopes.
| What you provide | Notes |
|---|---|
| Client type | Confidential (server-side, with a client secret) or public (mobile/desktop/SPA, PKCE required) |
| Redirect URIs | Exact or *-wildcard-subdomain allowlist for the authorization code flow |
| Post-logout redirect URIs | Where RP-Initiated Logout sends the browser back to; falls back to your redirect URIs if omitted |
| Allowed scopes | openid profile email by default — request sign and/or manage-limits explicitly if your integration needs the wallet API |
Contact Biatec to register a new client and get a client_id/client_secret issued.