How do I set multiple values in AUD claim?

Hi There.
Am an Okta noob, but… .
My reading of OIDC spec suggests that an Auth Server should be able to set multiple values for the AUD claim.
I can’t seem to be able to do this from the Okta UI - should i be looking at programmatic control to achieve this?

Do i even want to be doing this?
The aim is to have a web-app (written by 3rd party) retrieve an access token, which is passed to my API, i’m thinking it makes sense that the web-app and the API would have different audiences.

Thanks for any help.

Answering my own question.
Per documentation Okta only supports a single value for audiences (aud).
Not sure how this is goes with OIDC certification, but now i know.

Hi @willba - what is your use case for multiple audiences?

Hi @tom
Thanks for the follow up.
The scenario i have is that my company provides a heap of UI and functionality to a customer for their internal users. Our customer wants to provide similar functionality to their external users(their customers).
So they have engaged a 3rd party to create a web-portal, as well as putting some middleware onto their estate. Their portal will use an authorization server (ala OIDC/OAUTH2 ) for user login. i was thinking that the access-token used by the portal would be passed through the middleware to our application. By using separate audience identifiers it would mean that our interface would only need to know about “our” audience ID, and the 3rd party web-app would use “their” audience ID.
The reasoning about separate audience IDs is that it’s conceivable that the web-portal might have users that have no business using our interface/functionality, and also that our interface might be used by other systems that shouldn’t need to know anything about the web-portal.
I haven’t been able to find anything about best practice WRT this scenario, so had a guess at using separate audiences…

Any guidance or references will be very appreciated.


Interesting use-case. Does the 3rd party apps have different scopes, or are they the same?

@tom - it’s probable that 3rd party apps would have different scopes (still early days).
in particular the web-portal would offer a range of functionality that would use yet other APIs, so access control for the UI would be a superset of that required by the “our” API.
Does this make sense in the context of OAuth/OIDC?

It might make sense to use multiple authorization servers here. This will allow you to provide the correct policies and scopes for the different use cases, without the two mixing. This means that the issuer of the token will be different.

3rd party web app would use their authorization server.
Your UI would use your authorization server.

The middleware would be issuer aware, not audience aware. My general feeling on why this matches your use case comes down to an issue that you will run into, which scopes are for which audience? If there is an overlap between your use cases (which I believe will be true because this sounds like b2b2c) I think haven’t issuer division, policy division, and scope division will be important.

Also, there may be some scopes for your UI usecase that may not require user consent for scope, but you need to enforce that for the 3rd party web-app. The issuer and scope division will be able to handle that as well.

Let me know if this sounds off, you have the complete information here :slight_smile:


Hi @tom
Your idea seems right - divide at authorization level rather than audience level.
Though it means that the portal will need to explicitly know about down-stream systems and their corresponding authorization server(s).
Also, can i use an authorization code grant on 2 different authorization servers?
Otherwise will the user be redirected twice and have to supply credentials twice?
PS: I am cognizant that i am chewing up your time, so feel free to drop off the thread any time.

Did this get this figured out? It sounds like the same issue I’m facing. We are implementing micro-services and are binding each service to their own authorization server. We have created an auth library that will handle discovering the downstream services needed and will be used to fetch access tokens from each and cache the tokens server side… the client only has the token needed to authorize them to access the consuming application. The issue for us is we can’t figure out how to get access tokens from the services’ authorization servers without needing to build a custom login page to capture credentials to pass to each auth server. I can’t think this is what is needed, but I’m at a loss here. Is there a better way to get access tokens for the user who originally logged in?

I’ve searched for over a week now and haven’t found anything. The fact I can’t find anything makes me wonder if I’ve got the approach all wrong or if it’s something so simple I’m just not seeing it. Any help would be greatly appreciated!

Hi @croden

If the user currently has a session in Okta, you can redirect him client side to the authorization endpoint for each application, without needing him to log in.
If you have the user’s credentials, you can authenticate him through /api/v1/authn and then use the sessionToken as query parameter on /authorize endpoint or simply pass the credentials to get JWTs using resource owner password flow.
If the user is not logged in and you don’t have the user’s credentials, Okta does not have an option to create JWTs for any user.