OAuth Login fails due to "aud" claim being an array

[Trickfilm400]

Hi,

I have configured Zitadel as an OAuth Provider. The Login flow works, but in the Log file an error is printed and I'm not logged in.

The Error is

{"level":"debug","error":"invalid aud claim","time":"2024-10-02T00:05:14+02:00","message":"OAuth access token is invalid"}

The JWT Payload is the following (part of):

{
  "aud": [
    "287419081525624851",
    "287418988378456083"
  ],
  "exp": 1727864564,
  "iat": 1727821364,
  "iss": "https://example.com",
  "jti": "V2_287436263340900371-at_287436264666300435",
  "nbf": 1727821364,
  "sub": "208358293549088776"
}

I've identified the following line as the issue probably: https://github.com/Zibbp/ganymede/blob/main/internal/auth/oauth.go#L217

It seems the code expects aud as an string, but in my case it's an array, which is also an valid option for a JWT token. (https://mojoauth.com/glossary/jwt-audience/)

In the JSON Web Token (JWT) standard, the "aud" (audience) claim is a string or array of strings that identifies the recipients that the JWT is intended for.

Could you fix the line to check for a valid option inside an aud array as well?

[Zibbp]

Hey,
I've updated the logic in #521 to support checking if the aud is an array of strings. I spun up a Zitadel instance to test but ran into issue after the aud is validated. It appears Zitdael isn't sending the nickname or preferred_username in the access token causing auth to ultimately fail. I'm not familiar with Zitdal, maybe you know a workaround for this?
If you want to try the partial fix you'll need to build the image using the branch in the PR.

[Trickfilm400]

I've testet the fix and the aud issue is fixed. To the nickname thing: I don't think there is a simple fix for this, as the idea is to use the https://example.com/oidc/v1/userinfo HTTP Endpoint for Zitadel in this case to get all of the user details. You should be able to clal this endpoint with the given jwt token and the endpoint is published on the well-known openid endpoint (as this endpoint differs from oidc provider)