Since you’re on RS256 and already have a JWKS URL, you’re in the “asymmetric signing + JWK” scenario that ODC is designed for. Key management and JSON Web Keys (JWK)

Below is a concrete way to wire this with JWTCore’s ReadToken in ODC.

1. Overall flow in ODC

Because you’re validating tokens (not generating them) and using RS256:

1. Client calls your API with Authorization: Bearer <jwt>.
2. In your OnAuthentication of the exposed REST API (recommended place), or in a common server action called from there:
   • Extract the token string.
   • Resolve the correct public key from your JWKS URL (using kid).
   • Call JWTCore.ReadToken with the JWT and that public key.
   • Enforce iss, aud, and lifetime checks.
3. If validation fails, return 401/403 and stop the request. Token-based authentication for exposed REST APIs

You can technically call this from OnBeforeRequest of a consumed API if your use case really is “validate a token we read from config/YAML before sending it out”, but structurally the logic is the same.

2. Getting the public key from JWKS (RS256)

Your IdP exposes a JWKS endpoint like:

https://<idp>/.well-known/jwks.json

Example structure:

{
  "keys": [
    {
      "kid": "abcd1234",
      "kty": "RSA",
      "alg": "RS256",
      "use": "sig",
      "n": "base64url-modulus...",
      "e": "AQAB"
    }
  ]
}

Implementation pattern in ODC:

1. Parse the JWT header to get kid:

   • Split JWT by "." → Header, Payload, Signature.
   • Base64url‑decode the header.
   • JSON‑deserialize into a structure with at least alg and kid.
   • Use kid to pick the correct JWK from the JWKS.

2. Fetch JWKS (once and cache it):

   • Create a consumed REST API that calls your JWKS URL and returns the keys array.
   • Cache the response at application level (e.g., in a server action with a timer-backed cache or just in-memory + short TTL, depending on requirements). Key management and JSON Web Keys (JWK)

3. Select the JWK with matching kid:

   • Filter the keys list by Key.kid = TokenHeader.kid.
   • If not found, reject the token.

4. Convert JWK → public key format expected by JWTCore:

   • For RS256, you’ll have n and e.
   • JWTCore normally expects either:
     • a PEM public key string (-----BEGIN PUBLIC KEY----- ...), or
     • some internal key format if the component supports JWK directly.
   • If JWTCore has helper actions for JWK/JWKS, use those and pass their output to SignatureKey. If not, you can:
     • Add a small helper (in .NET or JS inside the component, depending on what JWTCore exposes) to convert n + e into a PEM; or
     • Get the raw PEM from your IdP instead of constructing it from JWK.

From the ODC point of view, the “right” way is: store keys as JWK, get them from JWKS and rotate through that, exactly as described in the docs. Key management and JSON Web Keys (JWK)

3. ReadToken configuration for your RS256 + JWKS case

Once you have the correct public key string (or object) for the JWT’s kid, configure ReadToken like this:

• EncodedToken
  The raw JWT string (without "Bearer ").

• VerifySignature
  True — you definitely want to verify the signature.

• SignatureKey
  The public key that matches the token’s kid, in the format JWTCore expects.
  Examples:

  • A PEM public key from your IdP:

    -----BEGIN PUBLIC KEY-----
    MIIBIjANBgkq...
    -----END PUBLIC KEY-----
    

  • Or a value previously derived from the JWK.

• SignatureKeyId

  • Optional. JWTCore doesn’t require it for validation.
  • Set only if JWTCore’s internal logic uses it for logging or key lookup.
  • Since you already matched the JWK using kid, you can safely leave this empty.

• VerifyLifetime
  True — so exp and nbf are enforced.

• VerifyIssuer
  True

• Issuer
  The exact expected iss from your IdP, e.g. https://<idp-domain>/.

• VerifyAudience
  True

• Audience
  The audience your API expects (the one configured in your IdP for this client/API).

• ShowDebugInformation
  False in production; True only for troubleshooting (and even then, don’t log entire tokens or keys).

This matches the “asymmetric signing with RSA + JWK” approach recommended for ODC REST APIs. Token-based authentication for exposed REST APIs

4. Is kid / SignatureKeyId mandatory?

• kid in the JWT header:

  • Not strictly mandatory per spec, but very important when your IdP rotates keys (multiple JWKs).
  • Since you have JWKS, you should use kid to pick the proper keys[i] entry.

• SignatureKeyId input of JWTCore:

  • Not required for validation itself.
  • You can leave it blank as long as:
    • VerifySignature = True, and
    • SignatureKey is the correct public key for that token.

So in your case: use the JWT header kid only as a selector against JWKS; SignatureKeyId can remain empty unless the Forge component specifically needs it for some internal logic.

5. Best-practice checklist for your scenario

All of these are consistent with the official ODC JWT guidance. Token-based authentication for exposed REST APIs Key management and JSON Web Keys (JWK)

1. Use JWKS + kid for key selection; cache the JWKS.
2. Validate all:
   • Signature (VerifySignature = True).
   • Lifetime (VerifyLifetime = True).
   • Issuer and audience (VerifyIssuer, VerifyAudience).
3. Do not log tokens or keys.
4. Short-lived access tokens, with refresh managed by the IdP (not by your ODC API).
5. Centralize validation in a single server action (called from OnAuthentication or OnBeforeRequest) so all APIs follow the same rules.

If you want, describe briefly how your JWKS JSON looks (fields and names), and I can outline the exact data model and logic (steps) to pick the key and pass it into ReadToken in ODC terms (structures + actions).

You’re using:

• ODC platform APIs (Service Account token) to get a JWT in your DevSecOps pipeline
• The same token to call your own custom API (exposed REST in ODC) via YAML
• You want to validate that token in your custom API (or before sending it, in OnBeforeRequest)

In ODC, the validation pattern is:

• The Auth / App Auth service (ODC platform APIs) issues the token
• Your custom exposed REST API validates that token on every request (signature + claims) Token-based authentication for exposed REST APIs

Below is how to do it with RS256 + JWKS + JWTCore.ReadToken.

1. High‑level validation flow

1. Pipeline gets token from ODC platform API (service account / app token).

2. Pipeline calls your custom API with:

   Authorization: Bearer <tokenFromPlatformAPI>

3. In your custom API (exposed REST in ODC):

   • In OnAuthentication (recommended) or in a shared server action:
     1. Read the Authorization header.
     2. Extract the raw JWT string.
     3. Resolve the correct public key from your JWKS URL using kid.
     4. Call JWTCore.ReadToken:
        • Verify signature (RS256) using the public key
        • Verify iss, aud, exp/nbf
     5. If validation fails ⇒ return 401/403 and stop.
        If it passes ⇒ continue to your API logic.
        This follows the ODC pattern for token-based auth using JWTs. Token-based authentication for exposed REST APIs

You can also validate in OnBeforeRequest of a consumed REST API if your API is a client to another service, but the logic is the same.

2. Getting the public key from JWKS (RS256)

Given you already have the JWKS URL (from the same issuer that generates the token):

1. Create a consumed REST in ODC to call the JWKS URL

   • It should return something like:

     {
       "keys": [
         {
           "kid": "abcd1234",
           "kty": "RSA",
           "alg": "RS256",
           "use": "sig",
           "n": "base64url-modulus...",
           "e": "AQAB"
         }
       ]
     }
     

   • Model that as structures (JwksResponse, JwkKey).

2. Parse the JWT header to get kid:

   • Split token by . ⇒ HeaderPart, PayloadPart, SignaturePart.
   • Base64url-decode HeaderPart.
   • JSON-deserialize into a structure with at least alg, kid.

3. Pick the right key:

   • Call your JWKS REST (preferably cached).
   • Filter keys where Key.kid = Header.kid.
   • If none found ⇒ token invalid.

4. Convert that JWK into the format JWTCore expects:

   • For RS256 you need a public key:
     • Either:
       • Use a PEM public key the IdP also exposes
       • Or use helper logic (if available in JWTCore / other Forge) to convert n + e into PEM
   • Use that PEM (or key object) as SignatureKey.

This is exactly the ODC guidance: retrieve verification keys from JWKS and rotate via JWKs, not via hard‑coded secrets. Key management and JSON Web Keys (JWK)

3. Concrete ReadToken configuration (RS256 + JWKS)

Once you have the token and the public key (from JWKS):

EncodedToken        = <raw JWT from Authorization header, without "Bearer ">
VerifySignature     = True
SignatureKey        = <public key from JWKS, e.g. PEM string>
SignatureKeyId      = ""   // Optional, not required for validation
VerifyLifetime      = True
VerifyIssuer        = True
Issuer              = "<expected iss from platform API token>"
VerifyAudience      = True
Audience            = "<your custom API's audience>"
ShowDebugInformation= False (True only during debugging, never log full token/key)

Key points:

• SignatureKey: public key that corresponds to the token’s RS256 private key.
• SignatureKeyId: not mandatory; leave blank unless JWTCore specifically uses it for something internal.
• Issuer: must match the iss in the token your ODC platform APIs generate.
• Audience: whatever you configured as audience for that API / token (for service account tokens, usually a client or API identifier). Token-based authentication for exposed REST APIs

If ReadToken throws or returns an “invalid” result, treat the token as not valid.

4. Where exactly to plug this in

A. To validate inside your custom API (recommended)

• Expose a REST API in ODC.
• Set authentication to custom via OnAuthentication.
• In OnAuthentication:
  1. HeaderValue = GetRequestHeader("Authorization")
  2. Token = Replace(HeaderValue, "Bearer ", "")
  3. Call a shared action ValidateJwt(Token) that:
     • Resolves public key from JWKS
     • Calls JWTCore.ReadToken as above
  4. If validation fails:
     • Response_SetStatusCode(401) (or 403 if token is valid but not allowed)
     • End request / raise error. Token-based authentication for exposed REST APIs

Then, any call from your pipeline using the ODC platform token will be validated as “valid or not” automatically on every request.

B. To validate before sending a request (OnBeforeRequest, consumed REST)

If your scenario is:

• You have a consumed REST (you are a client) and
• You want to check a pre-configured token in YAML before attaching it:

In OnBeforeRequest of that consumed REST:

1. Read token (from Site/Secret/parameter).
2. Optionally validate it with the exact same ValidateJwt(Token) action.
3. If valid:
   • Set the request header: Authorization = "Bearer " + Token
4. If invalid:
   • Decide: fail immediately or fetch a new token.

The same JWT validation logic (JWKS + ReadToken) is reused; only the place in the pipeline changes.

5. How do you answer your original question?

“I’m using the token generated by the ODC platform API’s in the devsecops pipeline and using the same token to invoke a custom built API through YAML. How do I validate this token is valid or not?”

Answer:

• Configure your custom API’s OnAuthentication (or a shared ValidateJwt action called from there) to:
  • Get the JWT from Authorization header.
  • Look up the public JWK from the platform’s JWKS URL using kid. Key management and JSON Web Keys (JWK)
  • Call JWTCore.ReadToken with:
    • VerifySignature = True, SignatureKey = public key
    • VerifyLifetime = True
    • VerifyIssuer = True, Issuer = <platform token issuer>
    • VerifyAudience = True, Audience = <your API audience>
• If ReadToken succeeds ⇒ token is valid and request proceeds.
• If it fails ⇒ respond with 401/403; token is not valid for that API. Token-based authentication for exposed REST APIs

If you share the exact iss and aud shape of the platform token (or a sample payload with names redacted), I can suggest precise string values for Issuer and Audience in your ReadToken call.