OpenFGA 1.22

Apply these rules to applications that use the OpenFGA server and to the service's configuration and policy deployment.

Identity and tenant boundary

• Authenticate the caller in the application before constructing an OpenFGA request. Derive the user, tenant, store_id, and protected object from trusted identity and resource records; do not accept a caller's tuple strings or store ID as authority.
• Map external identities to stable, opaque OpenFGA user IDs; validate the identity provider and namespace before a subject from another tenant or issuer can match a tuple.
• Resolve object IDs from application records in the caller's tenant before checking or writing a relationship. A correctly formed type:id string does not prove that the entity exists or belongs to that tenant.
• Keep each tenant in an intended store or encode and test tenant boundaries in the model and object IDs. Reject cross-tenant parent, group, and userset relationships during tuple writes.
• Restrict CreateStore, DeleteStore, WriteAuthorizationModel, and assertion changes to a separate control plane; they change the meaning or availability of authorization for every caller of a store.

Authorization decisions

• Call Check for the concrete user, relation, and object at the protected operation. Treat an error, timeout, missing result, or unavailable server as no allow; a successful Read or Expand result is not an authorization decision.
• Place the decision at every data and action entry point, including background jobs and non-HTTP handlers; filtering a list or hiding a UI