Missing audience in Oauth2.0 authentication

I’m implementing Oauth2.0 authentication for minIO (open-source clone of AWS S3) with auth0 as OIDC provider.
I’d like to experiment with Postman and to set up authentication at the Collection level using the Authorization Code flow.

My question:
I am able to get Access & ID tokens manually with a GET in browser :


…get the code and re-inject it in the POST request :

❯ curl --request POST \
  --url 'https://<AUTH0_SERVER>.auth0.com/oauth/token' \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data grant_type=authorization_code \
  --data 'client_id=<CLIENT_ID>' \
  --data client_secret=<OAUTH_SECRET> \
  --data code=<CODE_FROM_PREVIOUS_GET> \
  --data 'redirect_uri=<REDIRECT_URL>'

…which gives me conform acces & ID JWT tokens.

However, when I use the collection authentication helper in Postman, the JWT access token I get has an empty payload. When checking the logs, I can see that the first authent GET does not include the audience as parameter. Is this a bug or am I misusing the helper ?

Details (like screenshots):

Postman console:

10:35:50.975 GET https://<AUTH0_SERVE>.eu.auth0.com/authorize?response_type=code&client_id=<CLIENT_ID>&scope=openid%20profile&redirect_uri=<REDIRECT_UL>: {
  "Request Headers": {
    "upgrade-insecure-requests": "1",
    "user-agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Postman/9.25.2 Chrome/94.0.4606.81 Electron/15.5.7 Safari/537.36",
    "accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9",
    "sec-fetch-site": "none",
    "sec-fetch-mode": "navigate",
    "sec-fetch-user": "?1",
    "sec-fetch-dest": "document",
    "accept-encoding": "gzip, deflate, br",
    "accept-language": "en-US",
    "cookie": "XXXX"
  "Response Headers": {
    "alt-svc": "h3=\":443\"; ma=86400, h3-29=\":443\"; ma=86400",
    "cache-control": "no-store, max-age=0, no-transform",
    "cf-cache-status": "DYNAMIC",
    "cf-ray": "734db8e20bf83aa5-CDG",
    "content-length": "218",
    "content-type": "text/html; charset=utf-8",
    "date": "Wed, 03 Aug 2022 08:35:51 GMT",
    "expect-ct": "max-age=604800, report-uri=\"https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct\"",
    "location": "<CALLBACK_URL>",
    "ot-baggage-auth0-request-id": "734db8e20bf83aa5",
    "ot-tracer-sampled": "true",
    "ot-tracer-spanid": "396662ca75611b13",
    "ot-tracer-traceid": "6631e7003ade1bb9",
    "pragma": "no-cache",
    "server": "cloudflare",
    "set-cookie": [
      "auth0=xxxx; Path=/; Expires=Sat, 06 Aug 2022 08:35:50 GMT; HttpOnly; Secure; SameSite=None",
      "auth0_compat=xxxx; Path=/; Expires=Sat, 06 Aug 2022 08:35:50 GMT; HttpOnly; Secure"
    "strict-transport-security": "max-age=31536000",
    "traceparent": "00-396662ca75611b13-00000000000000006631e7003ade1bb9-01",
    "tracestate": "auth0-request-id=xxxxx",
    "vary": "Accept, Accept-Encoding",
    "x-auth0-requestid": "xxxxx",
    "x-content-type-options": "nosniff",
    "x-ratelimit-limit": "300",
    "x-ratelimit-remaining": "299",
    "x-ratelimit-reset": "1659515752"

How I found the problem:

I’ve already tried:

1 Like

Same problem here. Resource-Settings gets applied but audience not…

I am also facing same issue, Audience parameter is not getting passed,
Is there any updates on this issue?

Piling on here to say the same. For auth0 at least, the “audience” parameter is required in the Auth URL, but it’s being placed in the Access Token request. I’m having trouble finding if this is a requirement of any of the OAuth 2 RFCs or related docs but unfortunately this parameter is basically a requirement in the Auth URL if you don’t want to get malformed, “empty” JWTs.

Fortunately there’s a workaround that has worked for me: just add “audience” to the Auth URL directly. For auth0, you’d probably put something like https://<AUTH0_SERVER>.auth0.com/authorize?audience=<THE_AUDIENCE>. With that I’ve been able to successfully get a good access token JWT from auth0.

Of course if someone from Postman sees this it would be preferred if this were handled more cleanly within the OAuth 2.0 functionality itself. :slight_smile:

1 Like

Nice tip @ChrisSimmons - thanks!

I agree this looks busted (for use with Auth0 at least). I’d like to see audience added correctly to authorise API call too. Without it Auth0 responds only with opaque access tokens.