Add the concept of "Service Accounts" that are used by other systems, tools or scripts to authenticate with the auth daemon. Upon succesfull authentication, the auth daemon would issue a typical JWT token. Downstream services that validate the JWT token with have little to no variation in how they process requests for a Service account or a User account.
Service accounts are similar to users account:
They are assigned to a tenant
They have roles and permissions
They have a valid email address (for JWT consistency reason), but may not be expected to be active. ie. It isn't expected to receive or process email.
They can authenticate through the login endpoint
The main difference with the user account is the that they don't have a password instead they can be authenticated by one of the following methods:
They can be authenticated by whitelisted IP address
They can have a never expiring JWT token which acts as an API key
Machine account can be managed by a regular user who has the permissions to do so.
Add the concept of "Service Accounts" that are used by other systems, tools or scripts to authenticate with the auth daemon. Upon succesfull authentication, the auth daemon would issue a typical JWT token. Downstream services that validate the JWT token with have little to no variation in how they process requests for a Service account or a User account.
Service accounts are similar to users account:
The main difference with the user account is the that they don't have a password instead they can be authenticated by one of the following methods:
Machine account can be managed by a regular user who has the permissions to do so.