tai42-identity-oidc lets machines authenticate with a JWT your identity
provider already issues, rather than with an API key the runtime minted. It is a
user type source for
access control: it verifies a presented token and
resolves it to a user id, and the policy attached to that id decides what the
call may reach.
This provider verifies tokens; it never issues them. There is no
authorization-code flow, no client id or secret, and no key-minting surface here.
Your issuer mints tokens; the runtime checks them. For human sign-in, see
Accounts.
Install and register it
manifest.yml
identity-oidc, which is the value
ACCESS_CONTROL_AUTH_PROVIDERS selects. Listing redis alongside it keeps
minted API keys working next to issuer-signed JWTs.
Configure the issuer
The issuer must publish standard discovery metadata and a JWKS endpoint. Startup
fetches both, so a misconfigured issuer fails at boot rather than on the first
call.
Write the policy
A verified token resolves to the user ididp:{issuer}:{claim value}. Nothing is
provisioned automatically: until a policy exists for that exact id, every
protected route denies the call.
owner_user_id
claim is stripped from the claims the runtime keeps, so it cannot be used to
escalate.
See also
- Access control — the policy model this feeds.
- User types and permissions — how each identity type is judged.
- Accounts — human sign-in, sessions, and invites.
- Author an identity provider — write your own.

