In FOLIO user accounts are optional to issue API calls, instead FOLIO relies on signed tokens for authentication. User accounts are, however, required to request a signed token in the first place.
In FOLIO authentication is based on passing signed tokens between parties (browser, modules, Okapi). Authorisation is based directly on permissions encoded in the signed token or, indirectly, based on permissions assigned to the user account the token points to, both of which are optional.
The only way to request a signed token is to authenticate against a login endpoint. After the token has been issued the client may use it to initiate requests with secured FOLIO endpoints.
This approach may be problematic when modules would like to call FOLIO APIs without a context of an authenticated client request. Use cases:
- module makes a request on their own e.g periodically to perform a system task (cron-like behavior)
- module makes a request during the "init" phase (e.g moduleA needs to bootsrap data in moduleB)
- module makes a request to another module in response to an unauthenticated request (request made to the unauthentifcated endpoint, example: calls to /login)
When a module is enabled for a tenant, Okapi issues an "init" call (Tenant API) to the module. Assuming the Okapi installation has been properly secured (this is a requirement for a secured system) the "init" call issued from Okapi originates from a privileged security context (which is required for enabling modules). This privileged context may be downgraded to a less privileged context specific to the module being enabled. This is done by encoding module's permissions (defined in the modulePermission entry for init) in the token passed to the module. The token passed during init can be then peristed by the module to subsequently trigger system tasks (that are allowed within the init's modulePermissions) or the module may request "init" permissions to "create users and grant them permissions" and automatically install a "system" user it needs.