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

From: Mike Schwartz <[email-masked]>
Date: Sun, 13 Mar 2016 15:44:09 -0500

I like the idea of an encrypted JWT... I guess if there are multiple 
AS's, how would you know which key to use? Cycle through each key? Are 
you suggesting maybe use a non-encrypted JWT that contains an encrypted 
JWT as a value? Something like

{"iss": "https://example.com",
  "token": "fjbfgy5Fdx8ybx0.."
}

Are there any OAuth2 profiles to standardize this approach?

- Mike

--------------------------

Michael Schwartz
Gluu
Founder / CEO
[email-masked]

---

From: John Bradley <[email-masked]>
Date: Sun, 13 Mar 2016 18:20:50 -0300

I would expect the RS would only have one or two keys that it has published for encryption.  

I would expect the encryptor to provide a key ID “kid”  if the RS has published more than one key (eg for key rotation) and they probably should anyway unless size is unusually constrained.

See JWE 4.1.6

The number of AS is not relevant for encryption to the RS unless you are using symmetric keys, and in that case there is likely only one key per AS (iss) so iss should be sufficient.

John B.

> On Mar 13, 2016, at 5:44 PM, Mike Schwartz <[email-masked]> wrote:
> 
> I like the idea of an encrypted JWT... I guess if there are multiple AS's, how would you know which key to use? Cycle through each key? Are you suggesting maybe use a non-encrypted JWT that contains an encrypted JWT as a value? Something like
> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: George Fletcher <[email-masked]>
Date: Mon, 14 Mar 2016 11:07:44 -0400

For what it's worth, we deployed such a system in 2011 using signed 
JWTs, symmetric keys and supporting key rotation via the kid JWT header 
field. The body of the JWT includes 'iss', 'exp', 'uid' (for the user), 
'access_token' (AS specific opaque blob), and 'validation_url' (where to 
validate the AS specific opaque blob).

The issuing AS would generate this JWT and sign it. The RS, then 
validates the signature. If necessary, the RS then also validates the 
opaque token with the issuing AS.

Of course, using encrypted JWTs may be a better solution these days:)

Thanks,
George

On 3/13/16 4:44 PM, Mike Schwartz wrote:
> you suggesting maybe use a non-encrypted JWT that contains an 
> encrypted JWT as a value? Something like
>

---

From: Mike Schwartz <[email-masked]>
Date: Mon, 14 Mar 2016 11:16:45 -0500

This was the original requirement:

" 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."

Not sure we're all on the same page after numerous responses...

So the fact that the token is an encrypted JWT is great... the question 
is: who issued it? That's why I was thinking of a url encoded JWT with 
the issuer + the encrypted token, such as {"iss": 
"https://as.example.com", "token": "(encrypted JTW)"}

- Mike

---

From: John Bradley <[email-masked]>
Date: Mon, 14 Mar 2016 16:04:37 -0300

Sorry your first email didn’t mention introspection.

I answered assuming a JWT.

A JWE can have the issuer in the envelope, so the recipient just needs to base64url decode the envelope to see who it issuer was and from that determine where to introspect it.

However if you are introspecting the token why bother making it a JWE, just send a regular JWS with a reference claim in the body that can be looked up by the AS during introspection.    

If you are trying to do stateless introspection then just send a JWE access token containing the required claims and forget the introspection.

John B.

> On Mar 14, 2016, at 1:16 PM, Mike Schwartz <[email-masked]> wrote:
> 
> " 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."
> 
> So the fact that the token is an encrypted JWT is great... the question is: who issued it? That's why I was thinking of a url encoded JWT with the issuer + the encrypted token, such as {"iss": "https://as.example.com", "token": "(encrypted JTW)"}
> 
> - Mike
> 
>