# Buildkite-agent oidc request-token --lifetime maximum too short

**URL:** <https://forum.buildkite.community/t/buildkite-agent-oidc-request-token-lifetime-maximum-too-short/4618>\
**Category:** Features Requests\
**Created:** [August 12, 2026, 1:52am UTC](https://forum.buildkite.community/t/buildkite-agent-oidc-request-token-lifetime-maximum-too-short/4618 "2026-08-12T01:52:02Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![chris-at-metacosm](https://avatars.discourse-cdn.com/v4/letter/c/ecccb3/32.png) [@chris-at-metacosm](https://forum.buildkite.community/u/chris-at-metacosm)\
**Post date:** [August 12, 2026, 1:52am UTC](https://forum.buildkite.community/t/buildkite-agent-oidc-request-token-lifetime-maximum-too-short/4618/1 "2026-08-12T01:52:02Z")

</div>

From this page [OIDC in Buildkite Package Registries | Buildkite Documentation](https://buildkite.com/docs/package-registries/security/oidc#configure-a-buildkite-pipeline-to-authenticate-to-a-registry-part-1-request-an-oidc-token-from-buildkite) token max lifetime is 300 seconds.

For a token that is going to be used to upload large files (including docker images) to a package registry this is too short in a lot of scenarios.

A 300 second OIDC token is on the very short end of the reasonable expectation of best practice for OIDC tokens - and in this particular scenario is often technically unworkable.

Ironically this is likely to hit users when they are first experimenting with packages and there is no existing layers uploaded - potentially blocking adoption of this pretty cool feature entirely.

**Suggestion** - set 300 as a default (seems like it already is from experimentation) and allow a max lifetime of up to 1800 seconds (or higher) and clearly document the security trade off to allow teams to make their own decision on this. For a well scoped token this is a pretty well mitigated risk.

Cheers

---

<div class="post-metadata">

**Author:** ![lizette](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.buildkite.community/lizette/32/1161_2.png) [@lizette](https://forum.buildkite.community/u/lizette)\
**Post date:** [August 12, 2026, 2:32am UTC](https://forum.buildkite.community/t/buildkite-agent-oidc-request-token-lifetime-maximum-too-short/4618/2 "2026-08-12T02:32:57Z")

</div>

Hi @chris-at-metacosm , welcome to our Buildkite Support Community! 👋

Thanks for raising this to our attention. This limit of 300 seconds only applies to our Package Registries product. Our pipelines can manage a longer lifetime as you can see in our platform / organization limits - [Limits | Buildkite Documentation](https://buildkite.com/docs/platform/limits#viewing-your-organizations-service-quotas) . The recommended approach at the moment if your upload or publish process is running longer than 5 minutes, is to request the OIDC token immediately before authenticating/publishing to the registry, rather than generating it earlier in the job and reusing it later. Is the 5-minute limit blocking a specific use-case for you? Or are you alright with the suggested workaround?

Cheers!

---

<div class="post-metadata">

**Author:** ![chris-at-metacosm](https://avatars.discourse-cdn.com/v4/letter/c/ecccb3/32.png) [@chris-at-metacosm](https://forum.buildkite.community/u/chris-at-metacosm)\
**Post date:** [August 12, 2026, 2:52am UTC](https://forum.buildkite.community/t/buildkite-agent-oidc-request-token-lifetime-maximum-too-short/4618/3 "2026-08-12T02:52:50Z")

</div>

I’m aware that the limit is only on package registries - that’s actually the root of the problem. Uploading large files is one of the things during a CI/CD process that can reliably potentially exceed 5 minutes and is also usually very hard to re-authenticate mid upload. This problem bites mainly BECAUSE it is a limit that applies to package registries, not an issue that is mitigated because it only applies here. The five minute limit is a hard blocker here. There is no workaround (your proposal is just basic best practice). 300 seconds is also a very non-standard limit here in general - there’s very little reason for a time this tight - I’d suspect that somewhere along the way during product design a default got changed to a maximum.

---

<div class="post-metadata">

**Author:** ![lizette](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.buildkite.community/lizette/32/1161_2.png) [@lizette](https://forum.buildkite.community/u/lizette)\
**Post date:** [August 12, 2026, 3:14am UTC](https://forum.buildkite.community/t/buildkite-agent-oidc-request-token-lifetime-maximum-too-short/4618/4 "2026-08-12T03:14:47Z")

</div>

I see. Thanks for sharing your thoughts and for letting us know that this is a blocker for you. I’ll raise this as a feedback to our product team to assess if this limit can be lifted.

Cheers!

---

<div class="post-metadata">

**Author:** ![chris-at-metacosm](https://avatars.discourse-cdn.com/v4/letter/c/ecccb3/32.png) [@chris-at-metacosm](https://forum.buildkite.community/u/chris-at-metacosm)\
**Post date:** [August 12, 2026, 3:18am UTC](https://forum.buildkite.community/t/buildkite-agent-oidc-request-token-lifetime-maximum-too-short/4618/5 "2026-08-12T03:18:24Z")

</div>

The tone in that message came out harsher than intended on re-read. Thanks for raising the ticket - I’m moving our packages to ECR in the meantime as this can’t be worked around. I would like to see the buildkite platform continue to succeed though so the feature request still stands.

---

<div class="post-metadata">

**Author:** ![lizette](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.buildkite.community/lizette/32/1161_2.png) [@lizette](https://forum.buildkite.community/u/lizette)\
**Post date:** [August 12, 2026, 3:31am UTC](https://forum.buildkite.community/t/buildkite-agent-oidc-request-token-lifetime-maximum-too-short/4618/6 "2026-08-12T03:31:20Z")

</div>

No worries! I’ve raised this already to our product team as a feature request. Thanks for the kind words on Buildkite! 💚
