AWS STS Rejects Valid Forgejo OIDC Token

Question

I am using Forgejo 15.0.6 LTS with an AWS IAM OIDC provider configured for:

```text
Issuer: https://git.sakthisanthosh.in/api/actions
Audience: sts.amazonaws.com
Subject: repo:ssanumand/lad-forgejo-aws-oidc:ref:refs/heads/main
```

The workflow is:

```yaml
name: AWS OIDC Test

on:
  workflow_dispatch:

enable-openid-connect: true

jobs:
  test-aws-oidc:
    runs-on: debian-trixie
    env:
      AWS_USE_DUALSTACK_ENDPOINT: "true"
      AWS_REGION: "ap-south-1"
      AWS_DEFAULT_REGION: "ap-south-1"

steps:
      - name: Get OIDC Token
        run: |
          curl -6 --fail --silent --show-error \
            -H "Authorization: Bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN" \
            "$ACTIONS_ID_TOKEN_REQUEST_URL&audience=sts.amazonaws.com" \
            | jq -rj '.value' > /tmp/oidc-token

- name: Configure AWS Credentials
        env:
          AWS_ROLE_ARN: arn:aws:iam:::role/ForgejoActions
          AWS_WEB_IDENTITY_TOKEN_FILE: /tmp/oidc-token
          AWS_ROLE_SESSION_NAME: forgejo-actions
        run: |
          aws sts get-caller-identity
```

AWS returns: An error occurred (InvalidIdentityToken) when calling the AssumeRoleWithWebIdentity operation: The web identity token provided could not be validated.

The IAM provider and trust policy exactly match the token’s issuer, audience, and subject. I recreated the IAM OIDC provider and reapplied the trust policy. The discovery and JWKS endpoints return HTTP 200 from AWS CloudShell and are cached at Cloudflare with `CF-Cache-Status: HIT`. The JWT uses RS256, its `kid` exists in the JWKS, and I independently verified its signature using the published RSA modulus and exponent. What additional AWS STS validation requirement could cause `InvalidIdentityToken` for an otherwise valid OIDC token?

Riku_Kobayashi · Accepted Answer

Hello.

Is it possible to actually inspect the header and payload of a JWT issued by Forgejo?  
I believe it is necessary to verify that the `alg` in the header is `RS256` and that the `kid` in the header matches the `kid` in the JWKS exactly.  
You will also likely need to verify that the `sub` claim in the payload matches the IAM trust policy condition exactly.  
```
curl -s \
  https://git.sakthisanthosh.in/api/actions/.well-known/keys \
  | jq
{
  "keys": [
    {
      "alg": "RS256",
      "e": "AQAB",
      "kid": "zufh62wMCHeIo9GDCQbR2lQp_w1_ywvzUyfKn09Wa_A",
      "kty": "RSA",
      "n": "8Hrg1JDv6D633cBsILqDPnENUAU_IxvkOIMrV8eKrAPV-ek1C6mY0AdVLYw1JYTFJ9O6KmWsTnT2BjUcygfa8_6CDUJ3A16o8QAAcOoPIDcmEyukOxHyMrDCNchXzucWfJbwq0s79fgyWVZYDIkN4GBR5DWjRqa_UucvM4xu1iqGK5e92eZRHIHAFO-c67HU3UAQOArg6SEVLJVNkA3drT7pXfmO4xiG1BcrQtfpRBNSfCfrwPV7k7zgv3BZL3Y8bP7zemNrz3wmhDB66KOc_rFQZ2VPul3RG3x9IxgioMeEacnxH4khwRS12nXACzWvqqrcdT5L45wDcb5Ad9N1HQ",
      "use": "sig"
    }
  ]
}
```

AWS STS Rejects Valid Forgejo OIDC Token

Add your answer

Relevant content