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
