Subjects
People and service accounts of the customer IdP, and the trust Xokepoint has in that IdP.
The subject is who answers for the call. It exists in the customer identity provider (Keycloak, Okta, Entra, Google Workspace), and Xokepoint neither creates nor stores subject credentials. What Xokepoint stores is the trust in the IdP.
There are two kinds of subject: user, a person in the directory, and service_account, a customer service with its own credential, such as a job that reconciles invoices every night. For authorization the two are the same. A service account receives delegations and permissions the same way a person does.
What identifies a subject
The issuer and subject pair: the iss and sub of the token, as defined by OpenID Connect. An e-mail does not work, because it changes and can be reused. A client_id does not work either, because it identifies the application that requested the token, not who acts.
Identity connection
The trust in an IdP is recorded in an identity connection: the issuer, the public keys and the accepted audiences. The subject token is accepted only if it passes through it.
The connection is checked again on every call, not only when the token is issued. Disabling a connection cuts off every subject of that IdP on the next call.
To pick subjects while configuring permissions, the Admin reads the directory through each provider's native API. Before a subject enters a delegation, the provider confirms that it exists.