Running into a wall with the aud claim when validating the JWT returned by the implicit grant flow in our React-based Custom Agent Desktop app. The token comes back fine, and I can decode it, but my validation logic keeps rejecting it because the audience doesn’t match what I expected.
Here is the relevant part of the JWT payload I’m seeing in the browser console:
{
"sub": "agent-user-id-123",
"aud": "https://api.mypurecloud.com",
"iss": "https://login.mypurecloud.com",
"exp": 1715623400,
"iat": 1715619800
}
My validation function in the React component is checking for aud: 'https://api.mypurecloud.com', which looks correct. However, when I switch to our staging environment, the aud claim changes to https://api.dev.mypurecloud.com, and my static check fails. I tried making the check dynamic based on the environment, but the token structure seems to vary slightly between prod and dev in ways I didn’t anticipate.
I’m using the @genesyscloud/genesys-cloud-sdk-js to handle the auth flow, but I’m manually validating the token before making API calls to /api/v2/users/me to ensure the session is still active. The SDK doesn’t seem to expose a direct method for this specific validation step, so I’m doing it manually with jwt-decode.
The issue is that sometimes the aud claim includes multiple values or a different format entirely, causing the validation to throw. Is there a standard way to handle this audience validation across different environments without hardcoding the base URLs? I’ve tried checking the iss claim instead, but that doesn’t guarantee the token is valid for the specific API endpoint I’m trying to hit.
Also, the token expiry seems to be shorter than expected in the staging environment, causing frequent re-auth prompts. I’m not sure if that’s related to the audience mismatch or a separate config issue. Any pointers on how to robustly handle this token validation in a React SPA context would be appreciated. I’m stuck on whether to trust the SDK’s internal state or keep doing manual checks.