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.
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.
It simply works as follows:
Obtain an OAuth2 client credential Credential (read more here) as follows:
Now you can use the client credentials, for example, within your application to authenticate to the Cluster's OAuth2 token endpoint located at the URL https://<DOMAIN>/oauth2/token. For example, let's assume we want to access the Service my-api and obtain the 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>).
Using shell and curl, this can be simply done as follows:
Here is an equivalent example in Golang:
And here is an equivalent example in Typescript:
You can optionally use Octelium scopes as OAuth2 scopes. Read more about scopes here.
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:
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. Here is an example in Golang but you can apply the same flow in any language: