On Sep 15, 2014, at 11:08 PM, Phil Hunt <phil.h...@oracle.com> wrote:
> I’m not sure I understand why this is an OAuth protocol problem? > > If you are starting with a false client with a false registration, everything > down stream is likely invalid. registration is not false. But the client can be a malicious one…. > > This seems like a registration curation (whitelisting) problem. there is not way a whitelist can cover all the malicious uris.. regards antonio > > This is a bit like saying, how can I prove that the application on this > jail-broken phone is legitimate? > > Phil > > @independentid > www.independentid.com > phil.h...@oracle.com > > > > On Sep 15, 2014, at 1:52 PM, Antonio Sanso <asa...@adobe.com> wrote: > >> The problem is that a malicious client can register a malicious redirect uri >> and https://tools.ietf.org/html/rfc6749#section-4.1.2.1 does the rest (as >> previously discussed) >> >> regards >> >> antonio >> >> On Sep 15, 2014, at 10:43 PM, Phil Hunt <phil.h...@oracle.com> wrote: >> >>> If a server accepts a URL from a client to be used as a redirect that the >>> server doesn’t recognize or is not registered, that is an open redirect. >>> >>> The specification does no allow open-redirects, it considers this a >>> mis-configuration. >>> >>> Take a look at sections 3.1.2.2 and 10.15 of RFC6749. >>> >>> Phil >>> >>> @independentid >>> www.independentid.com >>> phil.h...@oracle.com >>> >>> >>> >>> On Sep 15, 2014, at 1:00 PM, John Bradley <ve7...@ve7jtb.com> wrote: >>> >>>> There may be a problem with semantics in this discussion. >>>> >>>> There is a redirect performed by athe authorization endpoint to a fixed >>>> uri that is pre registered with the authorization server without user >>>> prompting. >>>> >>>> That probably doesn't fit the strict definition of a open redirector. >>>> >>>> It may however create similar security issues in situations with >>>> relatively open registration of clients. >>>> >>>> The largest issues are that the browser might leak information across the >>>> redirect in the fragment or referrer. That has been used in attacks >>>> against Facebook in the past. >>>> >>>> This is no where near the end of the world, however we need to look at >>>> the security considerations and see if we can provide better advice to >>>> implementors. In some cases returning a error to the browser may be best. >>>> >>>> >>>> I don't think we need to go so far as not returning any error to the >>>> client under any circumstance. >>>> >>>> John B. >>>> >>>> Sent from my iPhone >>>> >>>>> On Sep 15, 2014, at 4:41 PM, Phil Hunt <phil.h...@oracle.com> wrote: >>>>> >>>>> Simply not true. >>>>> >>>>> Phil >>>>> >>>>> @independentid >>>>> www.independentid.com >>>>> phil.h...@oracle.com >>>>> >>>>> >>>>> >>>>>> On Sep 15, 2014, at 12:10 PM, Antonio Sanso <asa...@adobe.com> wrote: >>>>>> >>>>>> hi *, >>>>>> >>>>>> my understanding is that there is a rough consensus that if an OAuth >>>>>> Provider follows rfc6749 verbatim will end up having an open redirector. >>>>>> My next question would be now, is there anything we can do to raise some >>>>>> awareness about this issue? >>>>>> >>>>>> regards >>>>>> >>>>>> antonio >>>>>> >>>>>>> On Sep 4, 2014, at 3:15 PM, Hans Zandbelt <hzandb...@pingidentity.com> >>>>>>> wrote: >>>>>>> >>>>>>> I am convinced about the issue in the use case Antonio provided but I >>>>>>> hope not to close the door on returning errors to known and trusted >>>>>>> clients. Not sure anymore if that's possible though because the >>>>>>> distinction can't be "registered"... >>>>>>> >>>>>>> Hans. >>>>>>> >>>>>>>> On 9/4/14, 3:01 PM, Antonio Sanso wrote: >>>>>>>> hi Bill >>>>>>>>> On Sep 4, 2014, at 2:52 PM, Bill Burke <bbu...@redhat.com> wrote: >>>>>>>>> >>>>>>>>> FWIW, Antonio convinced me and I'm going to change this in our IDM >>>>>>>>> project. Thanks Antonio. What convinced me was that the user is >>>>>>>>> probably expecting a login screen. Since there is this expectation, >>>>>>>>> it might make it a little easier for the attacker to convince the >>>>>>>>> user that a spoofed login screen is real. I know this issue can only >>>>>>>>> happen with unrestricted registration, but, IMO, this proposed change >>>>>>>>> doesn't really have much of an effect on usability and is even >>>>>>>>> backward compatible with the current RFC. >>>>>>>>> >>>>>>>>> Wouldn't it better though to never do a redirect on an invalid >>>>>>>>> request and just display an error page? >>>>>>>> >>>>>>>> thanks for sharing your thoughts :). Display an error 400 is what >>>>>>>> Google does :) >>>>>>>> >>>>>>>> regards >>>>>>>> >>>>>>>> antonio >>>>>>>> >>>>>>>>> >>>>>>>>>> On 9/4/2014 3:50 AM, Antonio Sanso wrote: >>>>>>>>>> Hi Hans, >>>>>>>>>> >>>>>>>>>> I really fail to see how this can be addressed at registration time >>>>>>>>>> for cases where registration is unrestricted (namely all the big >>>>>>>>>> Providers) >>>>>>>>>> >>>>>>>>>> regards >>>>>>>>>> >>>>>>>>>> antonio >>>>>>>>>> >>>>>>>>>>> On Sep 4, 2014, at 9:47 AM, Hans Zandbelt >>>>>>>>>>> <hzandb...@pingidentity.com> wrote: >>>>>>>>>>> >>>>>>>>>>> Classifying like this must also mean that consent should not be >>>>>>>>>>> stored until the client is considered (admin) trusted, and admin >>>>>>>>>>> policy would interfere with user policy. >>>>>>>>>>> >>>>>>>>>>> IMHO the security consideration would apply only to dynamically >>>>>>>>>>> registered clients where registration is unrestricted; any other >>>>>>>>>>> form would involve some form of admin/user approval at registration >>>>>>>>>>> time, overcoming the concern at authorization time: there's no >>>>>>>>>>> auto-redirect flow possible for unknown clients. >>>>>>>>>>> >>>>>>>>>>> Hans. >>>>>>>>>>> >>>>>>>>>>>> On 9/4/14, 9:04 AM, Richer, Justin P. wrote: >>>>>>>>>>>> I think this advice isn't a bad idea, though it's of course up to >>>>>>>>>>>> the AS >>>>>>>>>>>> what an "untrusted" client really is. In practice, this is >>>>>>>>>>>> something >>>>>>>>>>>> that was registered by a non-sysadmin type person, either a >>>>>>>>>>>> dynamically >>>>>>>>>>>> registered client or something available through self-service >>>>>>>>>>>> registration of some type. It's also reasonable that a client, even >>>>>>>>>>>> dynamically registered, would be considered "trusted" if enough >>>>>>>>>>>> time has >>>>>>>>>>>> passed and enough users have used it without things blowing up. >>>>>>>>>>>> >>>>>>>>>>>> -- Justin >>>>>>>>>>>> >>>>>>>>>>>> On Sep 4, 2014, at 1:26 AM, Antonio Sanso <asa...@adobe.com >>>>>>>>>>>> <mailto:asa...@adobe.com>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> hi again *, >>>>>>>>>>>>> >>>>>>>>>>>>> after thinking a bit further IMHO an alternative for the untrusted >>>>>>>>>>>>> clients can also be to always present the consent screen (at least >>>>>>>>>>>>> once) before any redirect. >>>>>>>>>>>>> Namely all providers I have seen show the consent screen if all >>>>>>>>>>>>> the >>>>>>>>>>>>> request parameters are correct and if the user accepts the >>>>>>>>>>>>> redirect >>>>>>>>>>>>> happens. >>>>>>>>>>>>> If one of the parameter (with the exclusion of the client id and >>>>>>>>>>>>> redirect uri that are handled differently as for spec) is wrong >>>>>>>>>>>>> though >>>>>>>>>>>>> the redirect happens without the consent screen being shown.. >>>>>>>>>>>>> >>>>>>>>>>>>> WDYT? >>>>>>>>>>>>> >>>>>>>>>>>>> regards >>>>>>>>>>>>> >>>>>>>>>>>>> antonio >>>>>>>>>>>>> >>>>>>>>>>>>> On Sep 3, 2014, at 7:54 PM, Antonio Sanso <asa...@adobe.com >>>>>>>>>>>>> <mailto:asa...@adobe.com>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Well, >>>>>>>>>>>>>> I do not know if this is only dynamic registration... >>>>>>>>>>>>>> let’s talk about real use cases, namely e.g. Google , Facebook , >>>>>>>>>>>>>> etc.. is that dynamic client registration? I do not know… :) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Said that what the other guys think? :) >>>>>>>>>>>>>> Would this deserve some “spec adjustment” ? I mean there is a >>>>>>>>>>>>>> reason >>>>>>>>>>>>>> if Google is by choice “violating” the spec right? (I assume to >>>>>>>>>>>>>> avoid >>>>>>>>>>>>>> open redirect…) >>>>>>>>>>>>>> But other implementers do follow the spec hence they have this >>>>>>>>>>>>>> open >>>>>>>>>>>>>> redirector… and this is not nice IMHO... >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sep 3, 2014, at 7:40 PM, Hans Zandbelt >>>>>>>>>>>>>> <hzandb...@pingidentity.com >>>>>>>>>>>>>> <mailto:hzandb...@pingidentity.com>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 9/3/14, 7:14 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Sep 3, 2014, at 7:10 PM, Hans Zandbelt >>>>>>>>>>>>>>>> <hzandb...@pingidentity.com >>>>>>>>>>>>>>>> <mailto:hzandb...@pingidentity.com>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Is your concern clients that were registered using dynamic >>>>>>>>>>>>>>>>> client >>>>>>>>>>>>>>>>> registration? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> yes >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think your issue is then with the trust model of dynamic >>>>>>>>>>>>>>> client >>>>>>>>>>>>>>> registration; that is left out of scope of the dynreg spec (and >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>> concept is not even part of the core spec), but unless you want >>>>>>>>>>>>>>> everything to be open (which typically would not be the case), >>>>>>>>>>>>>>> then >>>>>>>>>>>>>>> it would involve approval somewhere in the process before the >>>>>>>>>>>>>>> client >>>>>>>>>>>>>>> is registered. Without dynamic client registration that >>>>>>>>>>>>>>> approval is >>>>>>>>>>>>>>> admin based or resource owner based, depending on use case. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Otherwise the positive case is returning a response to a >>>>>>>>>>>>>>>>> valid URL >>>>>>>>>>>>>>>>> that belongs to a client that was registered explicitly by the >>>>>>>>>>>>>>>>> resource owner >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> well AFAIK the resource owner doesn’t register clients… >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> roles can collapse in use cases especially when using dynamic >>>>>>>>>>>>>>> client >>>>>>>>>>>>>>> registration >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> and the negative case is returning an error to that same URL. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> the difference is the consent screen… in the positive case you >>>>>>>>>>>>>>>> need >>>>>>>>>>>>>>>> to approve an app.. for the error case no approval is needed,,, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I fail to see the open redirect. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> why? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> because the client and thus the fixed URL are explicitly >>>>>>>>>>>>>>> approved at >>>>>>>>>>>>>>> some point >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 9/3/14, 6:56 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:51 PM, Hans Zandbelt >>>>>>>>>>>>>>>>>> <hzandb...@pingidentity.com >>>>>>>>>>>>>>>>>> <mailto:hzandb...@pingidentity.com> >>>>>>>>>>>>>>>>>> <mailto:hzandb...@pingidentity.com>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Let me try and approach this from a different angle: why >>>>>>>>>>>>>>>>>>> would you >>>>>>>>>>>>>>>>>>> call it an open redirect when an invalid scope is provided >>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>> call it >>>>>>>>>>>>>>>>>>> correct protocol behavior (hopefully) when a valid scope is >>>>>>>>>>>>>>>>>>> provided? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> as specified below in the positive case (namely when the >>>>>>>>>>>>>>>>>> correct >>>>>>>>>>>>>>>>>> scope >>>>>>>>>>>>>>>>>> is provided) the resource owner MUST approve the app via the >>>>>>>>>>>>>>>>>> consent >>>>>>>>>>>>>>>>>> screen (at least once). >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hans. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 9/3/14, 6:46 PM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>> hi John, >>>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 6:14 PM, John Bradley <ve7...@ve7jtb.com >>>>>>>>>>>>>>>>>>>> <mailto:ve7...@ve7jtb.com> >>>>>>>>>>>>>>>>>>>> <mailto:ve7...@ve7jtb.com> >>>>>>>>>>>>>>>>>>>> <mailto:ve7...@ve7jtb.com>> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> In the example the redirect_uri is vlid for the attacker. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> The issue is that the AS may be allowing client >>>>>>>>>>>>>>>>>>>>> registrations with >>>>>>>>>>>>>>>>>>>>> arbitrary redirect_uri. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> In the spec it is unspecified how a AS validates that a >>>>>>>>>>>>>>>>>>>>> client >>>>>>>>>>>>>>>>>>>>> controls the redirect_uri it is registering. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I think that if anything it may be the registration step >>>>>>>>>>>>>>>>>>>>> that >>>>>>>>>>>>>>>>>>>>> needs >>>>>>>>>>>>>>>>>>>>> the security consideration. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> (this is the first time :p) but I do disagree with you. It >>>>>>>>>>>>>>>>>>>> would be >>>>>>>>>>>>>>>>>>>> pretty unpractical to block this at registration time…. >>>>>>>>>>>>>>>>>>>> IMHO the best approach is the one taken from Google, namely >>>>>>>>>>>>>>>>>>>> returning >>>>>>>>>>>>>>>>>>>> 400 with the cause of the error.. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> *400.* That’s an error. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> *Error: invalid_scope* >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Some requested scopes were invalid. {invalid=[l]} >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> said that I hope you all agree this is an issue in the >>>>>>>>>>>>>>>>>>>> spec so >>>>>>>>>>>>>>>>>>>> far…. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> John B. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Sep 3, 2014, at 12:10 PM, Bill Burke <bbu...@redhat.com >>>>>>>>>>>>>>>>>>>>> <mailto:bbu...@redhat.com> >>>>>>>>>>>>>>>>>>>>> <mailto:bbu...@redhat.com> >>>>>>>>>>>>>>>>>>>>> <mailto:bbu...@redhat.com>> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I don't understand. The redirect uri has to be valid in >>>>>>>>>>>>>>>>>>>>>> order for a >>>>>>>>>>>>>>>>>>>>>> redirect to happen. The spec explicitly states this. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On 9/3/2014 11:43 AM, Antonio Sanso wrote: >>>>>>>>>>>>>>>>>>>>>>> hi *, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> IMHO providers that strictly follow rfc6749 are >>>>>>>>>>>>>>>>>>>>>>> vulnerable >>>>>>>>>>>>>>>>>>>>>>> to open >>>>>>>>>>>>>>>>>>>>>>> redirect. >>>>>>>>>>>>>>>>>>>>>>> Let me explain, reading [0] >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> If the request fails due to a missing, invalid, or >>>>>>>>>>>>>>>>>>>>>>> mismatching >>>>>>>>>>>>>>>>>>>>>>> redirection URI, or if the client identifier is missing >>>>>>>>>>>>>>>>>>>>>>> or >>>>>>>>>>>>>>>>>>>>>>> invalid, >>>>>>>>>>>>>>>>>>>>>>> the authorization server SHOULD inform the resource >>>>>>>>>>>>>>>>>>>>>>> owner of the >>>>>>>>>>>>>>>>>>>>>>> error and MUST NOT automatically redirect the >>>>>>>>>>>>>>>>>>>>>>> user-agent to the >>>>>>>>>>>>>>>>>>>>>>> invalid redirection URI. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> If the resource owner denies the access request or if >>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>> request >>>>>>>>>>>>>>>>>>>>>>> fails for reasons other than a missing or invalid >>>>>>>>>>>>>>>>>>>>>>> redirection URI, >>>>>>>>>>>>>>>>>>>>>>> the authorization server informs the client by adding >>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>>>>>>>> parameters to the query component of the redirection URI >>>>>>>>>>>>>>>>>>>>>>> using the >>>>>>>>>>>>>>>>>>>>>>> "application/x-www-form-urlencoded" format, perAppendix >>>>>>>>>>>>>>>>>>>>>>> B >>>>>>>>>>>>>>>>>>>>>>> <https://tools.ietf.org/html/rfc6749#appendix-B>: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Now let’s assume this. >>>>>>>>>>>>>>>>>>>>>>> I am registering a new client to thevictim.com >>>>>>>>>>>>>>>>>>>>>>> <http://thevictim.com/> >>>>>>>>>>>>>>>>>>>>>>> <http://victim.com/><http://victim.com >>>>>>>>>>>>>>>>>>>>>>> <http://victim.com/> >>>>>>>>>>>>>>>>>>>>>>> <http://victim.com/>> >>>>>>>>>>>>>>>>>>>>>>> <http://victim.com <http://victim.com/> >>>>>>>>>>>>>>>>>>>>>>> <http://victim.com/>> >>>>>>>>>>>>>>>>>>>>>>> provider. >>>>>>>>>>>>>>>>>>>>>>> I register redirect uriattacker.com >>>>>>>>>>>>>>>>>>>>>>> <http://uriattacker.com/> >>>>>>>>>>>>>>>>>>>>>>> <http://attacker.com/><http://attacker.com >>>>>>>>>>>>>>>>>>>>>>> <http://attacker.com/> <http://attacker.com/>> >>>>>>>>>>>>>>>>>>>>>>> <http://attacker.com <http://attacker.com/> >>>>>>>>>>>>>>>>>>>>>>> <http://attacker.com/>>. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> According to [0] if I pass e.g. the wrong scope I am >>>>>>>>>>>>>>>>>>>>>>> redirected >>>>>>>>>>>>>>>>>>>>>>> back to >>>>>>>>>>>>>>>>>>>>>>> attacker.com <http://attacker.com/> >>>>>>>>>>>>>>>>>>>>>>> <http://attacker.com/><http://attacker.com >>>>>>>>>>>>>>>>>>>>>>> <http://attacker.com/> >>>>>>>>>>>>>>>>>>>>>>> <http://attacker.com/>> <http://attacker.com >>>>>>>>>>>>>>>>>>>>>>> <http://attacker.com/> <http://attacker.com/>>. >>>>>>>>>>>>>>>>>>>>>>> Namely I prepare a url that is in this form: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> and this is works as an open redirector. >>>>>>>>>>>>>>>>>>>>>>> Of course in the positive case if all the parameters are >>>>>>>>>>>>>>>>>>>>>>> fine this >>>>>>>>>>>>>>>>>>>>>>> doesn’t apply since the resource owner MUST approve the >>>>>>>>>>>>>>>>>>>>>>> app >>>>>>>>>>>>>>>>>>>>>>> via the >>>>>>>>>>>>>>>>>>>>>>> consent screen (at least once). >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> A solution would be to return error 400 rather than >>>>>>>>>>>>>>>>>>>>>>> redirect >>>>>>>>>>>>>>>>>>>>>>> to the >>>>>>>>>>>>>>>>>>>>>>> redirect URI (as some provider e.g. Google do) >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> WDYT? >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> regards >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> antonio >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> [0] https://tools.ietf.org/html/rfc6749#section-4.1.2.1 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>> Bill Burke >>>>>>>>>>>>>>>>>>>>>> JBoss, a division of Red Hat >>>>>>>>>>>>>>>>>>>>>> http://bill.burkecentral.com >>>>>>>>>>>>>>>>>>>>>> <http://bill.burkecentral.com/> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>>>>>>>>>>>>>>>>>> <mailto:OAuth@ietf.org> >>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>>>>>>>>>>>>>>>>> <mailto:OAuth@ietf.org><mailto:OAuth@ietf.org> >>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>>>>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>>>>>>>>>>>>>>>> <mailto:OAuth@ietf.org> >>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>>>>> hzandb...@pingidentity.com >>>>>>>>>>>>>>>>>>> <mailto:hzandb...@pingidentity.com> >>>>>>>>>>>>>>>>>>> <mailto:hzandb...@pingidentity.com>| Ping >>>>>>>>>>>>>>>>>>> Identity >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>>>> hzandb...@pingidentity.com >>>>>>>>>>>>>>>>> <mailto:hzandb...@pingidentity.com> | >>>>>>>>>>>>>>>>> Ping Identity >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>>>>>> hzandb...@pingidentity.com <mailto:hzandb...@pingidentity.com>| >>>>>>>>>>>>>>> Ping >>>>>>>>>>>>>>> Identity >>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> OAuth mailing list >>>>>>>>>>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>>>>>> hzandb...@pingidentity.com | Ping Identity >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> OAuth mailing list >>>>>>>>>> OAuth@ietf.org >>>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Bill Burke >>>>>>>>> JBoss, a division of Red Hat >>>>>>>>> http://bill.burkecentral.com >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> OAuth@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> OAuth@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>> >>>>>>> -- >>>>>>> Hans Zandbelt | Sr. Technical Architect >>>>>>> hzandb...@pingidentity.com | Ping Identity >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> OAuth@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> OAuth@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/oauth >>> >> > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
