Support Access Tokens with multiple audiences

[Hard265]

Description

According to RFC 8707 §2 — Resource Indicators for OAuth 2.0

Multiple resource parameters MAY be used to indicate that the requested token is intended to be used at multiple resources.

Currently, node-oidc-provider accepts only a single resource value in token and authorization requests.
When multiple resource parameters are provided, only one (usually the last) is parsed and exposed to ctx.oidc.resource and getResourceServerInfo.

This limits spec compliance and makes it impossible to issue multi-audience tokens across multiple protected APIs managed under one Authorization Server.

---

Why / What for

• Spec compliance: RFC 8707 explicitly allows multiple resource parameters.
• Practical need: large ecosystems often expose multiple resource APIs (e.g., files, billing, analytics) under a single AS.
• Security alignment: enabling multiple validated resources allows the AS to control audience scoping centrally while producing a single JWT containing multiple audiences (aud array).

---

Example

POST /token
grant_type=authorization_code
code=abc123
redirect_uri=com.app://cb
resource=https://api.one.example.com
resource=https://api.two.example.com

Expected behavior:

• ctx.oidc.resource should contain all resource values.
• getResourceServerInfo(ctx, resourceIndicator, client) should be called for each.
• Resulting token may contain aud as an array if the AS deems appropriate.

Actual behavior:

• Only the first resource value is honored.

---

Possible implementation direction

1. Change request parsing to:

- const resource = params.get('resource');
+ const resource = params.getAll('resource');

2. Allow ctx.oidc.resource to be an array.

panva/jose already supports aud arrays, so JWT generation doesn’t require special handling beyond normalization.

---

References

• RFC 8707 §2 – Resource Indicators for OAuth 2.0
• OIDC Core 1.0 incorporating OAuth 2.0 Resource Indicators

[panva]

The way this is implemented in oidc-provider is very much intentional, functional, and exactly within the parameters (MAY is not a mandate) of the specification and best practices.

Currently, node-oidc-provider accepts only a single resource value in token and authorization requests.

This is not entirely true. You can already provide multiple resource parameters during the authorization request. The limitation of one audience is there solely on the issued access tokens. Having access tokens with multiple unrelated audiences is not what i'm willing to implement. To that end the client can request multiple audiences upfront, grant them, have them granted on an RT, and then exchange the RT for the individual audiences with the refresh token grant.

only one (usually the last) is parsed and exposed

This is not true, when multiple resource parameters are provided all of them are available after parsing in ctx.oidc.params and it is the job of the defaultResource configuration helper (i.e. your extension points' code) to determine which is going to end up being used for the issued access token. When the helper doesn't determine which one to use then invalid_target is thrown with a only a single resource indicator value must be requested/resolved during Access Token Request description.

[panva]

And this is also documented in https://github.com/panva/node-oidc-provider/blob/v9.x/docs/README.md#featuresresourceindicators

[Hard265]

Thanks for the clarification — that makes perfect sense. Appreciate the detailed explanation and the insight into how defaultResource and audience handling are designed.

[enten]

Having access tokens with multiple unrelated audiences is not what i'm willing to implement.

I'm understand your point of view and that is consistent with RFC8707 3. Security Considerations which encourages only a single resource parameter in a token request.

As the RFC8707 doesn't forbid multiple resource parameter in a token request: I think it's essential that node-oidc-provider supports that usecase.

Indeed, your work is the reference of AS in node ecosystem and it should implement all usecases envisaged by specs supported like the RFC8707.

Would you be ready to go further about multiple resource parameter in a token request ?

Indeed I'm starting to work on that and I would like to know if you are open to any potential contributions for this usecase.

[panva]

Again, there IS support a request containing multiple resource indicators. There IS NOT and I won't entertain it, support for issuing an access token with multiple audiences. As such, the server configuration MUST implement the defaultResource helper such that for a token-issuing request with multiple indicators only one of them is selected.

[panva]

Indeed, your work is the reference of AS in node ecosystem and it should implement all usecases envisaged by specs supported like the RFC8707.

I strongly disagree. I will not support Access Tokens with multiple audiences.