Missing aud parameter in OIDC redirect


I am following the steps here: https://developer.okta.com/docs/guides/add-an-external-idp/openidconnect/before-you-begin/ to create an app that authenticates with an external OIDC provider and have followed all the steps.

When I test the app, what’s happening is that Okta redirects to the idp using the generated authorize url of the format https://.okta.com/oauth2/v1/authorize?idp=<their_idp>&client_id={clientId}&response_type={responseType}&response_mode={responseMode}&scope={scopes}&redirect_uri={redirectUri}&state={state}&nonce={nonce}, and the idp says that the aud is missing/not valid. By copying the full url and adding an aud parameter manually (matching with the issuer for the idp), I can actually authenticate with it and receive the id/access tokens from Okta and my app loads. Is it possible to add this parameter to the authorize url or am I missing something? The external idp is not under my control so I’m wondering if it’s a proprietary requirement. I’ll provide more background and information if needed.


Hi @pacauth,

Could you let us know what type of external idp you have configured (OpenIdConnect IDP or SAML IDP) ?
Could you send the working url with the aud parameter ?
Would it be possible for you to capture the network request/response ?

Hi @pacauth

The audience is set up by the identity provider and is in the form of “https://org.okta.com” where this URL is the URL of your Okta tenant. We do not offer any option to send the audience to the OIDC identity provider as the audience relies solely on the identity provider’s side in order to generate valid JWTs to authenticate the user in Okta.

Hi @gpadma and @dragos,

It is an OIDC IDP. I can’t recreate the problem now actually. I have been messing with this code from both front-end and back-end so perhaps I was doing something wrong before and have fixed it now.

I do want to confirm if what I’m seeing is what’s expected. The workflow of the app is: there is a 3rd party app where a user would be logged in. When they click a link/button, my app opens in an iframe within that app (they call my app with some contextual information which includes the issuer). When my app loads I want to SSO the user so they don’t have to log in to my app separately. What I’m seeing now is, my app makes a call to the v1/authorize endpoint of my dev Okta org, which redirects to the /implicit/callback endpoint with the id_token and access_token present. There is no communication to the 3rd party idp visible on the browser side. Does that sound correct?

Also, the current version I’ve got this working loads my app in a separate tab. When using the iframe version it’s not able to set certain cookies and I get an AuthSdkError message. I am using older versions of the okta-auth-js and okta-oidc-js libraries however, and looking at the more recent versions of those it seems like this may have been fixed via cookie options. Please let me know if upgrading the libraries is the way to go; I wanted to confirm before taking on that task.

Thanks so much!

I started upgrading the front end libraries to the latest version. I’m seeing the original issue again.

My app makes this call: https://<my_dev_org>.okta.com/oauth2/v1/authorize?client_id=0oa13z8c94l936c8d4x7&code_challenge=TqZxXjy6ez0mXFhcvgcp3E0_7gpAnTUfqgfpva9knsY&code_challenge_method=S256&idp=0oa13z725b7nC4PeK4x7&nonce=38PeqevfszDb5D6yDSS3huVBet9JSxo7QR6LolX03HZ6yUypHnQyuag41FQ7uF6R&redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Fimplicit%2Fcallback&response_type=code&state=21yNBQxszXOU9k8GCloPlkNjsGL4HHhUakLpQpqo4h9bqh6wHdgrRfuhUKwB9Me3&scope=openid%20email%20profile

which receives a 302 redirect to https://<other_idp>/authorize?state=TUlyUFpGZm9sd3ZEb1l5RUlpTzh1YUhKbVIycGlETFZ2d2N6dkFEUTJHaHJ5WkVuU2dxalNxSHZYWDB0YU9LdQ&client_id=34b8df53-54e5-4be5-9c6e-40e47b115e4b&redirect_uri=https%3A%2F%2F<my_dev_org>.okta.com%2Foauth2%2Fv1%2Fauthorize%2Fcallback&response_type=code&display=page&scope=openid+profile+email

This redirect is what’s missing the aud parameter. If I take the url and add an aud paramater matching the issuer for the 3rd party idp, then I’m taken to the 3rd party idp’s login page. After logging in I can approve access for the app, but when I do approve it I get redirected to Okta, which then throws a 400 saying:

Identity Provider: Unknown

Error Code: access_denied

Description: Social transaction expired.

I’m wondering if this whole approach is wrong. Maybe I need to authorize with the 3rd party directly, then use the tokens received from there to authenticate with my Okta org somehow and not deal with the idp integration stuff. Please advise.

Hi @dragos and @gpadma, please advise on this use-case.

My app is an SPA that needs to load in an iframe in a 3rd party app with its own IDP. My app also has its own backend and Okta-based user management. When the user clicks a link on the 3rd party app and loads my app, I want to login the user to my org without them having to login again, and then I want to verify it’s an authorized user for the particular site and access protected resources on my org. I set it up so that my app makes a call to /authorize on my Okta org, then Okta redirects to the 3rd party IDP. That part is working but the 3rd party IDP wants an aud parameter (equal to the url of their issuer) in the /authorize redirect which Okta isn’t sending to them.

The call from my app looks like: https://<my_dev_org>.okta.com/oauth2/v1/authorize?client_id=0oa13z8c94l936c8d4x7&idp=0oa13z725b7nC4PeK4x7&nonce=UTwKLe9ggFFAedyMINZi92I7IM6CqHGHgb8o8kHJCvJS17Vd56Endu9UhSwsoUay&redirect_uri=http%3A%2F%2Flocalhost%3A3000%2Fimplicit%2Fcallback&response_type=id_token%20token&state=wfosJAn9pSgpKAQKiSr3W30QaqDRWdFfZEyLPnTINibI6brj8nsXG6lWO7PZ3Bqy&scope=openid%20email%20profile

which redirects to


the aud parameter is required in this call in the format &aud=<their_issuer_url>

I checked a couple of the 3rd party providers and both needed the aud parameter.

Is this not the right approach? Or, should I authorize with their IDP, receive the tokens and somehow use those tokens to validate/authorize against my Okta org? That does not seem right to me.

Thanks in advance.

I am also interested in the answer. We are trying to use an external OIDC identity provider, and it requires an “aud” parameter in the request to its authorize endpoint.

I’m wondering if there is a subtle distinction between OIDC, and an OAuth2 authorize endpoint that happens to support the “openid” scope.

Hi @pacauth and @wrschneider

aud is not part of the authorization’s endpoint query parameters as per https://openid.net/specs/openid-connect-core-1_0.html. The audience is present as a claim in the access token generated by the identity provider.

I have added this topic to our Feature Requests section in order to make it visible to our engineering team and have the option for “aud” parameter passed to the identity provider possibly implemented in the future.

1 Like

Thanks. I agree, the identity provider in question is part of SMART on FHIR and may not exactly follow the OpenID spec. Rather it looks like it follows the OAuth2 spec, but with OpenID scopes supported.

If this is not strictly OIDC, but something else, is there a way to support it in Okta today?

If not, it would be a feature request.