Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

I think Phil and others are concerned that a developer might get bad info to put in the client , some out of band discovery goes wrong or the user is somehow tricked into specifying a bad resource to the client. So getting a bad resource is a touch hypothetical. For Connect we could suppose th

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

Yes, I agree the level of indirection starts us down the road to discovery... but if we want the audience binding it's a road I feel we have to traverse. The other option creates too tight a coupling in my mind. On 3/15/16 1:43 PM, John Bradley wrote: I am trying to support multiple audiences i

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

I think it is a AS policy decision if it should error or take the requested resource and issue a token audianced for that resource. I guess the question is how to transition from now to a future state. If you cannot upgrade all the clients at once. A processing rule on the AS that allowed som

Re: [OAUTH-WG] Client Credentials flow and Client Registrations

Sorry, On 15/03/16 17:51, Sergey Beryozkin wrote: Hi Justin AFAIK many Java JAAS systems, etc have things like "username", "password" set in various properties files, etc, and often these are really "client_id", "client_secret" in that these are not meant to support a direct authentication betw

Re: [OAUTH-WG] Client Credentials flow and Client Registrations

Hi Justin AFAIK many Java JAAS systems, etc have things like "username", "password" set in various properties files, etc, and often these are really "client_id", "client_secret" in that these are not meant to support a direct authentication between some command line client and this server.

Re: [OAUTH-WG] When does RS not require token introspection ?

On Tue, Mar 15, 2016 at 6:23 PM Justin Richer wrote: > +1 to all of this. > > Our reasoning for the JWT+introspection was to allow for an RS to take in > tokens from multiple AS, by looking up the issuer in the JWT itself. > But then, as I said, you need the AS to "cooperate" by making their ATs

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

I was thinking it'd be simpler to error, if the requested resource(s) weren't okay. That puts the burden of checking in the AS. And doesn't add anything to the token or authorization response. I see the potential similarity to scope but not sure it's worth it. On Tue, Mar 15, 2016 at 11:37 AM, Joh

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

I am trying to support multiple audiences in a token. We are agreed on that. The problem with having a abstract audience is how a client would verify the RS URI is correct. If we wanted abstract Audience could be a HTTPS URI with only host component, or a Fully qualified URI that can be re

Re: [OAUTH-WG] When does RS not require token introspection ?

Hi Thomas Yes, we currently only support 'small' tokens with the introspection and the local caching (though not time but size based which is not ideal if we talk about the revocations, though in a high end servers that should still invalidate the cache fast enough). But that does not support

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

If the client specifies the resource it wants the token for, then the meta-data would not be required unless the resources the token is good at are different from the request. Lat is the same logic as scopes. For backwards compatibility if the client is happy with the default resources based

Re: [OAUTH-WG] When does RS not require token introspection ?

While I understand the desire for small tokens, we chose JWT as a wrapper for the external AS opaque token so that we would have a generic implementation that can be expanded to additional partners without affecting our implementation. You could assign each AS in a multiple AS closed environme

Re: [OAUTH-WG] When does RS not require token introspection ?

+1 to all of this. Our reasoning for the JWT+introspection was to allow for an RS to take in tokens from multiple AS, by looking up the issuer in the JWT itself. — Justin > On Mar 15, 2016, at 12:34 PM, Thomas Broyer wrote: > > > > On Tue, Mar 15, 2016 at 2:02 PM Sergey Beryozkin

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

I'm less concerned about making the mitigation choice the AS's because to prevent the leaking of tokens you need a "good" client in both cases. An evil client can still request a token correctly and then send it to an evil RS. If a client that "does the right thing" is required, then I don't s

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

Pushing documents such as AS metadata because Connect uses them does not help anything but muddies the water, Metadata is not a solution to Mix-up and Metadata is not a solution to Discovery, both Discovery and Mix-up are problems we need and agreed to fix. So I totally agree that we should not

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

Thanks George I think we have to discuss cases where mitigstion is not needed such as oidc. My concern is to make the mitigation choice the AS's and not the client. Phil > On Mar 15, 2016, at 09:01, George Fletcher wrote: > > I understand the benefit of having the client specify where it wa

Re: [OAUTH-WG] When does RS not require token introspection ?

On Tue, Mar 15, 2016 at 2:02 PM Sergey Beryozkin wrote: > Hi > > After following the recent thread on multiple authorization servers, but > also reading some other related threads, I have a question related to > when the token introspection can be avoided. > > My understanding has been that given

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

I understand the benefit of having the client specify where it wants to present the token. However, in general, the client knows which kind of resource it's going to connect to (even if it doesn't know the exact endpoint). For example, if the client speaks PortableContacts, then it can potentia

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

Regarding 2. The bound config spec makes no such requirement of knowing the and its path structure. If you feel that you have other security measures and that clients will always have the proper AS, then you can wildcard the whole resource parameter. It still might be advisable to at least

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

I'm not against binding audiences to a token. (Note that in many deployments today, a single access token can be used at many endpoints representing different services. It's not uncommon for a client to request a token to access the mail endpoints, messaging endpoints, contacts endpoints, etc.

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

If the client specifies the desired audience(s)/resource(s), is that metadata to the client needed? The AS can audience restrict the token as needed or respond with an error if it can't or wont issue a token for the resource the client asked for. On Tue, Mar 15, 2016 at 9:37 AM, John Bradley wrot

Re: [OAUTH-WG] Client Credentials flow and Client Registrations

So long as you’re storing the client_id and client_secret in your LDAP and not putting a username and password (that normally represents a person) into the software, you’re fine. That’s just a case of externalizing the client registration to the LDAP system — it’s still registered. Otherwise,

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

Yes, I think bearer tokens with no audience are a bad idea. The AS needs to infer an audience from the scopes snd/or have the client specify the desired audience. If the AT has a audience or audiences then as long as the endpoint URI are provided as meta-data with the token, the client can det

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

I worry about two directions I see in this thread... 1. Client's accessing resources dynamically so that discovery is required to know the correct AS, etc. This is pretty much the classic use case for UMA and I'd rather not re-invent the wheel. 2. Creating a tight coupling between RS and AS s

Re: [OAUTH-WG] New Version Notification for draft-hunt-oauth-bound-config-00.txt

Discovery in general for OAuth isn't well understood. This conversation and others like it around the 'discovery' draft demonstrate that. But publishing AS metadata is something that is understood and already in wide use for Connect. The rough consensus (except for a very few but vocal dissenters)

Re: [OAUTH-WG] When does RS not require token introspection ?

We have also implemented option 3. In our case, the RS is supporting our own AS and an external trusted AS. The hybrid JWT allows us to know where to validate the token and also allows the external AS to protect it's token in a way that is not visible to us. Thanks, George On 3/15/16 9:12 AM,

Re: [OAUTH-WG] When does RS not require token introspection ?

One of the things JWT allows is interoperable access tokens from multiple AS. The OAuth specs have always been a bit hand-wavy about access tokens saying that they are a local implementation decision. You can use JWT or introspection or a database lookup, but leave it to the implementation t

Re: [OAUTH-WG] When does RS not require token introspection ?

Hi Justin I guess it depends on what the customer requirements are, with the AS vendor neutrality being one of the variables - something that we had to deal with recently. Or if the RS stack is flexible in a way that it can be easily adapted to work with AS from multiple vendors. I can see how

Re: [OAUTH-WG] When does RS not require token introspection ?

Hi Justin It does help, thanks, I was really meaning to ask whether RS was able to parse it or not itself, without getting the external introspection support, but using a wrong term, 'opaque' for it :-). Thanks Sergey On 15/03/16 13:33, Justin Richer wrote: Hi Sergey, one comment inline On

Re: [OAUTH-WG] When does RS not require token introspection ?

On 3/15/2016 9:35 AM, Sergey Beryozkin wrote: Hi Justin On 15/03/16 13:18, Justin Richer wrote: And don't forget option 4: look it up in a database because the RS and AS are in the same box. Sometimes I feel like I understand OAuth2 and today I'm feeling like I've no idea what it is :-). A

Re: [OAUTH-WG] When does RS not require token introspection ?

Hi Justin On 15/03/16 13:18, Justin Richer wrote: And don't forget option 4: look it up in a database because the RS and AS are in the same box. Sometimes I feel like I understand OAuth2 and today I'm feeling like I've no idea what it is :-). Are AS and RS meant to be collocated ? I thought

Re: [OAUTH-WG] When does RS not require token introspection ?

Hi Sergey, one comment inline On 3/15/2016 9:31 AM, Sergey Beryozkin wrote: Hi John, Justin On 15/03/16 13:12, John Bradley wrote: Access tokens are opaque to the client not the RS. But only if they are self-contained as in the option 1 below, right ? No. They're non-opaque to the RS in all

Re: [OAUTH-WG] When does RS not require token introspection ?

Hi John, Justin On 15/03/16 13:12, John Bradley wrote: Access tokens are opaque to the client not the RS. But only if they are self-contained as in the option 1 below, right ? You have three basic design choices. 1 Use a token that the RS can locally validate. JWT or SAML are standard option

Re: [OAUTH-WG] Client Credentials flow and Client Registrations

Hi John On 15/03/16 13:05, John Bradley wrote: I think you may be confusing Client credentials flow with resource owner credentials flow. Sorry, I should've clarified initially, it is a piece of software that needs to run without a human user. So I hope it is still client_credentials. If th

Re: [OAUTH-WG] When does RS not require token introspection ?

And don't forget option 4: look it up in a database because the RS and AS are in the same box. -- Justin On 3/15/2016 9:12 AM, John Bradley wrote: Access tokens are opaque to the client not the RS. You have three basic design choices. 1 Use a token that the RS can locally validate. JWT or S

Re: [OAUTH-WG] Client Credentials flow and Client Registrations

Hi Justin Many thanks for the quick response. On 15/03/16 12:53, Justin Richer wrote: Is Alice the client here (the piece of software), or is Alice the resource owner? Piece of software, something that needs to run without the human user being involved If Alice is the resource owner, then you

Re: [OAUTH-WG] When does RS not require token introspection ?

Access tokens are opaque to the client not the RS. You have three basic design choices. 1 Use a token that the RS can locally validate. JWT or SAML are standard options or you could do your own custom format and use a HMAC to integrity protect them. If using astandard token format this support

Re: [OAUTH-WG] When does RS not require token introspection ?

The access tokens are opaque to the client, not the RS. -- Justin On 3/15/2016 9:01 AM, Sergey Beryozkin wrote: Hi After following the recent thread on multiple authorization servers, but also reading some other related threads, I have a question related to when the token introspection can

Re: [OAUTH-WG] Client Credentials flow and Client Registrations

I think you may be confusing Client credentials flow with resource owner credentials flow. If there is a resource owner in the flow use code. The resource owner credentials flow is a bad idea and only put in for backwards compatibility. John B. > On Mar 15, 2016, at 9:37 AM, Sergey Beryozkin

[OAUTH-WG] When does RS not require token introspection ?

Hi After following the recent thread on multiple authorization servers, but also reading some other related threads, I have a question related to when the token introspection can be avoided. My understanding has been that given that access tokens are opaque the RS does not know anything abou

Re: [OAUTH-WG] Client Credentials flow and Client Registrations

Is Alice the client here (the piece of software), or is Alice the resource owner? If Alice is the resource owner, then you should absolutely not be using the client credentials flow like this. The client credentials flow is designed for cases where the client is acting on its own behalf, not o

[OAUTH-WG] Client Credentials flow and Client Registrations

Hi All I've alway been thinking of Client Credentials as being the simplest flow but now that I'm looking at implementing it myself to be used in the real productions, I'm realizing that there's something I do not understand about it: Do the clients using Client Credentials flow need to be