The addition of portals makes the use of the GraphQL inside jobs easier (e.g. to get the GitHub Webhook Payload to extract the before and after commit hashes, or to get the most recent main build job to get baseline artifacts).
It seems this is still tied to access tokens. I would appreciate it if a Job could authenticate without the need to store an access token somewhere.
Either by submitting the token that is also used for OIDC purposes or by adding a proxy command to the buildkite-agent.
Hey @Valkum 
Glad to hear you’re liking the addition of Portals, and thank you for sharing your feedback! I wonder if Ephemeral Tokens may be a little closer to what you’re after? This way you could store the secret used to acquire a token in your secrets management tool of choice, and use OIDC to authenticate and acquire secrets in the job more securely.
It feels a bit unconnected to be required to store something from System A in a secret management tool (System B, either pipeline secret or AWS or GCP) to be able to access something in System A.
I mean, the OIDC token exchange flow to assume roles or impersonate service accounts seems like the one hyperscalers recommend to authenticate with and other parts of the buildkite system already let jobs authenticate (annotations etc).
Certain parts of the API (annotation endpoint etc.) seem to allow authenticating using the agent access token (which is scoped to a job IIUC), adding an allowed list of pipelines to the portal seems like a useful addition?
Also, security-wise unless a second system is exchanging the Portal secret with an ephemeral token, the ephemeral token doesn’t add much security wise, as the pipeline that wants to use the ephemeral token needs access to the secret. You could allow access to the Portal secret to just a single step by matching on the step in the OIDC subject, but we clearly leave easy-to-use-land at this point.
That’s totally fair - I only offered up ephemeral tokens as a suggestion for already existing solutions for authentication to Portals in a way that isn’t using the admin token created with a portal, but I agree it would be great (and preferable in lots of cases) if that was an option as well. These are all excellent points and I’ll share this with our product folks for consideration. Thanks!