enhance(actions): add OIDC workload identity support by 0xMax42 · Pull Request #39052 · go-gitea/gitea

0xMax42 · 2026-08-22T15:59:28Z

Add OpenID Connect workload identity support for Gitea Actions.

Workflows can explicitly request id-token: write and obtain short-lived OIDC tokens representing their repository and workflow provenance. This enables external services to authenticate Actions workloads without requiring long-lived credentials stored as secrets.

This continues and substantially revises the work from #36988, particularly around effective permissions, reusable workflows, authoritative provenance and token issuance security.

UI

Before:

After:

Documentation

https://gitea.com/gitea/docs/pulls/526

Assisted-by: ChatGPT:gpt-5.6-sol

0xMax42 · 2026-08-22T16:22:29Z

Manual validation note

In addition to the automated test suite, which is currently passing, I have
manually tested the current implementation on a Gitea instance.

The following scenarios were verified:

regular workflow with id-token: write → OIDC runtime context is available
and a token can be minted successfully
regular workflow with id-token: none → OIDC runtime context is absent
regular workflow with id-token: read → OIDC runtime context is absent
repository-level maximum permission disabling OIDC → runtime context is
absent even when the workflow requests id-token: write
re-enabling OIDC at repository level → token issuance works again
cross-repository reusable workflow with id-token: write → token issuance
succeeds and root/reusable workflow provenance is reported separately and
correctly
reusable workflow where the caller has id-token: none while the called
workflow requests id-token: write → OIDC runtime context is absent, i.e.
the called workflow cannot elevate the caller's permission

The positive end-to-end test also verified the issued token using only the
public OIDC discovery document and JWKS, including signature, issuer, audience,
lifetime, repository/ref/SHA claims, and workflow provenance.

This is mainly a note for tracking the current Draft validation state; I still
intend to perform my own complete code/security review before marking the PR
ready for review.

silverwind · 2026-08-22T17:00:02Z

Make sure your agent has read AGENTS.md and followed it exactly. Based on this long PR description, I see that it didn't read it. Please re-review the whole work under the AGENTS.md constraints.

0xMax42 · 2026-08-22T17:10:33Z

Make sure your agent has read AGENTS.md and followed it exactly. Based on this long PR description, I see that it didn't read it. Please re-review the whole work under the AGENTS.md constraints.

Sorry! I’ve now amended the pull request description in line with the guidelines in AGENTS.md, and I’ve added the screenshots I’d already prepared.

I’ll check the entire change once more against the guidelines in AGENTS.md before removing the pull request from draft status.

silverwind · 2026-08-22T17:15:21Z

Thanks, yes that's a more managable size now :)

0xMax42 · 2026-08-22T18:10:18Z

+	if err := task.Job.LoadRun(ctx); err != nil {
+		return false, err
+	}
+	if task.Job.Run.WorkflowPath == "" {
+		return false, nil
+	}


For migrated schedules, WorkflowPath can legitimately be empty. In that case OIDC is intentionally kept unavailable rather than issuing a token with incomplete workflow provenance.

Would it make sense to log this condition when preparing the runner context? Otherwise, after upgrading, an administrator could see id-token: write but no OIDC runtime variables without an obvious indication why.

0xMax42 · 2026-08-22T19:18:31Z

 func TokenToTaskID(token string) (int64, error) {
 	parsedToken, err := jwt.ParseWithClaims(token, &actionsClaims{}, func(t *jwt.Token) (any, error) {
-		if _, ok := t.Method.(*jwt.SigningMethodHMAC); !ok {
+		if t.Method != jwt.SigningMethodHS256 {


This narrows Actions token verification to HS256, matching the algorithm Gitea actually uses to issue these tokens. It is defense-in-depth for the OIDC bearer credential path, so I’m happy to drop it if you’d prefer to keep this PR narrower.

0xMax42 · 2026-08-22T19:18:52Z

+
+func TestTokenToTaskIDRejectsOtherHMACAlgorithms(t *testing.T) {
+	token := jwt.NewWithClaims(jwt.SigningMethodHS384, actionsClaims{TaskID: 23})
+	signed, err := token.SignedString(setting.GetGeneralTokenSigningSecret())
+	assert.NoError(t, err)
+	_, err = TokenToTaskID(signed)
+	assert.Error(t, err)
+}


This test only documents the HS256 restriction above by verifying that an otherwise valid HS384 token is rejected. It can be removed together with that hardening if it is considered out of scope.

0xMax42 · 2026-08-22T20:44:06Z

+		if parentPerms := parentJob.TokenPermissions; parentPerms != nil {
+			effectivePerms = repo_model.ClampActionsTokenPermissions(effectivePerms, *parentPerms)
+		} else if parentJob.ParentJobID == 0 {
+			if repoActionsCfg.OverrideOwnerConfig {
+				effectivePerms = repo_model.ClampActionsTokenPermissions(effectivePerms, repoActionsCfg.GetDefaultTokenPermissions())
+			} else {
+				effectivePerms = repo_model.ClampActionsTokenPermissions(effectivePerms, ownerActionsCfg.GetDefaultTokenPermissions())
+			}
+		}


This intentionally clamps the full ActionsTokenPermissions, not only IDTokenAccessMode. The reusable caller chain is part of the canonical effective-permission calculation, so a called workflow cannot exceed its caller for either GITEA_TOKEN or OIDC. Happy to split or narrow this if you'd prefer to keep the PR strictly OIDC-scoped.

0xMax42 · 2026-08-22T21:23:42Z

While reviewing/testing this, I noticed an unrelated existing issue in the OAuth2 JWT signing-key setup: auto-generated ECDSA keys always use P-256, even when ES384 or ES512 is configured. This appears to make those algorithms fail when using an automatically generated key.

I don't think this belongs in this PR. Would you prefer a separate issue for it? I can open one later and look at it independently.

0xMax42 · 2026-08-22T21:30:40Z

I've now completed my own review of the implementation and tests. The remaining piece is documentation, which I'll add separately.

In the meantime, feel free to take a look already — feedback and comments are very welcome.

0xMax42 · 2026-08-22T21:43:18Z

Also verified that the Gitea Actions runner masks ACTIONS_ID_TOKEN_REQUEST_TOKEN in job logs as expected, including when environment variables are printed directly.

Derive token permissions and identity claims from canonical server state, persist authoritative workflow paths, and cover capability access and signing behavior. Assisted-by: OpenCode:gpt-5.6-sol

Legacy schedules can create runs without an authoritative workflow path. Keep OIDC unavailable for these runs, as before OIDC support was introduced, until the schedule is rebuilt. Assisted-by: OpenCode:gpt-5.6-sol

Fail OIDC token issuance when reusable workflow provenance cannot be resolved or does not include the resolved workflow commit. Assisted-by: OpenCode:gpt-5.6-sol

Treat the unsupported id-token read mode as none while preserving write-all and explicit id-token write behavior. Assisted-by: OpenCode:gpt-5.6-sol

Avoid evaluating OIDC eligibility while the provider is unavailable so disabled OIDC cannot interfere with normal task context generation. Assisted-by: OpenCode:gpt-5.6-sol

Cover workflow path persistence for scheduled runs and scoped workflow dispatches. Assisted-by: OpenCode:gpt-5.6-terra

Verify that cyclic reusable workflow parent chains are rejected while computing effective token permissions. Assisted-by: OpenCode:gpt-5.6-terra

Avoid resolving OIDC provenance and effective permissions for jobs that did not explicitly request id-token write access. Assisted-by: OpenCode:gpt-5.6-luna

Verify that reusable workflow callers restrict both repository unit permissions and OIDC token permissions. Assisted-by: OpenCode:gpt-5.6-luna

Keep invalid authorization and task state failures as 401 responses while surfacing unexpected task lookup failures as logged internal server errors. Assisted-by: OpenCode:gpt-5.6-luna

Reject token issuance when the root workflow source commit or reference is missing, and cover root, reusable, scoped, and signing-key provenance cases. Assisted-by: OpenCode:gpt-5.6-terra

Verify the discovery-to-JWKS chain and require the expected bearer challenge for rejected OIDC token requests. Assisted-by: OpenCode:gpt-5.6-luna

GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Aug 22, 2026

0xMax42 changed the title ~~feat(actions): add OIDC workload identity support~~ enhance(actions): add OIDC workload identity support Aug 22, 2026

0xMax42 commented Aug 22, 2026

View reviewed changes

silverwind added the topic/gitea-actions related to the actions of Gitea label Aug 22, 2026

0xMax42 commented Aug 22, 2026

View reviewed changes

0xMax42 force-pushed the feat/actions-oidc branch from 47a494c to de5952f Compare August 23, 2026 17:52

0xMax42 marked this pull request as ready for review August 23, 2026 17:56

github-actions Bot added the type/enhancement An improvement of existing functionality label Aug 23, 2026

lunny and others added 13 commits August 23, 2026 21:54

Add OIDC support for actions

b67ec2d

fix(actions): harden OIDC workload identity

f369ce5

Derive token permissions and identity claims from canonical server state, persist authoritative workflow paths, and cover capability access and signing behavior. Assisted-by: OpenCode:gpt-5.6-sol

fix(actions): require workflow path for OIDC

e579baf

Legacy schedules can create runs without an authoritative workflow path. Keep OIDC unavailable for these runs, as before OIDC support was introduced, until the schedule is rebuilt. Assisted-by: OpenCode:gpt-5.6-sol

fix(actions): require complete reusable OIDC provenance

dd39306

Fail OIDC token issuance when reusable workflow provenance cannot be resolved or does not include the resolved workflow commit. Assisted-by: OpenCode:gpt-5.6-sol

fix(actions): normalize id-token read permission

339a8b0

Treat the unsupported id-token read mode as none while preserving write-all and explicit id-token write behavior. Assisted-by: OpenCode:gpt-5.6-sol

fix(actions): skip OIDC authorization when disabled

ca3beed

Avoid evaluating OIDC eligibility while the provider is unavailable so disabled OIDC cannot interfere with normal task context generation. Assisted-by: OpenCode:gpt-5.6-sol

test(actions): cover workflow path propagation

348f122

Cover workflow path persistence for scheduled runs and scoped workflow dispatches. Assisted-by: OpenCode:gpt-5.6-terra

test(actions): cover reusable workflow parent cycles

815e82e

Verify that cyclic reusable workflow parent chains are rejected while computing effective token permissions. Assisted-by: OpenCode:gpt-5.6-terra

perf(actions): skip unnecessary OIDC authorization

1ac168e

Avoid resolving OIDC provenance and effective permissions for jobs that did not explicitly request id-token write access. Assisted-by: OpenCode:gpt-5.6-luna

test(actions): cover reusable permission clamping

cd74584

Verify that reusable workflow callers restrict both repository unit permissions and OIDC token permissions. Assisted-by: OpenCode:gpt-5.6-luna

fix(actions): preserve OIDC backend errors

38a0504

Keep invalid authorization and task state failures as 401 responses while surfacing unexpected task lookup failures as logged internal server errors. Assisted-by: OpenCode:gpt-5.6-luna

fix(actions): require complete OIDC root provenance

0db13aa

Reject token issuance when the root workflow source commit or reference is missing, and cover root, reusable, scoped, and signing-key provenance cases. Assisted-by: OpenCode:gpt-5.6-terra

test(actions): strengthen OIDC integration coverage

c39e5bd

Verify the discovery-to-JWKS chain and require the expected bearer challenge for rejected OIDC token requests. Assisted-by: OpenCode:gpt-5.6-luna

fix(modelmigration): restore v28 import

a54eaa8

0xMax42 force-pushed the feat/actions-oidc branch from 8d8ce04 to a54eaa8 Compare August 23, 2026 19:54

Navigation Menu

Uh oh!

Uh oh!

enhance(actions): add OIDC workload identity support - #39052

enhance(actions): add OIDC workload identity support#39052
0xMax42 wants to merge 14 commits into
go-gitea:mainfrom
0xMax42:feat/actions-oidc

0xMax42 commented Aug 22, 2026 •

edited

Loading

Uh oh!

0xMax42 commented Aug 22, 2026

Uh oh!

silverwind commented Aug 22, 2026 •

edited

Loading

Uh oh!

0xMax42 commented Aug 22, 2026

Uh oh!

silverwind commented Aug 22, 2026

Uh oh!

0xMax42 Aug 22, 2026

Uh oh!

0xMax42 Aug 22, 2026

Uh oh!

0xMax42 Aug 22, 2026

Uh oh!

0xMax42 Aug 22, 2026

Uh oh!

0xMax42 commented Aug 22, 2026

Uh oh!

0xMax42 commented Aug 22, 2026

Uh oh!

0xMax42 commented Aug 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Uh oh!

Conversation

0xMax42 commented Aug 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

UI

Documentation

Uh oh!

0xMax42 commented Aug 22, 2026

Manual validation note

Uh oh!

silverwind commented Aug 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

0xMax42 commented Aug 22, 2026

Uh oh!

silverwind commented Aug 22, 2026

Uh oh!

0xMax42 Aug 22, 2026

Choose a reason for hiding this comment

Uh oh!

0xMax42 Aug 22, 2026

Choose a reason for hiding this comment

Uh oh!

0xMax42 Aug 22, 2026

Choose a reason for hiding this comment

Uh oh!

0xMax42 Aug 22, 2026

Choose a reason for hiding this comment

Uh oh!

0xMax42 commented Aug 22, 2026

Uh oh!

0xMax42 commented Aug 22, 2026

Uh oh!

0xMax42 commented Aug 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

0xMax42 commented Aug 22, 2026 •

edited

Loading

silverwind commented Aug 22, 2026 •

edited

Loading