OIDC scenario with multiple resource servers

[Mak, Steven]

> App1 would include a resource parameter with its request so that the access token issued to App1 will be usable to access App2 on behalf of the user.

So this is the part that I don't understand, but something I'm fairly certain I want to do.

I've looked in the OPTokenAudience and OPAuthorization documentation pages, but I don't see how this is done. Is there a different document that explains how to setup this sort of behavior, or do I just need to read these two and figure it out?

- Steve

From: Cantor, Scott <cantor.2 at osu.edu>
Date: Tuesday, June 17, 2025 at 8:57 AM
To: Shib Users <users at shibboleth.net>
Cc: Mak, Steven <makst at upenn.edu>
Subject: Re: OIDC scenario with multiple resource servers
> My question is mostly: Is sharing an OIDC secret a bad idea?

It's not intended certainly.

You don’t have multiple resource servers here. An OIDC RP is not really a resource server, that's an OAuth concept for a system you want to access from an OAuth client (the RP in this case, App1).

> How should this be done? Is this a "two-legged" scenario?

Depends if you count the browser, but it's four-legged essentially, it's the original OAuth use case (what was called three-legged) but adding an authorization server into the mix instead of App2 issuing its own tokens.

App1 would include a resource parameter with its request so that the access token issued to App1 will be usable to access App2 on behalf of the user.

Using a JWT access token lets it carry custom claims about the user to communicate that to App2 without the user actually interacting with it at all or it needing access to the UserInfo endpoint, which it would not have. App2 could also introspect the token in lieu of using JWT format though.

-- Scott

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20250617/67fcebf5/attachment.htm>