Summary

Add new InternalData fields to Aliases to support internal-only metadata that is not returned to the client but is persisted across all subsequent requests.

Problem Statement

After merging an enhancement to the OIDC auth method to expose id, request, and access tokens in metadata, we thought more about the implications of exposing OIDC tokens in the client response. At the core, this is an issue of cross-plugin communication: the core use case was motivated by a third-party plugin accepting OIDC refresh_tokens, thus reducing the number of client logins to one, from two, to access external resource servers with OIDC information securely stored within OpenBao.

In particular, an ideal flow would either have a single OIDC auth take place within the context of a single plugin (say, if the Puppet plugin were to also become an auth plugin and support authenticating to OpenBao with the same OIDC token acquisition flow). Or, if not in the same plugin (to keep logical concerns separate), that cross-plugin communication of some sort would allow the OIDC auth method to indicate to an OIDC consumption plugin the underlying refresh tokens (since the auth method itself has no use for them).

Here, we propose InternalData as a field on Aliases; unlike the equivalent on the Auth field (which is returned to the auth plugin on subsequent renew or revoke operations), this field is given to other plugins for their internal use.

This allows an auth plugin which explicitly wishes to indicate any values to another plugin to do so, and that external plugin to consume it if desired.

User-facing description

This does not substantially modify user behavior. The existing flow has not yet been shipped in a release.

Instead, the intent with this is to simplify caller's workflows when using like plugins (auth & secret) which may use similar data. For instance, a cert auth plugin could indicate the underlying channel binding keys, which must remain secure. Or, the OIDC auth plugin could expose plugins to an OIDC client plugin (as mentioned above).

However, few uses of this are known to the authors of this RFC outside of the OIDC case, likely because such secure mechanism has not yet been created.

Technical Description

This change is mostly for plugin authors. No change is expected for auditing, as these values are not expected to be returned through the audit interface.

This field only occurs in the Alias information set by the authenticating plugin. This is a new field, InternalData, which needs to be stubbed throughout the GRPC & storage structures. This will be a string->string map like the existing field on Auth.

We will need to remove this field's value before returning it to the caller, just like auth.InternalData is removed.

Rationale and alternatives

This change allows us to improve the security the OIDC metadata change, restricting access to these tokens only from within OpenBao. This allows OpenBao to be considered the OIDC client, with the happenstance that the downstream OpenBao client can also authenticate itself to OpenBao at the same time.

One alternative unlikely to occur is true, server-side cross-plugin communication which does not involve paths that the client can also call. This would likely require either internal-only APIs (to be ACL'd by the system) or some other mechanism.

Downsides

One downside is that this adds complexity in yet-another-field that needs to be carefully considered in future designs. This also deviates from upstream, in that plugins will have to compile with OpenBao SDKs to take advantage of these new fields, if they are not also added upstream.

Security Implications

We cannot enforce that third-party plugins do not leak these values to the user in some other way (whether by side-channel or in their own response body). This is out of scope and we assume all plugins within the system are trusted.

User/Developer Experience

No user experience change is expected here.

Plugin authors (both auth and secrets) will have a new tool for one way cross-plugin communication that avoids bigger ACL-related questions. This will allow plugin authors to logically separate auth and secret plugins, while retaining some ability to communicate information from an authentication to later secret plugin invocations.

Unresolved Questions

n/a

Related Issues

• Add oauth2_metadata config option #320

Proof of Concept

n/a

cc @DanGhita / @DrDaveD