We use Authentication extensively within any sort of distributed system. This primarily breaks down into two parts:
Authentication (AuthN) -- who are you?
Authorization (AuthZ) -- what are you allowed to do?
There have been various approaches for authN over the years, with identity tied to an account. This holds for system component and get termed Service Accounts:
username and password
certificates
...
Then there came JWTs. These are a format for packaging a set of claims that are signed by an issuing authority. This allows a system presented with such a token to verify the integrity of the claims assuming it has the public certificate of the issuer without any additional interaction such as a database lookup. This allows for issuance of very large numbers of tokens and for very short expiration dates as there's no system load beyond the issuance.
There are several styles of token, the main variants being:
Bearer token - this is pure authZ without authN -- mere possession of the token allows the holder to act per its claims
Proof of Possession, aka Holder of Key (HOK) - this model requires the entity offering up the token to also demonstrate that they hold an associated key
In summary:
tokens - used for authorization
private certificates - used for authentication
Before components in a distributed system can authenticate with one another, a trust exchange must have occurred. This is generally a mediated exchange of public certificates (or distributon of a common signing certificate) that allow Proof-of-Possession. This is often a manual or complex step (eg. FDO).
If we could use authZ only, it would be much easier to bring up a distributed system, unfortunately bearer tokens have their own infrastructure and setup requirements, needing both an issuer and for that issuer to be trusted by any recipients. They also have risks around theft of tokens.
However, if your distributed system is not random clients and servers talking a protocol, but rather a collection of components all authored by the same entity (or group) then an interesting possibility is presented by combining attestation with entitlement.
Attestation is a little different from authentication. Where authN is a challenge of "tell me who you are", attestation is a question to a trusted 3rd party asking "what is their nature?".
With this, instead of trying to authenticate the remote, we can say "it doesn't matter who you are because I know what you are".
We can leverage commonality of authorship to assume that any statement of entitlement bound to a component is legitimate so long as the component has been attested. In this case we're not saying "who are you" and determining what that entity is authorized to do; we're instead saying, "prove you've not been tampered with" and then trusting that the component will only ask for necessary privileges.
This can be accomplished through:
creating a manifest that is signed by the common author which includes:
attestation data for the component
acceptable attestation stacks
necessary entitlements
packaging the public certificate for the common author into the components to allow validation of the manifest
All of the heavy lifting is being done by the attestation in this scenario, which is provided by the compute hardware in the form of a TPM, a SecureBoot chain, and a hardware enclave of some type such as SEV or TDX. The distribution of root keys into TPMs is already performed by manufacturers and we can leverage this to allow immediate unmediated trust between remote components.
If we're a company authoring software components, we're unlikely to want every install of our components to trust all others as customers require tenancy.
This can be accomplished by chaining additional signers into the manifests:
author download portal could generate a per-customer package that will only accept entitlements that are signed by both author and for that specific customer.
the manifest could be structured such that a customer can add their own signature and components could require remote components to also have all signers before entitlements are accepted
The acceptance of entitlement is fundamentally a programmatic validation in the local component, so there is a lot of flexibility in terms of whether a component should accept a remote entitlement or not.