Octelium
NEW

Introducing Cordium — Identity-based Sandboxes for Developers & AI Agents

Octelium documentation · Latest

OAuth2 Client Credentials Flow for Workloads

WORKLOAD Users (read more about User management here) can use the standard OAuth2 client credentials authentication flow (read more here) to authenticate themselves to the Cluster and start accessing its publicly exposed HTTP-based Services (read more about publicly exposed BeyondCorp Services here), such as HTTP/gRPC-based APIs or Kubernetes clusters, exactly like any protected public SaaS HTTP-based resource without having to install clients on their hosts, use special SDKs or even having to be aware of the Cluster's existence at all. This allows you to write applications in any programming language and use standard OAuth2 libraries to securely access all the Cluster's publicly exposed Services via a single identity and credential.

note

In addition to using OAuth2 client credentials flow Credentials, you can also generate an access token Credential and use it directly as a bearer token to access publicly exposed Services. Read more here.

First, obtain an OAuth2 client credentials Credential for your WORKLOAD User (read more here) as follows:

octeliumctl create cred --user microservice1 --type oauth2 my-oauth-cred # Here is the command output Client ID: nz7y-hagw Client Secret: AQpA691Z...

Now you can use the client credentials within your application to authenticate to the Cluster's OAuth2 token endpoint located at the URL https://<DOMAIN>/oauth2/token. The client ID and client secret are sent in the form-encoded request body (i.e. the client_secret_post authentication method). The token endpoint returns a bearer access token that can then be used to access your Services via the standard bearer authentication (i.e. via the HTTP request header Authorization: Bearer <ACCESS_TOKEN>).

In the following examples, we access the Service my-api. The examples read the Cluster domain and the client credentials from the OCTELIUM_DOMAIN, OCTELIUM_CLIENT_ID and OCTELIUM_CLIENT_SECRET environment variables:

Using shell and curl, this can be simply done as follows:

curl -X POST \ -d grant_type=client_credentials \ -d client_id=$OCTELIUM_CLIENT_ID \ -d client_secret=$OCTELIUM_CLIENT_SECRET \ https://$OCTELIUM_DOMAIN/oauth2/token # Now we use the obtained access token from the above request to access the Service curl -H "Authorization: Bearer <ACCESS_TOKEN>" https://my-api.$OCTELIUM_DOMAIN
note

You can optionally use Octelium scopes as OAuth2 scopes. Read more about scopes here.

The access token expires according to the Session limits set by the Cluster (read more here) or at the User level (read more here), and the token endpoint returns its lifetime in the expires_in field. It is the responsibility of the application to re-authenticate via the token endpoint to obtain a new access token before it expires. The Golang and Python examples above already do that automatically.

There are standard libraries in almost all the major programming languages to use the OAuth2 client credentials flow and obtain the access token. Some examples are:

note

You can also use the issued access token in the X-Octelium-Auth: <ACCESS_TOKEN> header instead of using it in the typical Authorization: Bearer <ACCESS_TOKEN> header.

Workload Identity Federation

You can also use OpenID Connect JWT-based assertions in OAuth2 client credentials authentication, as defined in RFC 7523 to avoid having to issue OAuth2 client credential Credentials. This allows WORKLOAD Users to authenticate themselves using OIDC identity tokens issued by the identity provider hosting the workload ( e.g. Azure, GitHub Actions, Kubernetes clusters, SPIFFE, etc...) and automatically access the Cluster's HTTP-based resources in a "secretless" way that does not require issuing and distributing OAuth2 client credential Credentials as shown above. The assertion must be trusted by an OIDC assertion IdentityProvider (read more here).

Instead of the client ID and client secret, the application sends the JWT in the client_assertion parameter along with the client_assertion_type parameter set to urn:ietf:params:oauth:client-assertion-type:jwt-bearer. The following examples read the JWT from the OCTELIUM_ASSERTION environment variable:

curl -X POST \ -d grant_type=client_credentials \ -d client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer \ -d client_assertion=$OCTELIUM_ASSERTION \ https://$OCTELIUM_DOMAIN/oauth2/token # Now we use the obtained access token from the above request to access the Service curl -H "Authorization: Bearer <ACCESS_TOKEN>" https://my-api.$OCTELIUM_DOMAIN
note

OIDC identity tokens are usually short-lived. Make sure that your application obtains a fresh assertion from the identity provider hosting the workload whenever it re-authenticates to the token endpoint. The Golang SDK can also authenticate via assertions read from a file on every re-authentication and automatically keep the Session fresh (read more here).