Clutch has modular support for authentication (i.e.
authn) and authorization (i.e.
authz). This will allow you to adapt these primitives to your environment without completely rewriting the core logic.
Currently Clutch supports Open ID Connect (OIDC) for authentication and ships with an RBAC engine for authorization.
The authentication components work together to create a valid session for a user from a third-party authentication provider.
The session information is stored in a JSON Web Token (JWT) for use by the authorization components, auditing components, etc.
|Handles token exchange with the authentication provider to verify the users identity and signs Clutch's own JWT.|
|Provides the |
|Validates the JWT on incoming requests and inserts authentication information such as the user ID into the request context.|
In order to use Clutch's native authentication, registration of all three
authn components is required in the gateway configuration.
Clutch currently supports OIDC, for example with Okta. It is possible to support other authentication providers by extending or swapping out the authn service.
Furthermore, Clutch has support for a
groups field in the claims. By default, no groups are appended to the claim. The authn service's
Provider interface has a
WithClaimsFromOIDCTokenFunc function that can be used to override claims derivation from the provider. At Lyft, we use this to call an internal service that provides the group IDs for a user.
The authorization components work together to provide an RBAC engine for Clutch.
|Evaluates policies to determine whether to allow or deny an action.|
|Calls the authz service on each request to determine whether to allow or deny an action.|
|Provides an endpoint for testing an action to see in advance whether it will be allowed or denied. Not currently required.|
The built-in authz service, which provides a simple RBAC engine, can be swapped out with any other type of authorization framework.