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] Working Group Last Call on OAuth 2.0 Discovery

On Sat, Mar 12, 2016 at 6:01 PM Anthony Nadalin wrote: > This is not discovery, its simply metadata, […], I don’t understand the > rush to get this document out when we already know it’s incomplete > +1 ___ OAuth mailing list OAuth@ietf.org https://www.

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] Working Group Last Call on OAuth 2.0 Discovery

I will put that forward in an alternate draft. Phil > On Mar 12, 2016, at 08:28, Mike Jones wrote: > > The AS metadata format is a necessary part of discovery. No, it doesn’t > accomplish every possible aspect of discovery – nor was it ever intended to. > I’ve consistently encouraged Phil

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] Working Group Last Call on OAuth 2.0 Discovery

This is not discovery, its simply metadata, it’s unclear if this is all the metadata that is needed because discovery has not been fully thought out as apparent from all the exchanges that have been going on, I don’t understand the rush to get this document out when we already know it’s incompl

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 _

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

The AS metadata format is a necessary part of discovery. No, it doesn’t accomplish every possible aspect of discovery – nor was it ever intended to. I’ve consistently encouraged Phil and others to write down additional aspects of discovery in specifications that build upon this one so that the

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

We agreed upon a discovery specification that the WG would work on, we did not agree upon what this has turned out to actually be, so at the minimum the chairs should call for adoption of a Authorization Server Metadata specification and we can continue to work on a Discovery specification From

Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Discovery

The draft enables easy configuration of OAuth clients with an AS. For instance, the Microsoft “ADAL” OAuth client software uses AS metadata in this format as an input at client configuration time. As a side benefit, having this standard AS metadata format and returning the issuer URL per the M