I am trying to develop OAuth 2.0 server that will use internal user authentication and authorization of the client application. In order to check the server I am using OAuthConsumerWpf application provided with the samples.
Everything working just fine until the last stage of the returning the auth token back to client. The client sends returnUrl to be http://localhost/and then after the process of user authentication and authorization finishes, the server redirects the response. The log of the server produces the following:
WebDev.WebServer40.exe Information: 0 : Incoming request received: EndUserAuthorizationRequest WebDev.WebServer40.exe Information: 0 : Binding element DotNetOpenAuth.OAuth2.ChannelElements.TokenCodeSerializationBindingElement did not apply to message. WebDev.WebServer40.exe Information: 0 : Binding element DotNetOpenAuth.OAuth2.ChannelElements.MessageValidationBindingElement applied to message. WebDev.WebServer40.exe Information: 0 : Preparing to send EndUserAuthorizationSuccessAuthCodeResponseAS (2.0) message. WebDev.WebServer40.exe Information: 0 : Binding element DotNetOpenAuth.OAuth2.ChannelElements.MessageValidationBindingElement did not apply to message. WebDev.WebServer40.exe Information: 0 : DotNetOpenAuth.Messaging.Bindings.ICryptoKeyStore.GetKeys returned no keys for bucket "https://localhost/dnoa/oauth_authorization_code" with the required key length of 256 bits. A new key will be created WebDev.WebServer40.exe Information: 0 : Binding element DotNetOpenAuth.OAuth2.ChannelElements.TokenCodeSerializationBindingElement applied to message. WebDev.WebServer40.exe Information: 0 : Sending message: EndUserAuthorizationSuccessAuthCodeResponseAS WebDev.WebServer40.exe Information: 0 : Redirecting to http://localhost/?code=E7dl%21IAAAAJl4CfH60tn5k5PONt4tDaXMg_WOjIOSyEB...
The problem is that no one listens on the port 80, thus the ClientAuthorizationView embedded in the dialog fails to navigate to the specified URL. As far as I understand it, I have no control in the OAuthConsumerWpfon the returnUrl parameter without changing the code of the client.
Please advice what am I missing and what should be done to fix it.
Are you trying to use OAuth2 in the context of a desktop application?
If so then you have two main options, have the desktop app rely on a
regular web app to do the token exchange, that way you can use the default
way of exchanging codes/tokens, but this means that you need a secure way
of transferring the token from the server to the app.
The other option is to use the 'native application' profile as described in
http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-9 combined with
the 'implicit grant' (
http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-4.2) where you
end up reading the access token out of the user agent in your application.
Remember, as long as you control the user agent in the application it
doesn't really matter that the redirect_url is not available - you will
still be able to access the url navigated to in order to extract the needed
data.
On Mon, Jul 2, 2012 at 2:53 AM, Vadim D. <vadi...@gmail.com> wrote:
> Hi,
> I am trying to develop OAuth 2.0 server that will use internal user
> authentication and authorization of the client application.
> In order to check the server I am using OAuthConsumerWpf application
> provided with the samples.
> Everything working just fine until the last stage of the returning the
> auth token back to client. The client sends returnUrl to be
> http://localhost/ and then after the process of user authentication and
> authorization finishes, the server redirects the response.
> The log of the server produces the following:
> WebDev.WebServer40.exe Information: 0 : Incoming request received:
> EndUserAuthorizationRequest
> WebDev.WebServer40.exe Information: 0 : Binding element
> DotNetOpenAuth.OAuth2.ChannelElements.TokenCodeSerializationBindingElement
> did not apply to message.
> WebDev.WebServer40.exe Information: 0 : Binding element
> DotNetOpenAuth.OAuth2.ChannelElements.MessageValidationBindingElement
> applied to message.
> WebDev.WebServer40.exe Information: 0 : Preparing to send
> EndUserAuthorizationSuccessAuthCodeResponseAS (2.0) message.
> WebDev.WebServer40.exe Information: 0 : Binding element
> DotNetOpenAuth.OAuth2.ChannelElements.MessageValidationBindingElement did
> not apply to message.
> WebDev.WebServer40.exe Information: 0 :
> DotNetOpenAuth.Messaging.Bindings.ICryptoKeyStore.GetKeys returned no keys
> for bucket "https://localhost/dnoa/oauth_authorization_code" with the
> required key length of 256 bits. A new key will be created
> WebDev.WebServer40.exe Information: 0 : Binding element
> DotNetOpenAuth.OAuth2.ChannelElements.TokenCodeSerializationBindingElement
> applied to message.
> WebDev.WebServer40.exe Information: 0 : Sending message:
> EndUserAuthorizationSuccessAuthCodeResponseAS
> WebDev.WebServer40.exe Information: 0 : Redirecting to
> http://localhost/?code=E7dl%21IAAAAJl4CfH60tn5k5PONt4tDaXMg_WOjIOSyEB...
> The problem is that no one listens on the port 80, thus the
> ClientAuthorizationView embedded in the dialog fails to navigate to the
> specified URL. As far as I understand it, I have no control in the
> OAuthConsumerWpfon the returnUrl parameter without changing the code of the
> client.
> Please advice what am I missing and what should be done to fix it.
> Thanks in advance
> Vadim
> --
> You received this message because you are subscribed to the Google Groups
> "DotNetOpenAuth" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/dotnetopenid/-/SpsA_VganOIJ.
> To post to this group, send email to dotnetopenid@googlegroups.com.
> To unsubscribe from this group, send email to
> dotnetopenid+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/dotnetopenid?hl=en.
Actually the authorization code grant type is an option for native clients,
and I still prefer that approach. But I think it requires that the native
app set up its own client account with the authorization server, which is
outside the scope of the spec but certainly something that could be done
using DNOA.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre
On Mon, Jul 2, 2012 at 9:11 AM, Øyvind Sean Kinsey <oyv...@kinsey.no> wrote:
> Are you trying to use OAuth2 in the context of a desktop application?
> If so then you have two main options, have the desktop app rely on a
> regular web app to do the token exchange, that way you can use the default
> way of exchanging codes/tokens, but this means that you need a secure way
> of transferring the token from the server to the app.
> The other option is to use the 'native application' profile as described
> in http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-9 combined
> with the 'implicit grant' (
> http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-4.2) where you
> end up reading the access token out of the user agent in your application.
> Remember, as long as you control the user agent in the application it
> doesn't really matter that the redirect_url is not available - you will
> still be able to access the url navigated to in order to extract the needed
> data.
> Øyvind Sean Kinsey
> San Francisco, CA
> On Mon, Jul 2, 2012 at 2:53 AM, Vadim D. <vadi...@gmail.com> wrote:
>> Hi,
>> I am trying to develop OAuth 2.0 server that will use internal user
>> authentication and authorization of the client application.
>> In order to check the server I am using OAuthConsumerWpf application
>> provided with the samples.
>> Everything working just fine until the last stage of the returning the
>> auth token back to client. The client sends returnUrl to be
>> http://localhost/ and then after the process of user authentication and
>> authorization finishes, the server redirects the response.
>> The log of the server produces the following:
>> WebDev.WebServer40.exe Information: 0 : Incoming request received:
>> EndUserAuthorizationRequest
>> WebDev.WebServer40.exe Information: 0 : Binding element
>> DotNetOpenAuth.OAuth2.ChannelElements.TokenCodeSerializationBindingElement
>> did not apply to message.
>> WebDev.WebServer40.exe Information: 0 : Binding element
>> DotNetOpenAuth.OAuth2.ChannelElements.MessageValidationBindingElement
>> applied to message.
>> WebDev.WebServer40.exe Information: 0 : Preparing to send
>> EndUserAuthorizationSuccessAuthCodeResponseAS (2.0) message.
>> WebDev.WebServer40.exe Information: 0 : Binding element
>> DotNetOpenAuth.OAuth2.ChannelElements.MessageValidationBindingElement did
>> not apply to message.
>> WebDev.WebServer40.exe Information: 0 :
>> DotNetOpenAuth.Messaging.Bindings.ICryptoKeyStore.GetKeys returned no keys
>> for bucket "https://localhost/dnoa/oauth_authorization_code" with the
>> required key length of 256 bits. A new key will be created
>> WebDev.WebServer40.exe Information: 0 : Binding element
>> DotNetOpenAuth.OAuth2.ChannelElements.TokenCodeSerializationBindingElement
>> applied to message.
>> WebDev.WebServer40.exe Information: 0 : Sending message:
>> EndUserAuthorizationSuccessAuthCodeResponseAS
>> WebDev.WebServer40.exe Information: 0 : Redirecting to
>> http://localhost/?code=E7dl%21IAAAAJl4CfH60tn5k5PONt4tDaXMg_WOjIOSyEB...
>> The problem is that no one listens on the port 80, thus the
>> ClientAuthorizationView embedded in the dialog fails to navigate to the
>> specified URL. As far as I understand it, I have no control in the
>> OAuthConsumerWpfon the returnUrl parameter without changing the code of the
>> client.
>> Please advice what am I missing and what should be done to fix it.
>> Thanks in advance
>> Vadim
>> --
>> You received this message because you are subscribed to the Google Groups
>> "DotNetOpenAuth" group.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msg/dotnetopenid/-/SpsA_VganOIJ.
>> To post to this group, send email to dotnetopenid@googlegroups.com.
>> To unsubscribe from this group, send email to
>> dotnetopenid+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/dotnetopenid?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "DotNetOpenAuth" group.
> To post to this group, send email to dotnetopenid@googlegroups.com.
> To unsubscribe from this group, send email to
> dotnetopenid+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/dotnetopenid?hl=en.
This also requires some extra work at the Authorization Server right? Not
all AS have facilities for 'out of bound' authorization, but if it does or
you are the one building it, then using the code grant is absolutely worth
it.
- Sean
On Mon, Jul 2, 2012 at 9:51 AM, Andrew Arnott <andrewarn...@gmail.com>wrote:
> Actually the authorization code grant type is an option for native
> clients, and I still prefer that approach. But I think it requires that
> the native app set up its own client account with the authorization server,
> which is outside the scope of the spec but certainly something that could
> be done using DNOA.
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death
> your right to say it." - S. G. Tallentyre
> On Mon, Jul 2, 2012 at 9:11 AM, Øyvind Sean Kinsey <oyv...@kinsey.no>wrote:
>> Are you trying to use OAuth2 in the context of a desktop application?
>> If so then you have two main options, have the desktop app rely on a
>> regular web app to do the token exchange, that way you can use the default
>> way of exchanging codes/tokens, but this means that you need a secure way
>> of transferring the token from the server to the app.
>> The other option is to use the 'native application' profile as described
>> in http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-9 combined
>> with the 'implicit grant' (
>> http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-4.2) where you
>> end up reading the access token out of the user agent in your application.
>> Alternatively, you implement an extension that lets you retrieve the
>> token in some other way, eg by using verification codes manually inputted
>> by the user and so on. An example of this can be found in
>> https://github.com/AArnott/dotnetopenid/tree/v4.1/samples/OAuthConsum... >> .
>> Remember, as long as you control the user agent in the application it
>> doesn't really matter that the redirect_url is not available - you will
>> still be able to access the url navigated to in order to extract the needed
>> data.
>> Øyvind Sean Kinsey
>> San Francisco, CA
>> On Mon, Jul 2, 2012 at 2:53 AM, Vadim D. <vadi...@gmail.com> wrote:
>>> Hi,
>>> I am trying to develop OAuth 2.0 server that will use internal user
>>> authentication and authorization of the client application.
>>> In order to check the server I am using OAuthConsumerWpf application
>>> provided with the samples.
>>> Everything working just fine until the last stage of the returning the
>>> auth token back to client. The client sends returnUrl to be
>>> http://localhost/ and then after the process of user authentication and
>>> authorization finishes, the server redirects the response.
>>> The log of the server produces the following:
>>> WebDev.WebServer40.exe Information: 0 : Incoming request received:
>>> EndUserAuthorizationRequest
>>> WebDev.WebServer40.exe Information: 0 : Binding element
>>> DotNetOpenAuth.OAuth2.ChannelElements.TokenCodeSerializationBindingElement
>>> did not apply to message.
>>> WebDev.WebServer40.exe Information: 0 : Binding element
>>> DotNetOpenAuth.OAuth2.ChannelElements.MessageValidationBindingElement
>>> applied to message.
>>> WebDev.WebServer40.exe Information: 0 : Preparing to send
>>> EndUserAuthorizationSuccessAuthCodeResponseAS (2.0) message.
>>> WebDev.WebServer40.exe Information: 0 : Binding element
>>> DotNetOpenAuth.OAuth2.ChannelElements.MessageValidationBindingElement did
>>> not apply to message.
>>> WebDev.WebServer40.exe Information: 0 :
>>> DotNetOpenAuth.Messaging.Bindings.ICryptoKeyStore.GetKeys returned no keys
>>> for bucket "https://localhost/dnoa/oauth_authorization_code" with the
>>> required key length of 256 bits. A new key will be created
>>> WebDev.WebServer40.exe Information: 0 : Binding element
>>> DotNetOpenAuth.OAuth2.ChannelElements.TokenCodeSerializationBindingElement
>>> applied to message.
>>> WebDev.WebServer40.exe Information: 0 : Sending message:
>>> EndUserAuthorizationSuccessAuthCodeResponseAS
>>> WebDev.WebServer40.exe Information: 0 : Redirecting to
>>> http://localhost/?code=E7dl%21IAAAAJl4CfH60tn5k5PONt4tDaXMg_WOjIOSyEB...
>>> The problem is that no one listens on the port 80, thus the
>>> ClientAuthorizationView embedded in the dialog fails to navigate to the
>>> specified URL. As far as I understand it, I have no control in the
>>> OAuthConsumerWpfon the returnUrl parameter without changing the code of the
>>> client.
>>> Please advice what am I missing and what should be done to fix it.
>>> Thanks in advance
>>> Vadim
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "DotNetOpenAuth" group.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msg/dotnetopenid/-/SpsA_VganOIJ.
>>> To post to this group, send email to dotnetopenid@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> dotnetopenid+unsubscribe@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/dotnetopenid?hl=en.
>> --
>> You received this message because you are subscribed to the Google Groups
>> "DotNetOpenAuth" group.
>> To post to this group, send email to dotnetopenid@googlegroups.com.
>> To unsubscribe from this group, send email to
>> dotnetopenid+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/dotnetopenid?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "DotNetOpenAuth" group.
> To post to this group, send email to dotnetopenid@googlegroups.com.
> To unsubscribe from this group, send email to
> dotnetopenid+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/dotnetopenid?hl=en.
Yes, the authorization server must support it.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre
On Mon, Jul 2, 2012 at 10:02 AM, Øyvind Sean Kinsey <oyv...@kinsey.no>wrote:
> This also requires some extra work at the Authorization Server right? Not
> all AS have facilities for 'out of bound' authorization, but if it does or
> you are the one building it, then using the code grant is absolutely worth
> it.
> - Sean
> On Mon, Jul 2, 2012 at 9:51 AM, Andrew Arnott <andrewarn...@gmail.com>wrote:
>> Thanks, Oyvind.
>> Actually the authorization code grant type is an option for native
>> clients, and I still prefer that approach. But I think it requires that
>> the native app set up its own client account with the authorization server,
>> which is outside the scope of the spec but certainly something that could
>> be done using DNOA.
>> --
>> Andrew Arnott
>> "I [may] not agree with what you have to say, but I'll defend to the
>> death your right to say it." - S. G. Tallentyre
>> On Mon, Jul 2, 2012 at 9:11 AM, Øyvind Sean Kinsey <oyv...@kinsey.no>wrote:
>>> Are you trying to use OAuth2 in the context of a desktop application?
>>> If so then you have two main options, have the desktop app rely on a
>>> regular web app to do the token exchange, that way you can use the default
>>> way of exchanging codes/tokens, but this means that you need a secure way
>>> of transferring the token from the server to the app.
>>> The other option is to use the 'native application' profile as described
>>> in http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-9 combined
>>> with the 'implicit grant' (
>>> http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-4.2) where
>>> you end up reading the access token out of the user agent in your
>>> application.
>>> Alternatively, you implement an extension that lets you retrieve the
>>> token in some other way, eg by using verification codes manually inputted
>>> by the user and so on. An example of this can be found in
>>> https://github.com/AArnott/dotnetopenid/tree/v4.1/samples/OAuthConsum... >>> .
>>> Remember, as long as you control the user agent in the application it
>>> doesn't really matter that the redirect_url is not available - you will
>>> still be able to access the url navigated to in order to extract the needed
>>> data.
>>> Øyvind Sean Kinsey
>>> San Francisco, CA
>>> On Mon, Jul 2, 2012 at 2:53 AM, Vadim D. <vadi...@gmail.com> wrote:
>>>> Hi,
>>>> I am trying to develop OAuth 2.0 server that will use internal user
>>>> authentication and authorization of the client application.
>>>> In order to check the server I am using OAuthConsumerWpf application
>>>> provided with the samples.
>>>> Everything working just fine until the last stage of the returning the
>>>> auth token back to client. The client sends returnUrl to be
>>>> http://localhost/ and then after the process of user authentication
>>>> and authorization finishes, the server redirects the response.
>>>> The log of the server produces the following:
>>>> WebDev.WebServer40.exe Information: 0 : Incoming request received:
>>>> EndUserAuthorizationRequest
>>>> WebDev.WebServer40.exe Information: 0 : Binding element
>>>> DotNetOpenAuth.OAuth2.ChannelElements.TokenCodeSerializationBindingElement
>>>> did not apply to message.
>>>> WebDev.WebServer40.exe Information: 0 : Binding element
>>>> DotNetOpenAuth.OAuth2.ChannelElements.MessageValidationBindingElement
>>>> applied to message.
>>>> WebDev.WebServer40.exe Information: 0 : Preparing to send
>>>> EndUserAuthorizationSuccessAuthCodeResponseAS (2.0) message.
>>>> WebDev.WebServer40.exe Information: 0 : Binding element
>>>> DotNetOpenAuth.OAuth2.ChannelElements.MessageValidationBindingElement did
>>>> not apply to message.
>>>> WebDev.WebServer40.exe Information: 0 :
>>>> DotNetOpenAuth.Messaging.Bindings.ICryptoKeyStore.GetKeys returned no keys
>>>> for bucket "https://localhost/dnoa/oauth_authorization_code" with the
>>>> required key length of 256 bits. A new key will be created
>>>> WebDev.WebServer40.exe Information: 0 : Binding element
>>>> DotNetOpenAuth.OAuth2.ChannelElements.TokenCodeSerializationBindingElement
>>>> applied to message.
>>>> WebDev.WebServer40.exe Information: 0 : Sending message:
>>>> EndUserAuthorizationSuccessAuthCodeResponseAS
>>>> WebDev.WebServer40.exe Information: 0 : Redirecting to
>>>> http://localhost/?code=E7dl%21IAAAAJl4CfH60tn5k5PONt4tDaXMg_WOjIOSyEB...
>>>> The problem is that no one listens on the port 80, thus the
>>>> ClientAuthorizationView embedded in the dialog fails to navigate to the
>>>> specified URL. As far as I understand it, I have no control in the
>>>> OAuthConsumerWpfon the returnUrl parameter without changing the code of the
>>>> client.
>>>> Please advice what am I missing and what should be done to fix it.
>>>> Thanks in advance
>>>> Vadim
>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "DotNetOpenAuth" group.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msg/dotnetopenid/-/SpsA_VganOIJ.
>>>> To post to this group, send email to dotnetopenid@googlegroups.com.
>>>> To unsubscribe from this group, send email to
>>>> dotnetopenid+unsubscribe@googlegroups.com.
>>>> For more options, visit this group at
>>>> http://groups.google.com/group/dotnetopenid?hl=en.
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "DotNetOpenAuth" group.
>>> To post to this group, send email to dotnetopenid@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> dotnetopenid+unsubscribe@googlegroups.com.
>>> For more options, visit this group at
>>> http://groups.google.com/group/dotnetopenid?hl=en.
>> --
>> You received this message because you are subscribed to the Google Groups
>> "DotNetOpenAuth" group.
>> To post to this group, send email to dotnetopenid@googlegroups.com.
>> To unsubscribe from this group, send email to
>> dotnetopenid+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/dotnetopenid?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "DotNetOpenAuth" group.
> To post to this group, send email to dotnetopenid@googlegroups.com.
> To unsubscribe from this group, send email to
> dotnetopenid+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/dotnetopenid?hl=en.
My authorization server supports client registration out-of-band so there is no problem with it.
I am using *OAuthConsumerWpf *in order to check the server side and I am using the Generic 2.0 tab with the following parameters:
I have stepped in into the *ClientAuthorizationView *source code in order to understand how the interception of the navigation happens and so it happens every time the event *WebBrowser1_Navigating* is pumped up. But somehow, when I have redirection from the AS with the code, the embedded browser pups up the event with wrong URL, so function *SignificantlyEqual *is always false.
If I put a breakpoint on *ProcessLocationChanged *in class *
ClientAuthorizationView*, these are the URLs I am getting:
The problem is that tha last URL should be the client's callback URL and it's never received by the embedded browser, although the server sent redirection in method *AuthorizeResponse*, where the code
is checking the client, checking the scope, adding new authorization to the DB and then returning with:
On Monday, July 2, 2012 8:33:33 PM UTC+3, Andrew Arnott wrote:
> Yes, the authorization server must support it.
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - S. G. Tallentyre
> On Mon, Jul 2, 2012 at 10:02 AM, Øyvind Sean Kinsey <oyv...@kinsey.no>wrote:
>> This also requires some extra work at the Authorization Server right? Not >> all AS have facilities for 'out of bound' authorization, but if it does or >> you are the one building it, then using the code grant is absolutely worth >> it.
>> - Sean
>> On Mon, Jul 2, 2012 at 9:51 AM, Andrew Arnott <andrewarn...@gmail.com>wrote:
>>> Thanks, Oyvind.
>>> Actually the authorization code grant type is an option for native >>> clients, and I still prefer that approach. But I think it requires that >>> the native app set up its own client account with the authorization server, >>> which is outside the scope of the spec but certainly something that could >>> be done using DNOA.
>>> --
>>> Andrew Arnott
>>> "I [may] not agree with what you have to say, but I'll defend to the >>> death your right to say it." - S. G. Tallentyre
>>> On Mon, Jul 2, 2012 at 9:11 AM, Øyvind Sean Kinsey <oyv...@kinsey.no>wrote:
>>>> Are you trying to use OAuth2 in the context of a desktop application?
>>>> If so then you have two main options, have the desktop app rely on a >>>> regular web app to do the token exchange, that way you can use the default >>>> way of exchanging codes/tokens, but this means that you need a secure way >>>> of transferring the token from the server to the app.
>>>> The other option is to use the 'native application' profile as >>>> described in >>>> http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-9 combined >>>> with the 'implicit grant' (
>>>> http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-4.2) where >>>> you end up reading the access token out of the user agent in your >>>> application.
>>>> Alternatively, you implement an extension that lets you retrieve the >>>> token in some other way, eg by using verification codes manually inputted >>>> by the user and so on. An example of this can be found in >>>> https://github.com/AArnott/dotnetopenid/tree/v4.1/samples/OAuthConsum... >>>> .
>>>> Remember, as long as you control the user agent in the application it >>>> doesn't really matter that the redirect_url is not available - you will >>>> still be able to access the url navigated to in order to extract the needed >>>> data.
>>>> Øyvind Sean Kinsey
>>>> San Francisco, CA
>>>> On Mon, Jul 2, 2012 at 2:53 AM, Vadim D. wrote:
>>>>> Hi,
>>>>> I am trying to develop OAuth 2.0 server that will use internal user >>>>> authentication and authorization of the client application.
>>>>> In order to check the server I am using OAuthConsumerWpf application >>>>> provided with the samples.
>>>>> Everything working just fine until the last stage of the returning the >>>>> auth token back to client. The client sends returnUrl to be >>>>> http://localhost/ and then after the process of user authentication >>>>> and authorization finishes, the server redirects the response. >>>>> The log of the server produces the following:
>>>>> WebDev.WebServer40.exe Information: 0 : Incoming request received: >>>>> EndUserAuthorizationRequest
>>>>> WebDev.WebServer40.exe Information: 0 : Binding element >>>>> DotNetOpenAuth.OAuth2.ChannelElements.TokenCodeSerializationBindingElement >>>>> did not apply to message.
>>>>> WebDev.WebServer40.exe Information: 0 : Binding element >>>>> DotNetOpenAuth.OAuth2.ChannelElements.MessageValidationBindingElement >>>>> applied to message.
>>>>> WebDev.WebServer40.exe Information: 0 : Preparing to send >>>>> EndUserAuthorizationSuccessAuthCodeResponseAS (2.0) message.
>>>>> WebDev.WebServer40.exe Information: 0 : Binding element >>>>> DotNetOpenAuth.OAuth2.ChannelElements.MessageValidationBindingElement did >>>>> not apply to message.
>>>>> WebDev.WebServer40.exe Information: 0 : >>>>> DotNetOpenAuth.Messaging.Bindings.ICryptoKeyStore.GetKeys returned no keys >>>>> for bucket "https://localhost/dnoa/oauth_authorization_code" with the >>>>> required key length of 256 bits. A new key will be created
>>>>> WebDev.WebServer40.exe Information: 0 : Binding element >>>>> DotNetOpenAuth.OAuth2.ChannelElements.TokenCodeSerializationBindingElement >>>>> applied to message.
>>>>> WebDev.WebServer40.exe Information: 0 : Sending message: >>>>> EndUserAuthorizationSuccessAuthCodeResponseAS
>>>>> WebDev.WebServer40.exe Information: 0 : Redirecting to >>>>> http://localhost/?code=E7dl%21IAAAAJl4CfH60tn5k5PONt4tDaXMg_WOjIOSyEB...
>>>>> The problem is that no one listens on the port 80, thus the >>>>> ClientAuthorizationView embedded in the dialog fails to navigate to the >>>>> specified URL. As far as I understand it, I have no control in the >>>>> OAuthConsumerWpfon the returnUrl parameter without changing the code of the >>>>> client.
>>>>> Please advice what am I missing and what should be done to fix it.
>>>>> Thanks in advance
>>>>> Vadim
>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "DotNetOpenAuth" group.
>>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msg/dotnetopenid/-/SpsA_VganOIJ.
>>>>> To post to this group, send email to dotnetopenid@googlegroups.com.
>>>>> To unsubscribe from this group, send email to >>>>> dotnetopenid+unsubscribe@googlegroups.com.
>>>>> For more options, visit this group at >>>>> http://groups.google.com/group/dotnetopenid?hl=en.
>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "DotNetOpenAuth" group.
>>>> To post to this group, send
On Tuesday, July 3, 2012 8:52:03 AM UTC+3, Vadim D. wrote:
> Thanks you for your answers.
> My authorization server supports client registration out-of-band so there > is no problem with it.
> I am using *OAuthConsumerWpf *in order to check the server side and I am > using the Generic 2.0 tab with the following parameters:
> I have stepped in into the *ClientAuthorizationView *source code in order > to understand how the interception of the navigation happens and so it > happens every time the event *WebBrowser1_Navigating* is pumped up. But > somehow, when I have redirection from the AS with the code, the embedded > browser pups up the event with wrong URL, so function *SignificantlyEqual > *is always false.
> If I put a breakpoint on *ProcessLocationChanged *in class *
> ClientAuthorizationView*, these are the URLs I am getting:
> The problem is that tha last URL should be the client's callback URL and > it's never received by the embedded browser, although the server sent > redirection in method *AuthorizeResponse*, where the code
> is checking the client, checking the scope, adding new authorization to > the DB and then returning with:
> I will try to install Fiddler the check what is returned from the server, > but it looks very strange to me.
> Vadim
> On Monday, July 2, 2012 8:33:33 PM UTC+3, Andrew Arnott wrote:
>> Yes, the authorization server must support it.
>> --
>> Andrew Arnott
>> "I [may] not agree with what you have to say, but I'll defend to the >> death your right to say it." - S. G. Tallentyre
>> On Mon, Jul 2, 2012 at 10:02 AM, Øyvind Sean Kinsey <oyv...@kinsey.no>wrote:
>>> This also requires some extra work at the Authorization Server right? >>> Not all AS have facilities for 'out of bound' authorization, but if it does >>> or you are the one building it, then using the code grant is absolutely >>> worth it.
>>> - Sean
>>> On Mon, Jul 2, 2012 at 9:51 AM, Andrew Arnott <andrewarn...@gmail.com>wrote:
>>>> Thanks, Oyvind.
>>>> Actually the authorization code grant type is an option for native >>>> clients, and I still prefer that approach. But I think it requires that >>>> the native app set up its own client account with the authorization server, >>>> which is outside the scope of the spec but certainly something that could >>>> be done using DNOA.
>>>> --
>>>> Andrew Arnott
>>>> "I [may] not agree with what you have to say, but I'll defend to the >>>> death your right to say it." - S. G. Tallentyre
>>>> On Mon, Jul 2, 2012 at 9:11 AM, Øyvind Sean Kinsey <oyv...@kinsey.no>wrote:
>>>>> Are you trying to use OAuth2 in the context of a desktop application?
>>>>> If so then you have two main options, have the desktop app rely on a >>>>> regular web app to do the token exchange, that way you can use the default >>>>> way of exchanging codes/tokens, but this means that you need a secure way >>>>> of transferring the token from the server to the app.
>>>>> The other option is to use the 'native application' profile as >>>>> described in >>>>> http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-9 combined >>>>> with the 'implicit grant' (
>>>>> http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-4.2) where >>>>> you end up reading the access token out of the user agent in your >>>>> application.
>>>>> Alternatively, you implement an extension that lets you retrieve the >>>>> token in some other way, eg by using verification codes manually inputted >>>>> by the user and so on. An example of this can be found in >>>>> https://github.com/AArnott/dotnetopenid/tree/v4.1/samples/OAuthConsum... >>>>> .
>>>>> Remember, as long as you control the user agent in the application it >>>>> doesn't really matter that the redirect_url is not available - you will >>>>> still be able to access the url navigated to in order to extract the needed >>>>> data.
>>>>> Øyvind Sean Kinsey
>>>>> San Francisco, CA
>>>>> On Mon, Jul 2, 2012 at 2:53 AM, Vadim D. wrote:
>>>>>> Hi,
>>>>>> I am trying to develop OAuth 2.0 server that will use internal user >>>>>> authentication and authorization of the client application.
>>>>>> In order to check the server I am using OAuthConsumerWpf application >>>>>> provided with the samples.
>>>>>> Everything working just fine until the last stage of the returning >>>>>> the auth token back to client. The client sends returnUrl to be >>>>>> http://localhost/ and then after the process of user authentication >>>>>> and authorization finishes, the server redirects the response. >>>>>> The log of the server produces the following:
>>>>>> WebDev.WebServer40.exe Information: 0 : Incoming request received: >>>>>> EndUserAuthorizationRequest
>>>>>> WebDev.WebServer40.exe Information: 0 : Binding element >>>>>> DotNetOpenAuth.OAuth2.ChannelElements.TokenCodeSerializationBindingElement >>>>>> did not apply to message.
>>>>>> WebDev.WebServer40.exe Information: 0 : Binding element >>>>>> DotNetOpenAuth.OAuth2.ChannelElements.MessageValidationBindingElement >>>>>> applied to message.
>>>>>> WebDev.WebServer40.exe Information: 0 : Preparing to send >>>>>> EndUserAuthorizationSuccessAuthCodeResponseAS (2.0) message.
>>>>>> WebDev.WebServer40.exe Information: 0 : Binding element >>>>>> DotNetOpenAuth.OAuth2.ChannelElements.MessageValidationBindingElement did >>>>>> not apply to message.
>>>>>> WebDev.WebServer40.exe Information: 0 : >>>>>> DotNetOpenAuth.Messaging.Bindings.ICryptoKeyStore.GetKeys returned no keys >>>>>> for bucket "https://localhost/dnoa/oauth_authorization_code" with >>>>>> the required key length of 256 bits. A new key will be created
>>>>>> WebDev.WebServer40.exe Information: 0 : Binding element >>>>>> DotNetOpenAuth.OAuth2.ChannelElements.TokenCodeSerializationBindingElement >>>>>> applied to message.
>>>>>> WebDev.WebServer40.exe Information: 0 : Sending message: >>>>>> EndUserAuthorizationSuccessAuthCodeResponseAS
>>>>>> WebDev.WebServer40.exe Information: 0 : Redirecting to >>>>>> http://localhost/?code=E7dl%21IAAAAJl4CfH60tn5k5PONt4tDaXMg_WOjIOSyEB...
>>>>>> The problem is that no one listens on the port 80, thus the >>>>>> ClientAuthorizationView embedded in the dialog fails to navigate to the >>>>>> specified URL. As far as I understand it, I have no control in the >>>>>> OAuthConsumerWpfon the returnUrl parameter without changing the code of the >>>>>> client.
>>>>>> Please advice what am I missing and what should be done to fix it.
>>>>>> Thanks in advance
>>>>>> Vadim
>>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "DotNetOpenAuth" group.
>>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msg/dotnetopenid/-/SpsA_VganOIJ.
>>>>>> To post to
I have continued to run the Fiddler and now I have another strange problem - I have server side exception in Token action that the client is not authenticated.
I have checked the reason and found that this is happening while server tries to authenticate the client from HTTP headers.
The problem is that .NET framework does not send this header when you do something like:
HttpWebRequest request = (HttpWebRequest)WebRequest.Create(...);
request.Credentials = new NetworkCredential("username", "password");
but instead it waits for server to reply with 401 and WWW-Authenticate<http://freesoft.org/CIE/RFC/1945/65.htm>header presented - only after this the proper authentication header will be sent. So it seems to me that I have to change somehow the Token action to require client authentication (your example of the server does not contains this)
On Tuesday, July 3, 2012 9:48:34 AM UTC+3, Vadim D. wrote:
> Very strange, but after installing and running Fiddler everything started > to work ... I have checked again without Fiddler - not working
> On Tuesday, July 3, 2012 8:52:03 AM UTC+3, Vadim D. wrote:
>> Thanks you for your answers.
>> My authorization server supports client registration out-of-band so there >> is no problem with it.
>> I am using *OAuthConsumerWpf *in order to check the server side and I >> am using the Generic 2.0 tab with the following parameters:
>> I have stepped in into the *ClientAuthorizationView *source code in >> order to understand how the interception of the navigation happens and so >> it happens every time the event *WebBrowser1_Navigating* is pumped up. >> But somehow, when I have redirection from the AS with the code, the >> embedded browser pups up the event with wrong URL, so function *SignificantlyEqual >> *is always false.
>> If I put a breakpoint on *ProcessLocationChanged *in class *
>> ClientAuthorizationView*, these are the URLs I am getting:
>> The problem is that tha last URL should be the client's callback URL and >> it's never received by the embedded browser, although the server sent >> redirection in method *AuthorizeResponse*, where the code
>> is checking the client, checking the scope, adding new authorization to >> the DB and then returning with:
>> I will try to install Fiddler the check what is returned from the server, >> but it looks very strange to me.
>> Vadim
>> On Monday, July 2, 2012 8:33:33 PM UTC+3, Andrew Arnott wrote:
>>> Yes, the authorization server must support it.
>>> --
>>> Andrew Arnott
>>> "I [may] not agree with what you have to say, but I'll defend to the >>> death your right to say it." - S. G. Tallentyre
>>> On Mon, Jul 2, 2012 at 10:02 AM, Øyvind Sean Kinsey <oyv...@kinsey.no>wrote:
>>>> This also requires some extra work at the Authorization Server right? >>>> Not all AS have facilities for 'out of bound' authorization, but if it does >>>> or you are the one building it, then using the code grant is absolutely >>>> worth it.
>>>> - Sean
>>>> On Mon, Jul 2, 2012 at 9:51 AM, Andrew Arnott <andrewarn...@gmail.com>wrote:
>>>>> Thanks, Oyvind.
>>>>> Actually the authorization code grant type is an option for native >>>>> clients, and I still prefer that approach. But I think it requires that >>>>> the native app set up its own client account with the authorization server, >>>>> which is outside the scope of the spec but certainly something that could >>>>> be done using DNOA.
>>>>> --
>>>>> Andrew Arnott
>>>>> "I [may] not agree with what you have to say, but I'll defend to the >>>>> death your right to say it." - S. G. Tallentyre
>>>>> On Mon, Jul 2, 2012 at 9:11 AM, Øyvind Sean Kinsey <oyv...@kinsey.no>wrote:
>>>>>> Are you trying to use OAuth2 in the context of a desktop application?
>>>>>> If so then you have two main options, have the desktop app rely on a >>>>>> regular web app to do the token exchange, that way you can use the default >>>>>> way of exchanging codes/tokens, but this means that you need a secure way >>>>>> of transferring the token from the server to the app.
>>>>>> The other option is to use the 'native application' profile as >>>>>> described in >>>>>> http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-9 combined >>>>>> with the 'implicit grant' (
>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-4.2) where >>>>>> you end up reading the access token out of the user agent in your >>>>>> application.
>>>>>> Alternatively, you implement an extension that lets you retrieve the >>>>>> token in some other way, eg by using verification codes manually inputted >>>>>> by the user and so on. An example of this can be found in >>>>>> https://github.com/AArnott/dotnetopenid/tree/v4.1/samples/OAuthConsum... >>>>>> .
>>>>>> Remember, as long as you control the user agent in the application it >>>>>> doesn't really matter that the redirect_url is not available - you will >>>>>> still be able to access the url navigated to in order to extract the needed >>>>>> data.
>>>>>> Øyvind Sean Kinsey
>>>>>> San Francisco, CA
>>>>>> On Mon, Jul 2, 2012 at 2:53 AM, Vadim D. wrote:
>>>>>>> Hi,
>>>>>>> I am trying to develop OAuth 2.0 server that will use internal user >>>>>>> authentication and authorization of the client application.
>>>>>>> In order to check the server I am using OAuthConsumerWpf >>>>>>> application provided with the samples.
>>>>>>> Everything working just fine until the last stage of the returning >>>>>>> the auth token back to client. The client sends returnUrl to be >>>>>>> http://localhost/ and then after the process of user authentication >>>>>>> and authorization finishes, the server redirects the response. >>>>>>> The log of the server produces the following:
>>>>>>> WebDev.WebServer40.exe Information: 0 : Incoming request received: >>>>>>> EndUserAuthorizationRequest
>>>>>>> WebDev.WebServer40.exe Information: 0 : Binding element >>>>>>> DotNetOpenAuth.OAuth2.ChannelElements.TokenCodeSerializationBindingElement >>>>>>> did not apply to message.
>>>>>>> WebDev.WebServer40.exe Information: 0 : Binding element >>>>>>> DotNetOpenAuth.OAuth2.ChannelElements.MessageValidationBindingElement >>>>>>> applied to message.
>>>>>>> WebDev.WebServer40.exe Information: 0 : Preparing to send >>>>>>> EndUserAuthorizationSuccessAuthCodeResponseAS (2.0) message.
>>>>>>> WebDev.WebServer40.exe Information: 0 : Binding element >>>>>>> DotNetOpenAuth.OAuth2.ChannelElements.MessageValidationBindingElement did >>>>>>> not apply to message.
>>>>>>> WebDev.WebServer40.exe Information: 0 : >>>>>>> DotNetOpenAuth.Messaging.Bindings.ICryptoKeyStore.GetKeys returned no keys >>>>>>> for bucket "https://localhost/dnoa/oauth_authorization_code" with >>>>>>> the required key length of 256 bits. A new key will be created
>>>>>>> WebDev.WebServer40.exe Information: 0 : Binding element >>>>>>> DotNetOpenAuth.OAuth2.ChannelElements.TokenCodeSerializationBindingElement >>>>>>> applied to message.
>>>>>>> WebDev.WebServer40.exe Information: 0 : Sending message: >>>>>>> EndUserAuthorizationSuccessAuthCodeResponseAS
>>>>>>> WebDev.WebServer40.exe Information: 0 : Redirecting to
Yes, .NET makes it extremely difficult to include an HTTP Authorization
header in the initial request and requires the authenticate challenge
response first.
Support for HTTP Basic client authentication is new in DNOA v4.1. The MVC
controller in the authorization server sample doesn't have an [Authorize]
attribute because DNOA handles it internally. If you step through the
OAuthClient and OAuthAuthorizationServer samples together, you'll see the
first request come in, get rejected with the error, and the client will
automatically retry applying the client credentials in the Authorization
header. This is how your app should presumably work as well.
Alternatively you can simply use the old style method of applying client id
and secret inside your POST payload, but OAuth 2 strongly discourages this.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre
On Tue, Jul 3, 2012 at 6:49 AM, Vadim D. <vadi...@gmail.com> wrote:
> I have continued to run the Fiddler and now I have another strange problem
> - I have server side exception in Token action that the client is not
> authenticated.
> I have checked the reason and found that this is happening while server
> tries to authenticate the client from HTTP headers.
> The problem is that .NET framework does not send this header when you do
> something like:
> but instead it waits for server to reply with 401 and WWW-Authenticate<http://freesoft.org/CIE/RFC/1945/65.htm>header presented - only after this the proper authentication header will be
> sent.
> So it seems to me that I have to change somehow the Token action to
> require client authentication (your example of the server does not contains
> this)
> Vadim
> On Tuesday, July 3, 2012 9:48:34 AM UTC+3, Vadim D. wrote:
>> Very strange, but after installing and running Fiddler everything started
>> to work ... I have checked again without Fiddler - not working
>> On Tuesday, July 3, 2012 8:52:03 AM UTC+3, Vadim D. wrote:
>>> Thanks you for your answers.
>>> My authorization server supports client registration out-of-band so
>>> there is no problem with it.
>>> I am using *OAuthConsumerWpf *in order to check the server side and I
>>> am using the Generic 2.0 tab with the following parameters:
>>> I have stepped in into the *ClientAuthorizationView *source code in
>>> order to understand how the interception of the navigation happens and so
>>> it happens every time the event *WebBrowser1_Navigating* is pumped up.
>>> But somehow, when I have redirection from the AS with the code, the
>>> embedded browser pups up the event with wrong URL, so function *SignificantlyEqual
>>> *is always false.
>>> If I put a breakpoint on *ProcessLocationChanged *in class *
>>> ClientAuthorizationView*, these are the URLs I am getting:
>>> The problem is that tha last URL should be the client's callback URL and
>>> it's never received by the embedded browser, although the server sent
>>> redirection in method *AuthorizeResponse*, where the code
>>> is checking the client, checking the scope, adding new authorization to
>>> the DB and then returning with:
>>> I will try to install Fiddler the check what is returned from the
>>> server, but it looks very strange to me.
>>> Vadim
>>> On Monday, July 2, 2012 8:33:33 PM UTC+3, Andrew Arnott wrote:
>>>> Yes, the authorization server must support it.
>>>> --
>>>> Andrew Arnott
>>>> "I [may] not agree with what you have to say, but I'll defend to the
>>>> death your right to say it." - S. G. Tallentyre
>>>> On Mon, Jul 2, 2012 at 10:02 AM, Øyvind Sean Kinsey <oyv...@kinsey.no>wrote:
>>>>> This also requires some extra work at the Authorization Server right?
>>>>> Not all AS have facilities for 'out of bound' authorization, but if it does
>>>>> or you are the one building it, then using the code grant is absolutely
>>>>> worth it.
>>>>> - Sean
>>>>> On Mon, Jul 2, 2012 at 9:51 AM, Andrew Arnott <andrewarn...@gmail.com>wrote:
>>>>>> Thanks, Oyvind.
>>>>>> Actually the authorization code grant type is an option for native
>>>>>> clients, and I still prefer that approach. But I think it requires that
>>>>>> the native app set up its own client account with the authorization server,
>>>>>> which is outside the scope of the spec but certainly something that could
>>>>>> be done using DNOA.
>>>>>> --
>>>>>> Andrew Arnott
>>>>>> "I [may] not agree with what you have to say, but I'll defend to the
>>>>>> death your right to say it." - S. G. Tallentyre
>>>>>> On Mon, Jul 2, 2012 at 9:11 AM, Øyvind Sean Kinsey <oyv...@kinsey.no>wrote:
>>>>>>> Remember, as long as you control the user agent in the application
>>>>>>> it doesn't really matter that the redirect_url is not available - you will
>>>>>>> still be able to access the url navigated to in order to extract the needed
>>>>>>> data.
>>>>>>> Øyvind Sean Kinsey
>>>>>>> San Francisco, CA
>>>>>>> On Mon, Jul 2, 2012 at 2:53 AM, Vadim D. wrote:
>>>>>>>> Hi,
>>>>>>>> I am trying to develop OAuth 2.0 server that will use internal user
>>>>>>>> authentication and authorization of the client application.
>>>>>>>> In order to check the server I am using OAuthConsumerWpf
>>>>>>>> application provided with the samples.
>>>>>>>> Everything working just fine until the last stage of the returning
>>>>>>>> the auth token back to client. The client sends returnUrl to be
>>>>>>>> http://localhost/ and then after the process of user
>>>>>>>> authentication and authorization finishes, the server redirects the
var httpClient = new HttpClient()
{
BaseAddress = new Uri(System.Configuration.ConfigurationManager.AppSettings["Domain"])
};
// set the oauth info
httpClient.DefaultRequestHeaders.Authorization = new System.Net.Http.Headers.AuthenticationHeaderValue("Basic", authInfo);
I've used this over TLS to do basic auth on a recent project - works well but it's one of the things i'm looking to do with DotNetOpenAuth in the coming week or so if i get time so not sure what kind of work would be needed.
On Tuesday, July 3, 2012 2:49:57 PM UTC+1, Vadim D. wrote:
> I have continued to run the Fiddler and now I have another strange problem > - I have server side exception in Token action that the client is not > authenticated.
> I have checked the reason and found that this is happening while server > tries to authenticate the client from HTTP headers.
> The problem is that .NET framework does not send this header when you do > something like:
> but instead it waits for server to reply with 401 and WWW-Authenticate<http://freesoft.org/CIE/RFC/1945/65.htm>header presented - only after this the proper authentication header will be > sent. > So it seems to me that I have to change somehow the Token action to > require client authentication (your example of the server does not contains > this)
> Vadim
> On Tuesday, July 3, 2012 9:48:34 AM UTC+3, Vadim D. wrote:
>> Very strange, but after installing and running Fiddler everything started >> to work ... I have checked again without Fiddler - not working
>> On Tuesday, July 3, 2012 8:52:03 AM UTC+3, Vadim D. wrote:
>>> Thanks you for your answers.
>>> My authorization server supports client registration out-of-band so >>> there is no problem with it.
>>> I am using *OAuthConsumerWpf *in order to check the server side and I >>> am using the Generic 2.0 tab with the following parameters:
>>> I have stepped in into the *ClientAuthorizationView *source code in >>> order to understand how the interception of the navigation happens and so >>> it happens every time the event *WebBrowser1_Navigating* is pumped up. >>> But somehow, when I have redirection from the AS with the code, the >>> embedded browser pups up the event with wrong URL, so function *SignificantlyEqual >>> *is always false.
>>> If I put a breakpoint on *ProcessLocationChanged *in class *
>>> ClientAuthorizationView*, these are the URLs I am getting:
>>> The problem is that tha last URL should be the client's callback URL and >>> it's never received by the embedded browser, although the server sent >>> redirection in method *AuthorizeResponse*, where the code
>>> is checking the client, checking the scope, adding new authorization to >>> the DB and then returning with:
>>> I will try to install Fiddler the check what is returned from the >>> server, but it looks very strange to me.
>>> Vadim
>>> On Monday, July 2, 2012 8:33:33 PM UTC+3, Andrew Arnott wrote:
>>>> Yes, the authorization server must support it.
>>>> --
>>>> Andrew Arnott
>>>> "I [may] not agree with what you have to say, but I'll defend to the >>>> death your right to say it." - S. G. Tallentyre
>>>> On Mon, Jul 2, 2012 at 10:02 AM, Øyvind Sean Kinsey <oyv...@kinsey.no>wrote:
>>>>> This also requires some extra work at the Authorization Server right? >>>>> Not all AS have facilities for 'out of bound' authorization, but if it does >>>>> or you are the one building it, then using the code grant is absolutely >>>>> worth it.
>>>>> - Sean
>>>>> On Mon, Jul 2, 2012 at 9:51 AM, Andrew Arnott <andrewarn...@gmail.com>wrote:
>>>>>> Thanks, Oyvind.
>>>>>> Actually the authorization code grant type is an option for native >>>>>> clients, and I still prefer that approach. But I think it requires that >>>>>> the native app set up its own client account with the authorization server, >>>>>> which is outside the scope of the spec but certainly something that could >>>>>> be done using DNOA.
>>>>>> --
>>>>>> Andrew Arnott
>>>>>> "I [may] not agree with what you have to say, but I'll defend to the >>>>>> death your right to say it." - S. G. Tallentyre
>>>>>> On Mon, Jul 2, 2012 at 9:11 AM, Øyvind Sean Kinsey <oyv...@kinsey.no>wrote:
>>>>>>> Are you trying to use OAuth2 in the context of a desktop application?
>>>>>>> If so then you have two main options, have the desktop app rely on a >>>>>>> regular web app to do the token exchange, that way you can use the default >>>>>>> way of exchanging codes/tokens, but this means that you need a secure way >>>>>>> of transferring the token from the server to the app.
>>>>>>> The other option is to use the 'native application' profile as >>>>>>> described in >>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-9combined with the 'implicit grant' (
>>>>>>> http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-4.2) >>>>>>> where you end up reading the access token out of the user agent in your >>>>>>> application.
>>>>>>> Alternatively, you implement an extension that lets you retrieve the >>>>>>> token in some other way, eg by using verification codes manually inputted >>>>>>> by the user and so on. An example of this can be found in >>>>>>> https://github.com/AArnott/dotnetopenid/tree/v4.1/samples/OAuthConsum... >>>>>>> .
>>>>>>> Remember, as long as you control the user agent in the application >>>>>>> it doesn't really matter that the redirect_url is not available - you will >>>>>>> still be able to access the url navigated to in order to extract the needed >>>>>>> data.
>>>>>>> Øyvind Sean Kinsey
>>>>>>> San Francisco, CA
>>>>>>> On Mon, Jul 2, 2012 at 2:53 AM, Vadim D. wrote:
>>>>>>>> Hi,
>>>>>>>> I am trying to develop OAuth 2.0 server that will use internal user >>>>>>>> authentication and authorization of the client application.
>>>>>>>> In order to check the server I am using OAuthConsumerWpf >>>>>>>> application provided with the samples.
>>>>>>>> Everything working just fine until the last stage of the returning >>>>>>>> the auth token back to client. The client sends returnUrl to be >>>>>>>> http://localhost/ and then after the process of user >>>>>>>> authentication and authorization finishes, the server redirects the >>>>>>>> response. >>>>>>>> The log of the server produces the following:
>>>>>>>> WebDev.WebServer40.exe Information: 0 : Incoming request received: >>>>>>>> EndUserAuthorizationRequest
>>>>>>>> WebDev.WebServer40.exe Information: 0 : Binding element >>>>>>>> DotNetOpenAuth.OAuth2.ChannelElements.TokenCodeSerializationBindingElement >>>>>>>> did not apply to message.
>>>>>>>> WebDev.WebServer40.exe Information: 0 : Binding element
DNOA still targets .NET 3.5, so it can't take a dependency on a .NET 4.0
class like HttpClient, if I understand what you're proposing correctly.
However there are specific DNOA builds that support #ifdef around code
that might allow DNOA to use HttpClient when specifically building against
.NET 4.0. Another option may be to implement your own
IDirectWebRequestHandler, in which case your implementation can use
HttpClient and then since DNOA will use your handler instead of its own
internal default it will work the way you want.
On the other hand, you could keep doing it the way the samples do and it
already works, just with an extra round trip.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre
> var httpClient = new HttpClient()
> {
> BaseAddress = new
> Uri(System.Configuration.ConfigurationManager.AppSettings["Domain"])
> };
> // set the oauth info
> httpClient.DefaultRequestHeaders.Authorization = new
> System.Net.Http.Headers.AuthenticationHeaderValue("Basic", authInfo);
> I've used this over TLS to do basic auth on a recent project - works well
> but it's one of the things i'm looking to do with DotNetOpenAuth in the
> coming week or so if i get time so not sure what kind of work would be
> needed.
> /steven
> On Tuesday, July 3, 2012 2:49:57 PM UTC+1, Vadim D. wrote:
>> I have continued to run the Fiddler and now I have another strange
>> problem - I have server side exception in Token action that the client is
>> not authenticated.
>> I have checked the reason and found that this is happening while server
>> tries to authenticate the client from HTTP headers.
>> The problem is that .NET framework does not send this header when you do
>> something like:
>> but instead it waits for server to reply with 401 and WWW-Authenticate<http://freesoft.org/CIE/RFC/1945/65.htm>header presented - only after this the proper authentication header will be
>> sent.
>> So it seems to me that I have to change somehow the Token action to
>> require client authentication (your example of the server does not contains
>> this)
>> Vadim
>> On Tuesday, July 3, 2012 9:48:34 AM UTC+3, Vadim D. wrote:
>>> Very strange, but after installing and running Fiddler everything
>>> started to work ... I have checked again without Fiddler - not working
>>> On Tuesday, July 3, 2012 8:52:03 AM UTC+3, Vadim D. wrote:
>>>> Thanks you for your answers.
>>>> My authorization server supports client registration out-of-band so
>>>> there is no problem with it.
>>>> I am using *OAuthConsumerWpf *in order to check the server side and I
>>>> am using the Generic 2.0 tab with the following parameters:
>>>> I have stepped in into the *ClientAuthorizationView *source code in
>>>> order to understand how the interception of the navigation happens and so
>>>> it happens every time the event *WebBrowser1_Navigating* is pumped up.
>>>> But somehow, when I have redirection from the AS with the code, the
>>>> embedded browser pups up the event with wrong URL, so function *SignificantlyEqual
>>>> *is always false.
>>>> If I put a breakpoint on *ProcessLocationChanged *in class *
>>>> ClientAuthorizationView*, these are the URLs I am getting:
>>>> The problem is that tha last URL should be the client's callback URL
>>>> and it's never received by the embedded browser, although the server sent
>>>> redirection in method *AuthorizeResponse*, where the code
>>>> is checking the client, checking the scope, adding new authorization to
>>>> the DB and then returning with:
>>>> I will try to install Fiddler the check what is returned from the
>>>> server, but it looks very strange to me.
>>>> Vadim
>>>> On Monday, July 2, 2012 8:33:33 PM UTC+3, Andrew Arnott wrote:
>>>>> Yes, the authorization server must support it.
>>>>> --
>>>>> Andrew Arnott
>>>>> "I [may] not agree with what you have to say, but I'll defend to the
>>>>> death your right to say it." - S. G. Tallentyre
>>>>> On Mon, Jul 2, 2012 at 10:02 AM, Øyvind Sean Kinsey <oyv...@kinsey.no>wrote:
>>>>>> This also requires some extra work at the Authorization Server right?
>>>>>> Not all AS have facilities for 'out of bound' authorization, but if it does
>>>>>> or you are the one building it, then using the code grant is absolutely
>>>>>> worth it.
>>>>>> - Sean
>>>>>> On Mon, Jul 2, 2012 at 9:51 AM, Andrew Arnott <andrewarn...@gmail.com
>>>>>> > wrote:
>>>>>>> Thanks, Oyvind.
>>>>>>> Actually the authorization code grant type is an option for native
>>>>>>> clients, and I still prefer that approach. But I think it requires that
>>>>>>> the native app set up its own client account with the authorization server,
>>>>>>> which is outside the scope of the spec but certainly something that could
>>>>>>> be done using DNOA.
>>>>>>> --
>>>>>>> Andrew Arnott
>>>>>>> "I [may] not agree with what you have to say, but I'll defend to the
>>>>>>> death your right to say it." - S. G. Tallentyre
>>>>>>> On Mon, Jul 2, 2012 at 9:11 AM, Øyvind Sean Kinsey <oyv...@kinsey.no
>>>>>>> > wrote:
Thanks for the answer. I prefer not to change the client side.
What I did what to add the [RequireBasicAuthentication] attribute and implement it this way:
[AttributeUsage(AttributeTargets.Method)]
public sealed class RequireBasicAuthentication : FilterAttribute, IAuthorizationFilter {
public void OnAuthorization(AuthorizationContext filterContext)
{
var req = filterContext.HttpContext.Request;
if (String.IsNullOrEmpty(req.Headers["Authorization"]))
{
filterContext.Result = new ContentResult() { Content = "Not Authorized"};
var res = filterContext.HttpContext.Response;
res.StatusCode = 401;
res.AddHeader("WWW-Authenticate", "Basic realm=\"XXXXXXXXXXXX\"");
res.End();
}
}
}
Now it's working just fine without changing client side code.
I am stil struggling with the issue that somehow the WPF client supplied with the samples works only while Fiddler is on ... Without fiddler I am getting the error page in embedded browser control
On Thursday, July 5, 2012 7:41:06 PM UTC+3, Andrew Arnott wrote:
> DNOA still targets .NET 3.5, so it can't take a dependency on a .NET 4.0 > class like HttpClient, if I understand what you're proposing correctly. > However there are specific DNOA builds that support #ifdef around code > that might allow DNOA to use HttpClient when specifically building against > .NET 4.0. Another option may be to implement your own > IDirectWebRequestHandler, in which case your implementation can use > HttpClient and then since DNOA will use your handler instead of its own > internal default it will work the way you want.
> On the other hand, you could keep doing it the way the samples do and it > already works, just with an extra round trip.
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - S. G. Tallentyre
> On Thu, Jul 5, 2012 at 9:23 AM, weblivz <webl...@hotmail.com> wrote:
>> Might I suggest you look at the System.Net.Http namespace on ASP.NETMVC4.i
>> var httpClient = new HttpClient()
>> {
>> BaseAddress = new >> Uri(System.Configuration.ConfigurationManager.AppSettings["Domain"])
>> };
>> // set the oauth info
>> httpClient.DefaultRequestHeaders.Authorization = new >> System.Net.Http.Headers.AuthenticationHeaderValue("Basic", authInfo);
>> I've used this over TLS to do basic auth on a recent project - works well >> but it's one of the things i'm looking to do with DotNetOpenAuth in the >> coming week or so if i get time so not sure what kind of work would be >> needed.
>> /steven
>> On Tuesday, July 3, 2012 2:49:57 PM UTC+1, Vadim D. wrote:
>>> I have continued to run the Fiddler and now I have another strange >>> problem - I have server side exception in Token action that the client is >>> not authenticated.
>>> I have checked the reason and found that this is happening while server >>> tries to authenticate the client from HTTP headers.
>>> The problem is that .NET framework does not send this header when you do >>> something like:
>>> but instead it waits for server to reply with 401 and WWW-Authenticate<http://freesoft.org/CIE/RFC/1945/65.htm>header presented - only after this the proper authentication header will be >>> sent. >>> So it seems to me that I have to change somehow the Token action to >>> require client authentication (your example of the server does not contains >>> this)
>>> Vadim
>>> On Tuesday, July 3, 2012 9:48:34 AM UTC+3, Vadim D. wrote:
>>>> Very strange, but after installing and running Fiddler everything >>>> started to work ... I have checked again without Fiddler - not working
>>>> On Tuesday, July 3, 2012 8:52:03 AM UTC+3, Vadim D. wrote:
>>>>> Thanks you for your answers.
>>>>> My authorization server supports client registration out-of-band so >>>>> there is no problem with it.
>>>>> I am using *OAuthConsumerWpf *in order to check the server side and >>>>> I am using the Generic 2.0 tab with the following parameters:
>>>>> I have stepped in into the *ClientAuthorizationView *source code in >>>>> order to understand how the interception of the navigation happens and so >>>>> it happens every time the event *WebBrowser1_Navigating* is pumped >>>>> up. But somehow, when I have redirection from the AS with the code, the >>>>> embedded browser pups up the event with wrong URL, so function *SignificantlyEqual >>>>> *is always false.
>>>>> If I put a breakpoint on *ProcessLocationChanged *in class *
>>>>> ClientAuthorizationView*, these are the URLs I am getting:
>>>>> The problem is that tha last URL should be the client's callback URL >>>>> and it's never received by the embedded browser, although the server sent >>>>> redirection in method *AuthorizeResponse*, where the code
>>>>> is checking the client, checking the scope, adding new authorization >>>>> to the DB and then returning with:
>>>>> I will try to install Fiddler the check what is returned from the >>>>> server, but it looks very strange to me.
>>>>> Vadim
>>>>> On Monday, July 2, 2012 8:33:33 PM UTC+3, Andrew Arnott wrote:
>>>>>> Yes, the authorization server must support it.
>>>>>> --
>>>>>> Andrew Arnott
>>>>>> "I [may] not agree with what you have to say, but I'll defend to the >>>>>> death your right to say it." - S. G. Tallentyre
>>>>>> On Mon, Jul 2, 2012 at 10:02 AM, Øyvind Sean Kinsey <oyv...@kinsey.no
>>>>>> > wrote:
>>>>>>> This also requires some extra work at the Authorization Server >>>>>>> right? Not all AS have facilities for 'out of bound' authorization, but if >>>>>>> it does or you are the one building it, then using the code grant is >>>>>>> absolutely worth it.
>>>>>>> - Sean
>>>>>>> On Mon, Jul 2, 2012 at 9:51 AM, Andrew Arnott <
>>>>>>> andrewarn...@gmail.com> wrote:
>>>>>>>> Thanks, Oyvind.
>>>>>>>> Actually the authorization code grant type is an option for native >>>>>>>> clients, and I still prefer that approach. But I think it requires that >>>>>>>> the native app set up its own client account with the authorization server, >>>>>>>> which is outside the scope of the spec but certainly something that could >>>>>>>> be done using DNOA.
>>>>>>>> --
>>>>>>>> Andrew Arnott
>>>>>>>> "I [may] not agree with what you have to say, but I'll defend to >>>>>>>> the death your right to say it." - S. G.
You've brought up an interesting point. Yes, if the nonce appears twice,
the first in a message without authentication and the second in a message
with it, then it seems the nonce should only be "consumed" the second time.
The fact that DNOA is consuming it both times sounds problematic. I don't
know why the sample is working in this case either. It's worth looking
more into. Do you have cycles to debug into it?
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre
On Fri, Aug 31, 2012 at 10:10 AM, James Andersen <james.j.ander...@gmail.com
> wrote:
> I've just been stuck on this as well... I ran into trouble because I
> found that first request failed for lack of an authentication header (as
> already noted) but then the second request (now authenticated) was failing
> because the INonceStore was returning false because the same entry was
> already recorded by the first request. For some reason the sample code
> (with the DatabaseKeyNonceStore) doesn't seem to have a problem with this
> even though the values passed to StoreNonce are exactly the same on both
> requests; my custom implementation was returning false on the second
> response which seems to be what it SHOULD do. Is this the expected
> behavior with StoreNonce? Should DNOA be calling StoreNonce twice for
> both the unauthenticated AND the authenticated request with the same values
> both times?
> On Thursday, July 5, 2012 10:14:57 AM UTC-6, Andrew Arnott wrote:
>> Yes, .NET makes it extremely difficult to include an HTTP Authorization
>> header in the initial request and requires the authenticate challenge
>> response first.
>> Support for HTTP Basic client authentication is new in DNOA v4.1. The
>> MVC controller in the authorization server sample doesn't have an
>> [Authorize] attribute because DNOA handles it internally. If you step
>> through the OAuthClient and OAuthAuthorizationServer samples together,
>> you'll see the first request come in, get rejected with the error, and the
>> client will automatically retry applying the client credentials in the
>> Authorization header. This is how your app should presumably work as well.
>> Alternatively you can simply use the old style method of applying client
>> id and secret inside your POST payload, but OAuth 2 strongly discourages
>> this.
>> --
>> Andrew Arnott
>> "I [may] not agree with what you have to say, but I'll defend to the
>> death your right to say it." - S. G. Tallentyre
>> On Tue, Jul 3, 2012 at 6:49 AM, Vadim D. <vad...@gmail.com> wrote:
>>> I have continued to run the Fiddler and now I have another strange
>>> problem - I have server side exception in Token action that the client is
>>> not authenticated.
>>> I have checked the reason and found that this is happening while server
>>> tries to authenticate the client from HTTP headers.
>>> The problem is that .NET framework does not send this header when you do
>>> something like:
>>> but instead it waits for server to reply with 401 and WWW-Authenticate<http://freesoft.org/CIE/RFC/1945/65.htm>header presented - only after this the proper authentication header will be
>>> sent.
>>> So it seems to me that I have to change somehow the Token action to
>>> require client authentication (your example of the server does not contains
>>> this)
>>> Vadim
>>> On Tuesday, July 3, 2012 9:48:34 AM UTC+3, Vadim D. wrote:
>>>> Very strange, but after installing and running Fiddler everything
>>>> started to work ... I have checked again without Fiddler - not working
>>>> On Tuesday, July 3, 2012 8:52:03 AM UTC+3, Vadim D. wrote:
>>>>> Thanks you for your answers.
>>>>> My authorization server supports client registration out-of-band so
>>>>> there is no problem with it.
>>>>> I am using *OAuthConsumerWpf *in order to check the server side and
>>>>> I am using the Generic 2.0 tab with the following parameters:
>>>>> I have stepped in into the *ClientAuthorizationView *source code in
>>>>> order to understand how the interception of the navigation happens and so
>>>>> it happens every time the event *WebBrowser1_Navigating* is pumped
>>>>> up. But somehow, when I have redirection from the AS with the code, the
>>>>> embedded browser pups up the event with wrong URL, so function *SignificantlyEqual
>>>>> *is always false.
>>>>> If I put a breakpoint on *ProcessLocationChanged *in class *
>>>>> ClientAuthorizationView*, these are the URLs I am getting:
>>>>> The problem is that tha last URL should be the client's callback URL
>>>>> and it's never received by the embedded browser, although the server sent
>>>>> redirection in method *AuthorizeResponse*, where the code
>>>>> is checking the client, checking the scope, adding new authorization
>>>>> to the DB and then returning with:
>>>>> I will try to install Fiddler the check what is returned from the
>>>>> server, but it looks very strange to me.
>>>>> Vadim
>>>>> On Monday, July 2, 2012 8:33:33 PM UTC+3, Andrew Arnott wrote:
>>>>>> Yes, the authorization server must support it.
>>>>>> --
>>>>>> Andrew Arnott
>>>>>> "I [may] not agree with what you have to say, but I'll defend to the
>>>>>> death your right to say it." - S. G. Tallentyre
>>>>>> On Mon, Jul 2, 2012 at 10:02 AM, Øyvind Sean Kinsey <oyv...@kinsey.no
>>>>>> > wrote:
>>>>>>> This also requires some extra work at the Authorization Server
>>>>>>> right? Not all AS have facilities for 'out of bound' authorization, but if
>>>>>>> it does or you are the one building it, then using the code grant is
>>>>>>> absolutely worth it.
>>>>>>> - Sean
>>>>>>> On Mon, Jul 2, 2012 at 9:51 AM, Andrew Arnott <andrew...@gmail.com>wrote:
>>>>>>>> Thanks, Oyvind.
>>>>>>>> Actually the authorization code grant type is an option for native
>>>>>>>> clients, and I still prefer that approach. But I think it requires that
>>>>>>>> the native app set up its own client account with the authorization server,
>>>>>>>> which is outside the scope of the spec but certainly something that could
>>>>>>>> be done using DNOA.
>>>>>>>> --
>>>>>>>> Andrew Arnott
>>>>>>>> "I [may] not agree with what you have to say, but I'll defend to
>>>>>>>> the death your right to say it." - S. G. Tallentyre
>>>>>>>> On Mon, Jul 2, 2012 at 9:11 AM, Øyvind Sean Kinsey <
>>>>>>>> oyv...@kinsey.no> wrote:
>>>>>>>>> Are you trying to use OAuth2 in the context of a desktop
>>>>>>>>> application?
>>>>>>>>> If so then you have two main options, have the desktop app rely on
>>>>>>>>> a regular web app to do the token exchange, that way you can use the
>>>>>>>>> default way of exchanging codes/tokens, but this means that you need a
Hmm... Haven't entirely gotten to the bottom of this but on the reason why the DatabaseKeyNonceStore ISN'T failing as one would expect, it appears to be that OAuthAuthorizationServer\Global.asax.cs stores the DataClassesDataContext in HttpContext.Current.Items["DataContext"] which is kept only during an HTTP request<http://msdn.microsoft.com/en-us/library/system.web.httpcontext.items....>. I'm not sure if that was the intent or if the intent was to keep the context in say HttpContext.Current.Cache so it's available across requests (that where I've kept my custom implementation which surfaced this problem for me). In any case, my best guess right now is that the non-authenticated and authenticated requests to the token endpoint are spinning up two threads with two instances of the DataContext and the second request isn't quite aware of the first one... again, not really sure at this point (was just poking at it while watching a movie).
However, assuming the issue with the INonceStore is straightened out, requests to the DNOA token endpoint in the sample would presumably start failing as replay attacks. Is there a simple way to avoid calling into StoreNonce until the incoming request message has been checked for authorization? (I'm a newbie to DNOA so not really familiar with the pipeline...) I could open a bug for this if that's useful.
On Friday, August 31, 2012 5:41:17 PM UTC-6, Andrew Arnott wrote:
> Hi James,
> You've brought up an interesting point. Yes, if the nonce appears twice, > the first in a message without authentication and the second in a message > with it, then it seems the nonce should only be "consumed" the second time. > The fact that DNOA is consuming it both times sounds problematic. I don't > know why the sample is working in this case either. It's worth looking > more into. Do you have cycles to debug into it?
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - S. G. Tallentyre
> On Fri, Aug 31, 2012 at 10:10 AM, James Andersen <james.j....@gmail.com<javascript:>
> > wrote:
>> I've just been stuck on this as well... I ran into trouble because I >> found that first request failed for lack of an authentication header (as >> already noted) but then the second request (now authenticated) was failing >> because the INonceStore was returning false because the same entry was >> already recorded by the first request. For some reason the sample code >> (with the DatabaseKeyNonceStore) doesn't seem to have a problem with this >> even though the values passed to StoreNonce are exactly the same on both >> requests; my custom implementation was returning false on the second >> response which seems to be what it SHOULD do. Is this the expected >> behavior with StoreNonce? Should DNOA be calling StoreNonce twice for >> both the unauthenticated AND the authenticated request with the same values >> both times?
>> On Thursday, July 5, 2012 10:14:57 AM UTC-6, Andrew Arnott wrote:
>>> Yes, .NET makes it extremely difficult to include an HTTP Authorization >>> header in the initial request and requires the authenticate challenge >>> response first.
>>> Support for HTTP Basic client authentication is new in DNOA v4.1. The >>> MVC controller in the authorization server sample doesn't have an >>> [Authorize] attribute because DNOA handles it internally. If you step >>> through the OAuthClient and OAuthAuthorizationServer samples together, >>> you'll see the first request come in, get rejected with the error, and the >>> client will automatically retry applying the client credentials in the >>> Authorization header. This is how your app should presumably work as well.
>>> Alternatively you can simply use the old style method of applying client >>> id and secret inside your POST payload, but OAuth 2 strongly discourages >>> this.
>>> --
>>> Andrew Arnott
>>> "I [may] not agree with what you have to say, but I'll defend to the >>> death your right to say it." - S. G. Tallentyre
>>> On Tue, Jul 3, 2012 at 6:49 AM, Vadim D. <vad...@gmail.com> wrote:
>>>> I have continued to run the Fiddler and now I have another strange >>>> problem - I have server side exception in Token action that the client is >>>> not authenticated.
>>>> I have checked the reason and found that this is happening while server >>>> tries to authenticate the client from HTTP headers.
>>>> The problem is that .NET framework does not send this header when you >>>> do something like:
>>>> but instead it waits for server to reply with 401 and WWW-Authenticate<http://freesoft.org/CIE/RFC/1945/65.htm>header presented - only after this the proper authentication header will be >>>> sent. >>>> So it seems to me that I have to change somehow the Token action to >>>> require client authentication (your example of the server does not contains >>>> this)
>>>> Vadim
>>>> On Tuesday, July 3, 2012 9:48:34 AM UTC+3, Vadim D. wrote:
>>>>> Very strange, but after installing and running Fiddler everything >>>>> started to work ... I have checked again without Fiddler - not working
>>>>> On Tuesday, July 3, 2012 8:52:03 AM UTC+3, Vadim D. wrote:
>>>>>> Thanks you for your answers.
>>>>>> My authorization server supports client registration out-of-band so >>>>>> there is no problem with it.
>>>>>> I am using *OAuthConsumerWpf *in order to check the server side and >>>>>> I am using the Generic 2.0 tab with the following parameters:
>>>>>> I have stepped in into the *ClientAuthorizationView *source code in >>>>>> order to understand how the interception of the navigation happens and so >>>>>> it happens every time the event *WebBrowser1_Navigating* is pumped >>>>>> up. But somehow, when I have redirection from the AS with the code, the >>>>>> embedded browser pups up the event with wrong URL, so function *SignificantlyEqual >>>>>> *is always false.
>>>>>> If I put a breakpoint on *ProcessLocationChanged *in class *
>>>>>> ClientAuthorizationView*, these are the URLs I am getting:
>>>>>> The problem is that tha last URL should be the client's callback URL >>>>>> and it's never received by the embedded browser, although the server sent >>>>>> redirection in method *AuthorizeResponse*, where the code
>>>>>> is checking the client, checking the scope, adding new authorization >>>>>> to the DB and then returning with:
Thanks for the investigation. It sounds like as you say the sample is
buggy. Then DNOA has a bug that it shouldn't call StoreNonce until the
request has been otherwise authorized. This is a bug within the assembly
-- not with your configuration. Can you please file a
bug<http://bit.ly/dnoawish>with all this information?
Thanks.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre
On Mon, Sep 3, 2012 at 9:36 PM, James Andersen
<james.j.ander...@gmail.com>wrote:
> Hmm... Haven't entirely gotten to the bottom of this but on the reason
> why the DatabaseKeyNonceStore ISN'T failing as one would expect, it appears
> to be that OAuthAuthorizationServer\Global.asax.cs stores the
> DataClassesDataContext in HttpContext.Current.Items["DataContext"] which
> is kept only during an HTTP request<http://msdn.microsoft.com/en-us/library/system.web.httpcontext.items....>.
> I'm not sure if that was the intent or if the intent was to keep the
> context in say HttpContext.Current.Cache so it's available across requests
> (that where I've kept my custom implementation which surfaced this problem
> for me). In any case, my best guess right now is that the
> non-authenticated and authenticated requests to the token endpoint are
> spinning up two threads with two instances of the DataContext and the
> second request isn't quite aware of the first one... again, not really
> sure at this point (was just poking at it while watching a movie).
> However, assuming the issue with the INonceStore is straightened out,
> requests to the DNOA token endpoint in the sample would presumably start
> failing as replay attacks. Is there a simple way to avoid calling into
> StoreNonce until the incoming request message has been checked for
> authorization? (I'm a newbie to DNOA so not really familiar with the
> pipeline...) I could open a bug for this if that's useful.
> On Friday, August 31, 2012 5:41:17 PM UTC-6, Andrew Arnott wrote:
>> Hi James,
>> You've brought up an interesting point. Yes, if the nonce appears twice,
>> the first in a message without authentication and the second in a message
>> with it, then it seems the nonce should only be "consumed" the second time.
>> The fact that DNOA is consuming it both times sounds problematic. I don't
>> know why the sample is working in this case either. It's worth looking
>> more into. Do you have cycles to debug into it?
>> --
>> Andrew Arnott
>> "I [may] not agree with what you have to say, but I'll defend to the
>> death your right to say it." - S. G. Tallentyre
>> On Fri, Aug 31, 2012 at 10:10 AM, James Andersen <james.j....@gmail.com>wrote:
>>> I've just been stuck on this as well... I ran into trouble because I
>>> found that first request failed for lack of an authentication header (as
>>> already noted) but then the second request (now authenticated) was failing
>>> because the INonceStore was returning false because the same entry was
>>> already recorded by the first request. For some reason the sample code
>>> (with the DatabaseKeyNonceStore) doesn't seem to have a problem with this
>>> even though the values passed to StoreNonce are exactly the same on both
>>> requests; my custom implementation was returning false on the second
>>> response which seems to be what it SHOULD do. Is this the expected
>>> behavior with StoreNonce? Should DNOA be calling StoreNonce twice for
>>> both the unauthenticated AND the authenticated request with the same values
>>> both times?
>>> On Thursday, July 5, 2012 10:14:57 AM UTC-6, Andrew Arnott wrote:
>>>> Yes, .NET makes it extremely difficult to include an HTTP Authorization
>>>> header in the initial request and requires the authenticate challenge
>>>> response first.
>>>> Support for HTTP Basic client authentication is new in DNOA v4.1. The
>>>> MVC controller in the authorization server sample doesn't have an
>>>> [Authorize] attribute because DNOA handles it internally. If you step
>>>> through the OAuthClient and OAuthAuthorizationServer samples together,
>>>> you'll see the first request come in, get rejected with the error, and the
>>>> client will automatically retry applying the client credentials in the
>>>> Authorization header. This is how your app should presumably work as well.
>>>> Alternatively you can simply use the old style method of applying
>>>> client id and secret inside your POST payload, but OAuth 2 strongly
>>>> discourages this.
>>>> --
>>>> Andrew Arnott
>>>> "I [may] not agree with what you have to say, but I'll defend to the
>>>> death your right to say it." - S. G. Tallentyre
>>>> On Tue, Jul 3, 2012 at 6:49 AM, Vadim D. <vad...@gmail.com> wrote:
>>>>> I have continued to run the Fiddler and now I have another strange
>>>>> problem - I have server side exception in Token action that the client is
>>>>> not authenticated.
>>>>> I have checked the reason and found that this is happening while
>>>>> server tries to authenticate the client from HTTP headers.
>>>>> The problem is that .NET framework does not send this header when you
>>>>> do something like:
>>>>> but instead it waits for server to reply with 401 and WWW-Authenticate<http://freesoft.org/CIE/RFC/1945/65.htm>header presented - only after this the proper authentication header will be
>>>>> sent.
>>>>> So it seems to me that I have to change somehow the Token action to
>>>>> require client authentication (your example of the server does not contains
>>>>> this)
>>>>> Vadim
>>>>> On Tuesday, July 3, 2012 9:48:34 AM UTC+3, Vadim D. wrote:
>>>>>> Very strange, but after installing and running Fiddler everything
>>>>>> started to work ... I have checked again without Fiddler - not working
>>>>>> On Tuesday, July 3, 2012 8:52:03 AM UTC+3, Vadim D. wrote:
>>>>>>> Thanks you for your answers.
>>>>>>> My authorization server supports client registration out-of-band so
>>>>>>> there is no problem with it.
>>>>>>> I am using *OAuthConsumerWpf *in order to check the server side
>>>>>>> and I am using the Generic 2.0 tab with the following parameters:
>>>>>>> I have stepped in into the *ClientAuthorizationView *source code in
>>>>>>> order to understand how the interception of the navigation happens and so
>>>>>>> it happens every time the event *WebBrowser1_Navigating* is pumped
>>>>>>> up. But somehow, when I have redirection from the AS with the code, the
>>>>>>> embedded browser pups up the event with wrong URL, so function *SignificantlyEqual
>>>>>>> *is always false.
>>>>>>> If I put a breakpoint on *ProcessLocationChanged *in class *
>>>>>>> ClientAuthorizationView*, these are the URLs I am getting:
>>>>>>> The problem is that tha last URL should be the client's callback URL
>>>>>>> and it's never received by the embedded browser, although the server sent
On Tuesday, September 4, 2012 8:16:08 AM UTC-6, Andrew Arnott wrote:
> James,
> Thanks for the investigation. It sounds like as you say the sample is > buggy. Then DNOA has a bug that it shouldn't call StoreNonce until the > request has been otherwise authorized. This is a bug within the assembly > -- not with your configuration. Can you please file a bug<http://bit.ly/dnoawish>with all this information?
> Thanks.
> --
> Andrew Arnott
> "I [may] not agree with what you have to say, but I'll defend to the death > your right to say it." - S. G. Tallentyre
> On Mon, Sep 3, 2012 at 9:36 PM, James Andersen <james.j....@gmail.com<javascript:>
> > wrote:
>> Hmm... Haven't entirely gotten to the bottom of this but on the reason >> why the DatabaseKeyNonceStore ISN'T failing as one would expect, it appears >> to be that OAuthAuthorizationServer\Global.asax.cs stores the >> DataClassesDataContext in HttpContext.Current.Items["DataContext"] which >> is kept only during an HTTP request<http://msdn.microsoft.com/en-us/library/system.web.httpcontext.items....>. >> I'm not sure if that was the intent or if the intent was to keep the >> context in say HttpContext.Current.Cache so it's available across requests >> (that where I've kept my custom implementation which surfaced this problem >> for me). In any case, my best guess right now is that the >> non-authenticated and authenticated requests to the token endpoint are >> spinning up two threads with two instances of the DataContext and the >> second request isn't quite aware of the first one... again, not really >> sure at this point (was just poking at it while watching a movie).
>> However, assuming the issue with the INonceStore is straightened out, >> requests to the DNOA token endpoint in the sample would presumably start >> failing as replay attacks. Is there a simple way to avoid calling into >> StoreNonce until the incoming request message has been checked for >> authorization? (I'm a newbie to DNOA so not really familiar with the >> pipeline...) I could open a bug for this if that's useful.
>> On Friday, August 31, 2012 5:41:17 PM UTC-6, Andrew Arnott wrote:
>>> Hi James,
>>> You've brought up an interesting point. Yes, if the nonce appears >>> twice, the first in a message without authentication and the second in a >>> message with it, then it seems the nonce should only be "consumed" the >>> second time. The fact that DNOA is consuming it both times sounds >>> problematic. I don't know why the sample is working in this case either. >>> It's worth looking more into. Do you have cycles to debug into it?
>>> --
>>> Andrew Arnott
>>> "I [may] not agree with what you have to say, but I'll defend to the >>> death your right to say it." - S. G. Tallentyre
>>> On Fri, Aug 31, 2012 at 10:10 AM, James Andersen <james.j....@gmail.com>wrote:
>>>> I've just been stuck on this as well... I ran into trouble because I >>>> found that first request failed for lack of an authentication header (as >>>> already noted) but then the second request (now authenticated) was failing >>>> because the INonceStore was returning false because the same entry was >>>> already recorded by the first request. For some reason the sample code >>>> (with the DatabaseKeyNonceStore) doesn't seem to have a problem with this >>>> even though the values passed to StoreNonce are exactly the same on both >>>> requests; my custom implementation was returning false on the second >>>> response which seems to be what it SHOULD do. Is this the expected >>>> behavior with StoreNonce? Should DNOA be calling StoreNonce twice for >>>> both the unauthenticated AND the authenticated request with the same values >>>> both times?
>>>> On Thursday, July 5, 2012 10:14:57 AM UTC-6, Andrew Arnott wrote:
>>>>> Yes, .NET makes it extremely difficult to include an HTTP >>>>> Authorization header in the initial request and requires the authenticate >>>>> challenge response first.
>>>>> Support for HTTP Basic client authentication is new in DNOA v4.1. The >>>>> MVC controller in the authorization server sample doesn't have an >>>>> [Authorize] attribute because DNOA handles it internally. If you step >>>>> through the OAuthClient and OAuthAuthorizationServer samples together, >>>>> you'll see the first request come in, get rejected with the error, and the >>>>> client will automatically retry applying the client credentials in the >>>>> Authorization header. This is how your app should presumably work as well.
>>>>> Alternatively you can simply use the old style method of applying >>>>> client id and secret inside your POST payload, but OAuth 2 strongly >>>>> discourages this.
>>>>> --
>>>>> Andrew Arnott
>>>>> "I [may] not agree with what you have to say, but I'll defend to the >>>>> death your right to say it." - S. G. Tallentyre
>>>>> On Tue, Jul 3, 2012 at 6:49 AM, Vadim D. <vad...@gmail.com> wrote:
>>>>>> I have continued to run the Fiddler and now I have another strange >>>>>> problem - I have server side exception in Token action that the client is >>>>>> not authenticated.
>>>>>> I have checked the reason and found that this is happening while >>>>>> server tries to authenticate the client from HTTP headers.
>>>>>> The problem is that .NET framework does not send this header when you >>>>>> do something like:
>>>>>> but instead it waits for server to reply with 401 and >>>>>> WWW-Authenticate <http://freesoft.org/CIE/RFC/1945/65.htm> header >>>>>> presented - only after this the proper authentication header will be sent. >>>>>> So it seems to me that I have to change somehow the Token action to >>>>>> require client authentication (your example of the server does not contains >>>>>> this)
>>>>>> Vadim
>>>>>> On Tuesday, July 3, 2012 9:48:34 AM UTC+3, Vadim D. wrote:
>>>>>>> Very strange, but after installing and running Fiddler everything >>>>>>> started to work ... I have checked again without Fiddler - not working
>>>>>>> On Tuesday, July 3, 2012 8:52:03 AM UTC+3, Vadim D. wrote:
>>>>>>>> Thanks you for your answers.
>>>>>>>> My authorization server supports client registration out-of-band so >>>>>>>> there is no problem with it.
>>>>>>>> I am using *OAuthConsumerWpf *in order to check the server side
>>>>>>>> and I am using the Generic 2.0 tab with the following parameters:
>>>>>>>> I have stepped in into the *ClientAuthorizationView *source code >>>>>>>> in order to understand how the interception of the navigation happens and >>>>>>>> so it happens every time the event *WebBrowser1_Navigating* is >>>>>>>> pumped up. But somehow, when I have redirection from the AS with the code, >>>>>>>> the embedded browser pups up the event with wrong URL, so function >>>>>>>> *SignificantlyEqual *is always false.
>>>>>>>> If I put a breakpoint on *ProcessLocationChanged *in class *
>>>>>>>> ClientAuthorizationView*, these are the URLs I am getting:
>>>>>>>> - http://localhost:42411/OAuth/**A**** >>>>>>>> uthorize?client_id=CADC23ED-**57****BD-4342-BC2D-2C4D1B002B91&**
>>>>>>>> redi****rect_uri=http:%2F%**2Flocalhost%****2F&scope=http:%2F%**
>>>>>>>> 2Flocalhost%****2Fapi%2Fa&**response_type=code - this is the >>>>>>>> request for the authorization of the client with the callback
>>>>>>>> <http://localhost:42411/OAuth/Authorize?client_id=CADC23ED-57BD-4342-B...>
>>>>>>>> - http://localhost:42411/**Account****/LogOn?ReturnUrl=%** >>>>>>>> 2fOAuth%**2fAu**thorize%3fclient_**id%**3dCADC23ED**
>>>>>>>> -57BD-4342-BC2D-**2C4D**1B002B91%**26redirect_uri%**3dhttp**
>>>>>>>> %253A%**252F%**252Flocalhost%252F%**26scop**e%**
>>>>>>>> 3dhttp%253A%252F%**252Fl**ocalho**st%252Fapi%252Fa%**26respo**
>>>>>>>> nse_**type%3dcode&client_**id=**CADC23ED**-57BD-4342-BC2D-**
>>>>>>>> 2C4D1B**002B91&**redirect_uri=**http:%2F%**2Flocalh**
>>>>>>>> ost%2F&scope=**http:%2F%**2Flocalh**ost%2Fapi%**2Fa&**
>>>>>>>> response_type=**code - this is ASP.NET forms redirection to >>>>>>>> user login page
>>>>>>>> <http://localhost:42411/Account/LogOn?ReturnUrl=%2fOAuth%2fAuthorize%3...>
>>>>>>>> - http://localhost:42411/OAuth/**A**** >>>>>>>> uthorize?client_id=CADC23ED-**57****BD-4342-BC2D-2C4D1B002B91&**
>>>>>>>> redi****rect_uri=http:%2F%**2Flocalhost%****2F&scope=http:%2F%**
I've done a bit more debugging on why the sample ISN'T failing and noted my findings in the github issue. Briefly, it looks like the unauthenticated request causes the error handler in the ASP.NET pipeline to trigger which rolls back the transaction on which INonceStore.StoreNonce attempts to write the nonce the first time. This implementation of INonceStore happens to accommodate the challenge/response flow well because of the rollback but it seems like a fortunate kludge as other implementations of INonceStore (like the in-memory one I was playing with earlier) would fail.
> On Tuesday, September 4, 2012 8:16:08 AM UTC-6, Andrew Arnott wrote:
>> James,
>> Thanks for the investigation. It sounds like as you say the sample is >> buggy. Then DNOA has a bug that it shouldn't call StoreNonce until the >> request has been otherwise authorized. This is a bug within the assembly >> -- not with your configuration. Can you please file a bug<http://bit.ly/dnoawish>with all this information?
>> Thanks.
>> --
>> Andrew Arnott
>> "I [may] not agree with what you have to say, but I'll defend to the >> death your right to say it." - S. G. Tallentyre
>> On Mon, Sep 3, 2012 at 9:36 PM, James Andersen <james.j....@gmail.com>wrote:
>>> Hmm... Haven't entirely gotten to the bottom of this but on the reason >>> why the DatabaseKeyNonceStore ISN'T failing as one would expect, it appears >>> to be that OAuthAuthorizationServer\Global.asax.cs stores the >>> DataClassesDataContext in HttpContext.Current.Items["DataContext"] >>> which is kept only during an HTTP request<http://msdn.microsoft.com/en-us/library/system.web.httpcontext.items....>. >>> I'm not sure if that was the intent or if the intent was to keep the >>> context in say HttpContext.Current.Cache so it's available across requests >>> (that where I've kept my custom implementation which surfaced this problem >>> for me). In any case, my best guess right now is that the >>> non-authenticated and authenticated requests to the token endpoint are >>> spinning up two threads with two instances of the DataContext and the >>> second request isn't quite aware of the first one... again, not really >>> sure at this point (was just poking at it while watching a movie).
>>> However, assuming the issue with the INonceStore is straightened out, >>> requests to the DNOA token endpoint in the sample would presumably start >>> failing as replay attacks. Is there a simple way to avoid calling into >>> StoreNonce until the incoming request message has been checked for >>> authorization? (I'm a newbie to DNOA so not really familiar with the >>> pipeline...) I could open a bug for this if that's useful.
>>> On Friday, August 31, 2012 5:41:17 PM UTC-6, Andrew Arnott wrote:
>>>> Hi James,
>>>> You've brought up an interesting point. Yes, if the nonce appears >>>> twice, the first in a message without authentication and the second in a >>>> message with it, then it seems the nonce should only be "consumed" the >>>> second time. The fact that DNOA is consuming it both times sounds >>>> problematic. I don't know why the sample is working in this case either. >>>> It's worth looking more into. Do you have cycles to debug into it?
>>>> --
>>>> Andrew Arnott
>>>> "I [may] not agree with what you have to say, but I'll defend to the >>>> death your right to say it." - S. G. Tallentyre
>>>> On Fri, Aug 31, 2012 at 10:10 AM, James Andersen <james.j....@gmail.com
>>>> > wrote:
>>>>> I've just been stuck on this as well... I ran into trouble because I >>>>> found that first request failed for lack of an authentication header (as >>>>> already noted) but then the second request (now authenticated) was failing >>>>> because the INonceStore was returning false because the same entry was >>>>> already recorded by the first request. For some reason the sample code >>>>> (with the DatabaseKeyNonceStore) doesn't seem to have a problem with this >>>>> even though the values passed to StoreNonce are exactly the same on both >>>>> requests; my custom implementation was returning false on the second >>>>> response which seems to be what it SHOULD do. Is this the expected >>>>> behavior with StoreNonce? Should DNOA be calling StoreNonce twice for >>>>> both the unauthenticated AND the authenticated request with the same values >>>>> both times?
>>>>> On Thursday, July 5, 2012 10:14:57 AM UTC-6, Andrew Arnott wrote:
>>>>>> Yes, .NET makes it extremely difficult to include an HTTP >>>>>> Authorization header in the initial request and requires the authenticate >>>>>> challenge response first.
>>>>>> Support for HTTP Basic client authentication is new in DNOA v4.1. >>>>>> The MVC controller in the authorization server sample doesn't have an >>>>>> [Authorize] attribute because DNOA handles it internally. If you step >>>>>> through the OAuthClient and OAuthAuthorizationServer samples together, >>>>>> you'll see the first request come in, get rejected with the error, and the >>>>>> client will automatically retry applying the client credentials in the >>>>>> Authorization header. This is how your app should presumably work as well.
>>>>>> Alternatively you can simply use the old style method of applying >>>>>> client id and secret inside your POST payload, but OAuth 2 strongly >>>>>> discourages this.
>>>>>> --
>>>>>> Andrew Arnott
>>>>>> "I [may] not agree with what you have to say, but I'll defend to the >>>>>> death your right to say it." - S. G. Tallentyre
>>>>>> On Tue, Jul 3, 2012 at 6:49 AM, Vadim D. <vad...@gmail.com> wrote:
>>>>>>> I have continued to run the Fiddler and now I have another strange >>>>>>> problem - I have server side exception in Token action that the client is >>>>>>> not authenticated.
>>>>>>> I have checked the reason and found that this is happening while >>>>>>> server tries to authenticate the client from HTTP headers.
>>>>>>> The problem is that .NET framework does not send this header when >>>>>>> you do something like:
>>>>>>> but instead it waits for server to reply with 401 and >>>>>>> WWW-Authenticate <http://freesoft.org/CIE/RFC/1945/65.htm> header >>>>>>> presented - only after this the proper authentication header will be sent. >>>>>>> So it seems to me that I have to change somehow the Token action to >>>>>>> require client authentication (your example of the server does not contains >>>>>>> this)
>>>>>>> Vadim
>>>>>>> On Tuesday, July 3, 2012 9:48:34 AM UTC+3, Vadim D. wrote:
>>>>>>>> Very strange, but after installing and running Fiddler everything >>>>>>>> started to work ... I have checked again without Fiddler - not working
>>>>>>>> On Tuesday, July 3, 2012 8:52:03 AM UTC+3, Vadim D. wrote:
>>>>>>>>> Thanks you for your answers.
>>>>>>>>> My authorization server supports client registration out-of-band >>>>>>>>> so there is no problem with it.
>>>>>>>>> I am using *OAuthConsumerWpf *in order to check the server side
>>>>>>>>> and I am using the Generic 2.0 tab with the following parameters:
>>>>>>>>> I have stepped in into the *ClientAuthorizationView *source code >>>>>>>>> in order to understand how the interception of the navigation happens and >>>>>>>>> so it happens every time the event *WebBrowser1_Navigating* is >>>>>>>>> pumped up. But somehow, when I have redirection from the AS with the code, >>>>>>>>> the embedded browser pups up the event with wrong URL, so function >>>>>>>>> *SignificantlyEqual *is always false.
>>>>>>>>> If I put a breakpoint on *ProcessLocationChanged *in class *
>>>>>>>>> ClientAuthorizationView*, these are the URLs I am getting:
>>>>>>>>> - http://localhost:42411/OAuth/**A**** >>>>>>>>> uthorize?client_id=CADC23ED-**57****BD-4342-BC2D-2C4D1B002B91&*
>>>>>>>>> *redi****rect_uri=http:%2F%**2Flocalhost%****2F&scope=http:%2F%
>>>>>>>>> **2Flocalhost%****2Fapi%2Fa&**response_type=code - this is the >>>>>>>>> request for the authorization of the client with the callback
>>>>>>>>> <http://localhost:42411/OAuth/Authorize?client_id=CADC23ED-57BD-4342-B...>
>>>>>>>>> - http://localhost:42411/**Account****/LogOn?ReturnUrl=%** >>>>>>>>> 2fOAuth%**2fAu**thorize%3fclient_**id%**3dCADC23ED**
>>>>>>>>> -57BD-4342-BC2D-**2C4D**1B002B91%**26redirect_uri%**3dhttp**
>>>>>>>>> %253A%**252F%**252Flocalhost%252F%**26scop**e%**
>>>>>>>>> 3dhttp%253A%252F%**252Fl**ocalho**st%252Fapi%252Fa%**26respo**
>>>>>>>>> nse_**type%3dcode&client_**id=**CADC23ED**-57BD-4342-BC2D-**
> wrote:
> I've done a bit more debugging on why the sample ISN'T failing and noted
> my findings in the github issue. Briefly, it looks like the
> unauthenticated request causes the error handler in the ASP.NET pipeline
> to trigger which rolls back the transaction on which INonceStore.StoreNonce
> attempts to write the nonce the first time. This implementation of
> INonceStore happens to accommodate the challenge/response flow well because
> of the rollback but it seems like a fortunate kludge as other
> implementations of INonceStore (like the in-memory one I was playing with
> earlier) would fail.
> On Tuesday, September 4, 2012 8:58:36 AM UTC-6, James Andersen wrote:
>> On Tuesday, September 4, 2012 8:16:08 AM UTC-6, Andrew Arnott wrote:
>>> James,
>>> Thanks for the investigation. It sounds like as you say the sample is
>>> buggy. Then DNOA has a bug that it shouldn't call StoreNonce until the
>>> request has been otherwise authorized. This is a bug within the assembly
>>> -- not with your configuration. Can you please file a bug<http://bit.ly/dnoawish>with all this information?
>>> Thanks.
>>> --
>>> Andrew Arnott
>>> "I [may] not agree with what you have to say, but I'll defend to the
>>> death your right to say it." - S. G. Tallentyre
>>> On Mon, Sep 3, 2012 at 9:36 PM, James Andersen <james.j....@gmail.com>wrote:
>>>> Hmm... Haven't entirely gotten to the bottom of this but on the reason
>>>> why the DatabaseKeyNonceStore ISN'T failing as one would expect, it appears
>>>> to be that OAuthAuthorizationServer\**Global.asax.cs stores the
>>>> DataClassesDataContext in HttpContext.Current.Items["**DataContext"]
>>>> which is kept only during an HTTP request<http://msdn.microsoft.com/en-us/library/system.web.httpcontext.items....>.
>>>> I'm not sure if that was the intent or if the intent was to keep the
>>>> context in say HttpContext.Current.Cache so it's available across requests
>>>> (that where I've kept my custom implementation which surfaced this problem
>>>> for me). In any case, my best guess right now is that the
>>>> non-authenticated and authenticated requests to the token endpoint are
>>>> spinning up two threads with two instances of the DataContext and the
>>>> second request isn't quite aware of the first one... again, not really
>>>> sure at this point (was just poking at it while watching a movie).
>>>> However, assuming the issue with the INonceStore is straightened out,
>>>> requests to the DNOA token endpoint in the sample would presumably start
>>>> failing as replay attacks. Is there a simple way to avoid calling into
>>>> StoreNonce until the incoming request message has been checked for
>>>> authorization? (I'm a newbie to DNOA so not really familiar with the
>>>> pipeline...) I could open a bug for this if that's useful.
>>>> On Friday, August 31, 2012 5:41:17 PM UTC-6, Andrew Arnott wrote:
>>>>> Hi James,
>>>>> You've brought up an interesting point. Yes, if the nonce appears
>>>>> twice, the first in a message without authentication and the second in a
>>>>> message with it, then it seems the nonce should only be "consumed" the
>>>>> second time. The fact that DNOA is consuming it both times sounds
>>>>> problematic. I don't know why the sample is working in this case either.
>>>>> It's worth looking more into. Do you have cycles to debug into it?
>>>>> --
>>>>> Andrew Arnott
>>>>> "I [may] not agree with what you have to say, but I'll defend to the
>>>>> death your right to say it." - S. G. Tallentyre
>>>>> On Fri, Aug 31, 2012 at 10:10 AM, James Andersen <
>>>>> james.j....@gmail.com> wrote:
>>>>>> I've just been stuck on this as well... I ran into trouble because
>>>>>> I found that first request failed for lack of an authentication header (as
>>>>>> already noted) but then the second request (now authenticated) was failing
>>>>>> because the INonceStore was returning false because the same entry was
>>>>>> already recorded by the first request. For some reason the sample code
>>>>>> (with the DatabaseKeyNonceStore) doesn't seem to have a problem with this
>>>>>> even though the values passed to StoreNonce are exactly the same on both
>>>>>> requests; my custom implementation was returning false on the second
>>>>>> response which seems to be what it SHOULD do. Is this the expected
>>>>>> behavior with StoreNonce? Should DNOA be calling StoreNonce twice for
>>>>>> both the unauthenticated AND the authenticated request with the same values
>>>>>> both times?
>>>>>> On Thursday, July 5, 2012 10:14:57 AM UTC-6, Andrew Arnott wrote:
>>>>>>> Yes, .NET makes it extremely difficult to include an HTTP
>>>>>>> Authorization header in the initial request and requires the authenticate
>>>>>>> challenge response first.
>>>>>>> Support for HTTP Basic client authentication is new in DNOA v4.1.
>>>>>>> The MVC controller in the authorization server sample doesn't have an
>>>>>>> [Authorize] attribute because DNOA handles it internally. If you step
>>>>>>> through the OAuthClient and OAuthAuthorizationServer samples together,
>>>>>>> you'll see the first request come in, get rejected with the error, and the
>>>>>>> client will automatically retry applying the client credentials in the
>>>>>>> Authorization header. This is how your app should presumably work as well.
>>>>>>> Alternatively you can simply use the old style method of applying
>>>>>>> client id and secret inside your POST payload, but OAuth 2 strongly
>>>>>>> discourages this.
>>>>>>> --
>>>>>>> Andrew Arnott
>>>>>>> "I [may] not agree with what you have to say, but I'll defend to the
>>>>>>> death your right to say it." - S. G. Tallentyre
>>>>>>> On Tue, Jul 3, 2012 at 6:49 AM, Vadim D. <vad...@gmail.com> wrote:
>>>>>>>> I have continued to run the Fiddler and now I have another strange
>>>>>>>> problem - I have server side exception in Token action that the client is
>>>>>>>> not authenticated.
>>>>>>>> I have checked the reason and found that this is happening while
>>>>>>>> server tries to authenticate the client from HTTP headers.
>>>>>>>> The problem is that .NET framework does not send this header when
>>>>>>>> you do something like:
>>>>>>>> but instead it waits for server to reply with 401 and
>>>>>>>> WWW-Authenticate <http://freesoft.org/CIE/RFC/1945/65.htm> header
>>>>>>>> presented - only after this the proper authentication header will be sent.
>>>>>>>> So it seems to me that I have to change somehow the Token action to
>>>>>>>> require client authentication (your example of the server does not contains
>>>>>>>> this)
>>>>>>>> Vadim
>>>>>>>> On Tuesday, July 3, 2012 9:48:34 AM UTC+3, Vadim D. wrote:
>>>>>>>>> Very strange, but after installing and running Fiddler everything
>>>>>>>>> started to work ... I have checked again without Fiddler - not working
>>>>>>>>> On Tuesday, July 3, 2012 8:52:03 AM UTC+3, Vadim D. wrote:
>>>>>>>>>> Thanks you for your answers.
>>>>>>>>>> My authorization server supports client registration out-of-band
>>>>>>>>>> so there is no problem with it.
>>>>>>>>>> I am using *OAuthConsumerWpf *in order to check the server side
>>>>>>>>>> and I am using the Generic 2.0 tab with the following parameters:
>>>>>>>>>> I have stepped in into the *ClientAuthorizationView *source code
>>>>>>>>>> in order to understand how the interception of the navigation happens and
>>>>>>>>>> so it happens every time the event *WebBrowser1_Navigating* is
>>>>>>>>>> pumped up. But somehow, when I have redirection from the AS with the code,
>>>>>>>>>> the embedded browser pups up the event with wrong URL, so function
>>>>>>>>>> *SignificantlyEqual *is always false.
>>>>>>>>>> If I put a breakpoint on *ProcessLocationChanged *in class *
>>>>>>>>>> ClientAuthorizationView*, these are the URLs I am getting:
>>>>>>>>>> - http://localhost:42411/OAuth/**A****** >>>>>>>>>> uthorize?client_id=CADC23ED-**57******
>>>>>>>>>> BD-4342-BC2D-2C4D1B002B91&**redi******rect_uri=http:%2F%**
>>>>>>>>>> 2Flocalhost%******2F&scope=http:%2F%**2Flocalhost%******
>>>>>>>>>> 2Fapi%2Fa&**response_type=code - this is the request for the
>>>>>>>>>> authorization of the client with the callback