Subject: [OAUTH-WG] Multiple authorization servers for one resource server

From: Takahiko Kawasaki <[email-masked]>
Date: Sat, 12 Mar 2016 12:02:26 +0900

Hello,

I have a question.

If there exist multiple authorization servers that can issue access tokens
for one resource server, when the resource server receives an access token
from a client application, as the first step, the resource server has to
determine which authorization server to use for access token introspection.

Is there any standard way to determine which authorization server to use?

There may be several ways, for example:

(1) Embed information about the access token issuer in the access token.
(2) Add a request parameter to identify the access token issuer.
(3) Separate protected resource endpoints for each authorization server.

If there is a standard way, I'd like to know it.

Best Regards,
Takahiko Kawasaki

---

From: Justin Richer <[email-masked]>
Date: Sat, 12 Mar 2016 20:03:09 -0500

What we've done in deployments is to combine JWT and introspection. You 
have all of your servers issue signed JWTs that include the "iss" 
(issuer) in the body, signed with the key of the AS. The tokens also 
include a random "jti" field. The RS submits the token to the 
introspection endpoint of the server identified in "iss", but only after 
validating the signature and other basic bits of information. If the 
introspection call comes back positive (and with the right scope, 
client, and resource owner information), the resource is served.

  -- Justin

On 3/11/2016 10:02 PM, Takahiko Kawasaki wrote:
> Hello,
>
> I have a question.
>
> If there exist multiple authorization servers that can issue access 
> tokens for one resource server, when the resource server receives an 
> access token from a client application, as the first step, the 
> resource server has to determine which authorization server to use for 
> access token introspection.
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Thomas Broyer <[email-masked]>
Date: Mon, 14 Mar 2016 00:00:39 +0000

On Sun, Mar 13, 2016 at 2:03 AM Justin Richer <[email-masked]> wrote:

> have all of your servers issue signed JWTs that include the "iss" (issuer)
> in the body, signed with the key of the AS. The tokens also include a
> random "jti" field. The RS submits the token to the introspection endpoint
> of the server identified in "iss", but only after validating the signature
> and other basic bits of information. If the introspection call comes back
> positive (and with the right scope, client, and resource owner
> information), the resource is served.
>

But you cannot force every AS to emit access tokens that are JWTs.
For those AS that won't, then the RS would probably have to provide
endpoints (token endpoints?), one per AS, where the client could exchange
an AT from the AS for an AT specific to the RS (using token exchange with
unauthenticated clients?)

---

From: Andrea Ceccanti <[email-masked]>
Date: Mon, 14 Mar 2016 10:36:14 +0800

Hello,

interesting thread, thanks.

Assuming the scopes are included in the token, the main purpose of call to
the introspection endpoint is to ensure
the token hasn't been revoked?

We are considering a deployment where a RS can trust multiple AS, and
having a JWT as access token, with
issuer, scopes and basic identity information included seems to solve our
issues.

Thanks,
Andrea

2016-03-13 9:03 GMT+08:00 Justin Richer <[email-masked]>:

> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: Justin Richer <[email-masked]>
Date: Mon, 14 Mar 2016 17:13:11 -0400

We don’t include the scopes or identity information in the token itself, so as to prevent it from leaking to parties that shouldn’t need it. 

The main benefit of introspection is liveness, but it also lets you reference data tied to the token that you don’t want to ship in the token itself.

At the end of the day, it’s a trade off as to what you want to put into the token and what you want attached as a reference. Good news is that you can do both together and use the strengths of each.

 — Justin

> On Mar 13, 2016, at 10:36 PM, Andrea Ceccanti <[email-masked]> wrote:
> 
> Hello,
> 
> Assuming the scopes are included in the token, the main purpose of call to the introspection endpoint is to ensure
> We are considering a deployment where a RS can trust multiple AS, and having a JWT as access token, with
> issuer, scopes and basic identity information included seems to solve our issues.
> 
> Thanks,
> Andrea
> 
> 
> 
> 
> 2016-03-13 9:03 GMT+08:00 Justin Richer <[email-masked] <mailto:[email-masked]>>:
> What we've done in deployments is to combine JWT and introspection. You have all of your servers issue signed JWTs that include the "iss" (issuer) in the body, signed with the key of the AS. The tokens also include a random "jti" field. The RS submits the token to the introspection endpoint of the server identified in "iss", but only after validating the signature and other basic bits of information. If the introspection call comes back positive (and with the right scope, client, and resource owner information), the resource is served.
> 
>  -- Justin
> 
> 
>> If there exist multiple authorization servers that can issue access tokens for one resource server, when the resource server receives an access token from a client application, as the first step, the resource server has to determine which authorization server to use for access token introspection.
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
>