Display OIDC as configurable field in UI and audit logs

We would like Spacelift to support a configurable display field for OIDC-authenticated API activity, so that administrators can choose which OIDC claim is used to represent the actor in the UI and audit logs.

At the moment, actions performed via an OIDC API key appear as the key itself. While this technically identifies the credential used, it does not always identify who or what initiated the request. For audit logging, fields such as sub, or potentially another configured claim, may provide a much more useful and traceable identity.

The requested behaviour is:

  • Allow administrators to configure which OIDC claim should be used as the display value for actions performed through an OIDC API key.

  • Show that configured value in relevant UI activity views and audit logs.

  • Preserve the existing API key identity as supporting metadata, so it is still clear which credential was used.

  • Avoid requiring full token storage, but retain enough selected claim information to support later audit and investigation.

  • Ideally support a fallback behaviour, such as showing the API key name when the configured claim is missing.

This would make OIDC-based automation more transparent and easier to govern. It would also help organisations trace changes back to the original requester without needing access to transient token contents that are not stored today.

Workaround
-
Problem
When an OIDC API key performs actions in Spacelift, those actions are displayed and recorded as being performed by the key itself. This makes audit trails hard to interpret because the visible actor is the integration credential, rather than the real requester or upstream identity behind the token. In many environments, the OIDC token contains more useful identity fields, such as sub or oid, which may better represent the originating user, workload, pipeline, service account, or request context. Since Spacelift audit logs do not currently store the full token details, there is no reliable way to trace actions back to the actual requester after the fact. This creates gaps in accountability, incident investigation, and compliance reporting.

Please authenticate to join the conversation.

Upvoters
Status

πŸ‘€ In Review

Board

πŸ’‘ Feature Requests

Date

1 day ago

Subscribe to post

Get notified by email when there are changes.