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

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

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

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

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

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 a

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

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 t

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

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, sc

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

On Sun, Mar 13, 2016 at 2:03 AM Justin Richer wrote: > 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.

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

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.

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

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": "fjbfgy5F

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

The question is about how RS can find the issuer from a bearer token that it received from the client. Obviously, a header from the AS does not work. We would have to have some kind of structured token. It can be a JWS or something proprietary to the trust framework. Note: the client is untrusted

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

Agree with Phil, an additional header is a bad idea. It's not only yet another thing that can be attacked, it's another thing that can get out of sync by the client. Always assume OAuth clients are the dumbest parts of the system. -- Justin On 3/12/2016 2:36 PM, Phil Hunt (IDM) wrote: Right

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

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

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

Right now we are discussing mis-configured clients that have been convinced to use a token or rs endpoint that has been mitm. Adding a new parameter increases attack surface because the rs is now ignoring the token abd believing the header which may have been inserted. Phil > On Mar 12, 2016,

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

Would a header be a concern if TLS was used for transportation? -- -jim Jim Willeke On Sat, Mar 12, 2016 at 10:03 AM, Phil Hunt (IDM) wrote: > A header might open another attack vector. Better to parse the jwt and > look for the issuer assuming the jwt validates. > > Phil > > On Mar 12, 2016, a

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

A header might open another attack vector. Better to parse the jwt and look for the issuer assuming the jwt validates. Phil > On Mar 12, 2016, at 09:02, Jim Willeke wrote: > > Why not register JWT as an access token type and then the the Issuer is > implied? > > -- > -jim > Jim Willeke > >

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

Why not register JWT as an access token type and then the the Issuer is implied? -- -jim Jim Willeke On Sat, Mar 12, 2016 at 8:32 AM, Mike Schwartz wrote: > Kawasaki-san, > > This is a really good question: h

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

Kawasaki-san, This is a really good question: how to know the issuer of a bearer token. Is there a header that could be added to specify the issuer, or other important metadata? - Mike - Michael Schwartz Gluu Founder / CEO m...@gluu.org _

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

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