The OAuthAuthorizationServer and OAuthResourceServer samples that you can
get from http://sourceforge.net/projects/dnoa/files/latest/ should
outline how to build the server(s). They don't demonstrate a resource
owner password grant but that should hopefully be a straightforward
addition.
It appears that you're sending the user credentials to the authorization
endpoint, which is incorrect. You should send these to the *token* endpoint
instead.
As for the HTTPS requirement, DNOA *should *be honoring the web.config
setting but maybe that bit is buggy. Can you include your web.config file
so I can check it for accuracy? (be sure to scrub it of any confidential
data)
--
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 24, 2012 at 2:47 PM, Rich Miller <richmiller...@gmail.com>wrote:
> Just getting started with DNOA and trying to implement a very simple
> OAuth2 Authorization server for an API using the Resource Owner Password
> Flow (client app asks the resource owner to enter credentials and passes
> them to an Authorize request along with the client ID and client secret).
> I've been looking at a bit of the sample code, but it's not clear to me
> what the basic steps are to implement an Authorization server -- if indeed
> that is what I need -- and how to translate some of the OAuth2 workflows
> into working code using the library. Can someone point me to something
> like an overview that might help me to understand the workflow of a
> DotNetOpenAuth implementation? I have the RFC and a starter book on
> OAuth2, but the terminology in those docs vs. the sample code and help file
> are not consistent.
> Also, I have managed to get a basic MVC controller working that will
> receive a form-urlencoded set of credentials from a Fiddler client. My
> request looks like:
> When the action method on the server calls ReadAuthorizationRequest(), I
> am getting the exception "This message can only be sent over HTTPS." I
> read in another post that setting an attribute on the messaging section in
> web.config called relaxSslRequirements to true would solve that, but it has
> had no effect, and I cannot find any documentation of the config parameters
> and what they mean.
> Thanks, everyone!
> Rich
> --
> 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/-/YjqNsMU8-oYJ.
> 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.
Thanks for the response. I'll admit to being really new to all of this -- both OAuth2 and DNOA -- and I guess one thing that has me a bit confused at this point regarding DNOA. Could you explain in general terms what the role of each of the server types is? Is the use of the Authorization server appropriate and the name of the endpoint wrong? What function does a Resource Server perform? If the client has received an access token from the Authorization server, wouldn't I simply need to validate the token when the client requested a resource from my API?
Here is my web.config dotnetopenauth section. Nothing really special here, since I just did a copy and paste from the docs on the web. The only change is in the messaging element where I added the relaxSslRequirements attribute and changed the strict attribute's value to false. The latter was just a guess on my part since there was really no place I could look other than diving into the source to see the effect the values have. The relaxSslRequirements idea came from another post in the forums.
unsolicitedAssertionVerification="RequireSuccess|LogWarningOnFailure|NeverV erify" minimumHashBitLength="160" maximumHashBitLength="512"> <associations> <add type="HMAC-SHA1" lifetime="14.00:00:00" /> <add type="HMAC-SHA256" lifetime="14.00:00:00" /> </associations> </security> <behaviors> <!-- <add type="Fully.Qualified.ClassName, Assembly" /> --> </behaviors> <!--<store type="Fully.Qualified.ClassName, Assembly" />--> </provider> <xriResolver enabled="true" proxy="xri.net" /> </openid> <messaging clockSkew="00:10:00" lifetime="00:03:00" strict="false" relaxSslRequirements="true"> <untrustedWebRequest timeout="00:00:10" readWriteTimeout="00:00:01.500" maximumBytesToRead="1048576" maximumRedirections="10"> <whitelistHosts> <!-- since this is a sample, and will often be used with localhost --> <!-- <add name="localhost" /> --> </whitelistHosts> <whitelistHostsRegex> <!-- since this is a sample, and will often be used with localhost --> <!-- <add name="\.owndomain\.com$" /> --> </whitelistHostsRegex> <blacklistHosts> </blacklistHosts> <blacklistHostsRegex> </blacklistHostsRegex> </untrustedWebRequest> </messaging> </dotNetOpenAuth>
On Tuesday, July 24, 2012 8:19:51 PM UTC-4, Andrew Arnott wrote:
> The OAuthAuthorizationServer and OAuthResourceServer samples that you can > get from http://sourceforge.net/projects/dnoa/files/latest/ should > outline how to build the server(s). They don't demonstrate a resource > owner password grant but that should hopefully be a straightforward > addition.
> It appears that you're sending the user credentials to the authorization > endpoint, which is incorrect. You should send these to the *token* endpoint > instead.
> As for the HTTPS requirement, DNOA *should *be honoring the web.config > setting but maybe that bit is buggy. Can you include your web.config file > so I can check it for accuracy? (be sure to scrub it of any confidential > data) > -- > 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 24, 2012 at 2:47 PM, Rich Miller <richmiller...@gmail.com>wrote:
>> Hi folks!
>> Just getting started with DNOA and trying to implement a very simple >> OAuth2 Authorization server for an API using the Resource Owner Password >> Flow (client app asks the resource owner to enter credentials and passes >> them to an Authorize request along with the client ID and client secret). >> I've been looking at a bit of the sample code, but it's not clear to me >> what the basic steps are to implement an Authorization server -- if indeed >> that is what I need -- and how to translate some of the OAuth2 workflows >> into working code using the library. Can someone point me to something >> like an overview that might help me to understand the workflow of a >> DotNetOpenAuth implementation? I have the RFC and a starter book on >> OAuth2, but the terminology in those docs vs. the sample code and help file >> are not consistent.
>> Also, I have managed to get a basic MVC controller working that will >> receive a form-urlencoded set of credentials from a Fiddler client. My >> request looks like:
>> When the action method on the server calls ReadAuthorizationRequest(), I >> am getting the exception "This message can only be sent over HTTPS." I >> read in another post that setting an attribute on the messaging section in >> web.config called relaxSslRequirements to true would solve that, but it has >> had no effect, and I cannot find any documentation of the config parameters >> and what they mean.
>> Thanks, everyone!
>> Rich
>> -- >> 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/-/YjqNsMU8-oYJ. >> 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.
So I've found some other samples and I've been trying to hit the token endpoint as suggested in your previous post. My Controller code looks a bit like this now, which is pretty much straight from the samples:
Public Class OAuth2Controller Inherits System.Web.Mvc.Controller
Private ReadOnly authServer As AuthorizationServer = New AuthorizationServer(New RCCAuthorizationServer())
Public Function Token() As ActionResult Return authServer.HandleTokenRequest(Request).AsActionResult() End Function
End Class
My RCCAuthorizationServer host implements the interface, but at this point the interface implementation methods are just dummy methods with a lot of breakpoints so I can see the sequence of calls that are being made when HandleTokenRequest is called. Unfortunately none of the breakpoints are ever hit. I am guessing this is because I need to tell the authorization server somewhere what host to use, but I thought that might have happened when I newed up the Authorization server with the new instance of the host in the Private line above.
My web.config dotnetopenauth section looks like this now:
<dotNetOpenAuth> <!-- Allow DotNetOpenAuth to publish usage statistics to library authors to improve the library. --> <reporting enabled="true" /> <oauth2> <authorizationServer> </authorizationServer> </oauth2>
<!-- Relaxing SSL requirements is useful for simple samples, but NOT a good idea in production. --> <messaging relaxSslRequirements="true"> <untrustedWebRequest> <whitelistHosts> <!-- since this is a sample, and will often be used with localhost --> <add name="localhost"/> </whitelistHosts> </untrustedWebRequest> </messaging> </dotNetOpenAuth>
I am assuming that I might need to specify something in the authorization server element under the oauth2 element? So far, I can't find any example code where this element is not empty.
Probably sounds like I could use a good tutorial. Maybe if this message thread gets long enough and produces results we can turn it into one... :-)
On Tuesday, July 24, 2012 8:19:51 PM UTC-4, Andrew Arnott wrote:
> The OAuthAuthorizationServer and OAuthResourceServer samples that you can > get from http://sourceforge.net/projects/dnoa/files/latest/ should > outline how to build the server(s). They don't demonstrate a resource > owner password grant but that should hopefully be a straightforward > addition.
> It appears that you're sending the user credentials to the authorization > endpoint, which is incorrect. You should send these to the *token* endpoint > instead.
> As for the HTTPS requirement, DNOA *should *be honoring the web.config > setting but maybe that bit is buggy. Can you include your web.config file > so I can check it for accuracy? (be sure to scrub it of any confidential > data) > -- > 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 24, 2012 at 2:47 PM, Rich Miller <richmiller...@gmail.com>wrote:
>> Hi folks!
>> Just getting started with DNOA and trying to implement a very simple >> OAuth2 Authorization server for an API using the Resource Owner Password >> Flow (client app asks the resource owner to enter credentials and passes >> them to an Authorize request along with the client ID and client secret). >> I've been looking at a bit of the sample code, but it's not clear to me >> what the basic steps are to implement an Authorization server -- if indeed >> that is what I need -- and how to translate some of the OAuth2 workflows >> into working code using the library. Can someone point me to something >> like an overview that might help me to understand the workflow of a >> DotNetOpenAuth implementation? I have the RFC and a starter book on >> OAuth2, but the terminology in those docs vs. the sample code and help file >> are not consistent.
>> Also, I have managed to get a basic MVC controller working that will >> receive a form-urlencoded set of credentials from a Fiddler client. My >> request looks like:
>> When the action method on the server calls ReadAuthorizationRequest(), I >> am getting the exception "This message can only be sent over HTTPS." I >> read in another post that setting an attribute on the messaging section in >> web.config called relaxSslRequirements to true would solve that, but it has >> had no effect, and I cannot find any documentation of the config parameters >> and what they mean.
>> Thanks, everyone!
>> Rich
>> -- >> 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/-/YjqNsMU8-oYJ. >> 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.
Your source code and web.config look good. And the way you're plugging in
your RCCAuthorizationServer is good. So if you're not getting any
breakpoint fired in your implementation, chances are DNOA is rejecting the
incoming request for some reason before it gets to where it needs to call
your code. Have you tried activating logging
<http://tinyurl.com/dnoalogs>to see what's wrong?
On Thursday, July 26, 2012, Rich Miller wrote:
> Andrew,
> So I've found some other samples and I've been trying to hit the token
> endpoint as suggested in your previous post. My Controller code looks a
> bit like this now, which is pretty much straight from the samples:
> Public Class OAuth2Controller
> Inherits System.Web.Mvc.Controller
> Private ReadOnly authServer As AuthorizationServer = New
> AuthorizationServer(New RCCAuthorizationServer())
> Public Function Token() As ActionResult
> Return authServer.HandleTokenRequest(Request).AsActionResult()
> End Function
> End Class
> My RCCAuthorizationServer host implements the interface, but at this point
> the interface implementation methods are just dummy methods with a lot of
> breakpoints so I can see the sequence of calls that are being made when
> HandleTokenRequest is called. Unfortunately none of the breakpoints are
> ever hit. I am guessing this is because I need to tell the authorization
> server somewhere what host to use, but I thought that might have happened
> when I newed up the Authorization server with the new instance of the host
> in the Private line above.
> My web.config dotnetopenauth section looks like this now:
> <dotNetOpenAuth>
> <!-- Allow DotNetOpenAuth to publish usage statistics to library
> authors to improve the library. -->
> <reporting enabled="true" />
> <oauth2>
> <authorizationServer>
> </authorizationServer>
> </oauth2>
> <!-- Relaxing SSL requirements is useful for simple samples, but NOT a
> good idea in production. -->
> <messaging relaxSslRequirements="true">
> <untrustedWebRequest>
> <whitelistHosts>
> <!-- since this is a sample, and will often be used with
> localhost -->
> <add name="localhost"/>
> </whitelistHosts>
> </untrustedWebRequest>
> </messaging>
> </dotNetOpenAuth>
> I am assuming that I might need to specify something in the authorization
> server element under the oauth2 element? So far, I can't find any example
> code where this element is not empty.
> Probably sounds like I could use a good tutorial. Maybe if this message
> thread gets long enough and produces results we can turn it into one... :-)
> Thanks again,
> Rich
> On Tuesday, July 24, 2012 8:19:51 PM UTC-4, Andrew Arnott wrote:
>> It appears that you're sending the user credentials to the authorization
>> endpoint, which is incorrect. You should send these to the *token* endpoint
>> instead.
>> As for the HTTPS requirement, DNOA *should *be honoring the web.config
>> setting but maybe that bit is buggy. Can you include your web.config file
>> so I can check it for accuracy? (be sure to scrub it of any confidential
>> data)
>> --
>> 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 24, 2012 at 2:47 PM, Rich Miller <richmiller...@gmail.com<javascript:_e({}, 'cvml', 'richmiller...@gmail.com');>
>> > wrote:
>>> Hi folks!
>>> Just getting started with DNOA and trying to implement a very simple
>>> OAuth2 Authorization server for an API using the Resource Owner Password
>>> Flow (client app asks the resource owner to enter credentials and passes
>>> them to an Authorize request along with the client ID and client secret).
>>> I've been looking at a bit of the sample code, but it's not clear to me
>>> what the basic steps are to implement an Authorization server -- if indeed
>>> that is what I need -- and how to translate some of the OAuth2 workflows
>>> into working code using the library. Can someone point me to something
>>> like an overview that might help me to understand the workflow of a
>>> DotNetOpenAuth implementation? I have the RFC and a starter book on
>>> OAuth2, but the terminology in those docs vs. the sample code and help file
>>> are not consistent.
>>> Also, I have managed to get a basic MVC controller working that will
>>> receive a form-urlencoded set of credentials from a Fiddler client. My
>>> request looks like:
>>> When the action method on the server calls **ReadAuthorizationRequest(),
>>> I am getting the exception "This message can only be sent over HTTPS." I
>>> read in another post that setting an attribute on the messaging section in
>>> web.config called relaxSslRequirements to true would solve that, but it has
>>> had no effect, and I cannot find any documentation of the config parameters
>>> and what they mean.
>>> Thanks, everyone!
>>> Rich
>>> --
>>> 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/-/YjqNsMU8-**oYJ<https://groups.google.com/d/msg/dotnetopenid/-/YjqNsMU8-oYJ>
>>> .
>>> To post to this group, send email to dotnetopenid@googlegroups.com<javascript:_e({}, 'cvml', 'dotnetopenid@googlegroups.com');>
>>> .
>>> To unsubscribe from this group, send email to dotnetopenid+unsubscribe@*
>>> *googlegroups.com <javascript:_e({}, 'cvml',
>>> 'dotnetopenid%2Bunsubscribe@googlegroups.com');>.
>>> For more options, visit this group at http://groups.google.com/** >>> group/dotnetopenid?hl=en<http://groups.google.com/group/dotnetopenid?hl=en>
>>> .
>> --
> 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/-/0krNIbyg4ekJ.
> To post to this group, send email to dotnetopenid@googlegroups.com<javascript:_e({}, 'cvml', 'dotnetopenid@googlegroups.com');>
> .
> To unsubscribe from this group, send email to
> dotnetopenid+unsubscribe@googlegroups.com <javascript:_e({}, 'cvml',
> 'dotnetopenid%2Bunsubscribe@googlegroups.com');>.
> For more options, visit this group at
> http://groups.google.com/group/dotnetopenid?hl=en.
-- --
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 Thursday, July 26, 2012, Rich Miller wrote:
> Andrew,
> Thanks for the response. I'll admit to being really new to all of this --
> both OAuth2 and DNOA -- and I guess one thing that has me a bit confused at
> this point regarding DNOA. Could you explain in general terms what the
> role of each of the server types is?
Authorization Server: the server that authenticates the user, asks the user
to authorize a client to access his/her data, and issues refresh and access
tokens.
Resource Server: the server that actually provides access to the protected
data. This server *accepts* access tokens as authorization. It does not
issue any tokens.
> Is the use of the Authorization server appropriate and the name of the
> endpoint wrong?
The URL itself isn't really that important, but seeing as an authorization
server has two endpoints, called the authorization endpoint and access
token endpoint, the fact that you were sending a message intended for the
access token endpoint to one named /Authorize was a clue that either you
named the URL in a confusing way, or you were calling the wrong one.
> What function does a Resource Server perform?
Answered above.
> If the client has received an access token from the Authorization server,
> wouldn't I simply need to validate the token when the client requested a
> resource from my API?
Yes. The resource server should new up a DNOA ResourceServer instance and
ask it to verify the access token.
-- --
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
Thanks for the reply and suggestion. I attempted to activate logging using the instructions provided at the link you included in your response. However, using the logging instructions on that page didn't produce a log file at all. Someone else had the same issue and reported it on the comments on that page. Is there something I am missing in my configuration that might not be included on that page? Do I have to add something in the DNOA configuration section to make it write log entries?
On Thursday, July 26, 2012 9:34:47 PM UTC-4, Andrew Arnott wrote:
> Answers inline...
> On Thursday, July 26, 2012, Rich Miller wrote:
>> Andrew,
>> Thanks for the response. I'll admit to being really new to all of this >> -- both OAuth2 and DNOA -- and I guess one thing that has me a bit confused >> at this point regarding DNOA. Could you explain in general terms what the >> role of each of the server types is?
> Authorization Server: the server that authenticates the user, asks the > user to authorize a client to access his/her data, and issues refresh and > access tokens. > Resource Server: the server that actually provides access to the protected > data. This server *accepts* access tokens as authorization. It does not > issue any tokens.
>> Is the use of the Authorization server appropriate and the name of the >> endpoint wrong?
> The URL itself isn't really that important, but seeing as an authorization > server has two endpoints, called the authorization endpoint and access > token endpoint, the fact that you were sending a message intended for the > access token endpoint to one named /Authorize was a clue that either you > named the URL in a confusing way, or you were calling the wrong one.
>> What function does a Resource Server perform?
> Answered above.
>> If the client has received an access token from the Authorization >> server, wouldn't I simply need to validate the token when the client >> requested a resource from my API?
> Yes. The resource server should new up a DNOA ResourceServer instance and > ask it to verify the access token.
> -- > -- > 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
I worked out the logging problem with the code on the instructions page. I was looking for the log entries in the file specified for the rolling log file appender, but the root log4net element was putting log entries in the tracefileappender. Made the change and the logging worked.
Here is the log entry for the request I posted in my previous message. It seems to be saying that DNOA is having trouble identifying the appropriate message type for the incoming request, but I'd appreciate any help interpreting what it is trying to tell me:
2012-07-30 10:39:49,899 (GMT-4) [46] INFO DotNetOpenAuth - DotNetOpenAuth, Version=4.1.0.12182, Culture=neutral, PublicKeyToken=2780ccd10d57b246 (official) 2012-07-30 10:39:49,908 (GMT-4) [46] WARN DotNetOpenAuth.Messaging - Message type EndUserAuthorizationImplicitRequest has more than one message part named response_type. Inherited members will be hidden. 2012-07-30 10:41:12,781 (GMT-4) [59] INFO DotNetOpenAuth.Messaging.Channel - Scanning incoming request for messages: http://localhost:61732/OAuth2/token 2012-07-30 10:41:12,782 (GMT-4) [59] DEBUG DotNetOpenAuth.Messaging.Channel - Incoming HTTP request: POST http://localhost:61732/OAuth2/token 2012-07-30 10:41:12,790 (GMT-4) [59] DEBUG DotNetOpenAuth.Messaging - The following required parameters were missing from the DotNetOpenAuth.OAuth2.AuthServer.Messages.AccessTokenRefreshRequestAS message: {refresh_token,
}
2012-07-30 10:41:12,792 (GMT-4) [59] DEBUG DotNetOpenAuth.Messaging - The following required parameters were missing from the DotNetOpenAuth.OAuth2.Messages.AccessTokenAuthorizationCodeRequestAS message: {code,
}
2012-07-30 10:41:12,793 (GMT-4) [59] DEBUG DotNetOpenAuth.Messaging - The following required parameters were missing from the DotNetOpenAuth.OAuth2.Messages.EndUserAuthorizationRequest message: {response_type,
}
2012-07-30 10:41:12,793 (GMT-4) [59] DEBUG DotNetOpenAuth.Messaging - The following required parameters were missing from the DotNetOpenAuth.OAuth2.Messages.EndUserAuthorizationImplicitRequest message: {response_type,
}
2012-07-30 10:41:12,793 (GMT-4) [59] DEBUG DotNetOpenAuth.Messaging - The following required parameters were missing from the DotNetOpenAuth.OAuth2.Messages.EndUserAuthorizationFailedResponse message: {error,
}
2012-07-30 10:41:12,795 (GMT-4) [59] WARN DotNetOpenAuth.Messaging - Multiple message types seemed to fit the incoming data: {AccessTokenResourceOwnerPasswordCredentialsRequest (2.0), AccessTokenClientCredentialsRequest (2.0),
}
2012-07-30 10:41:12,803 (GMT-4) [59] ERROR DotNetOpenAuth.Messaging - Protocol error: This message can only be sent over HTTPS. at DotNetOpenAuth.Messaging.ErrorUtilities.VerifyProtocol(Boolean condition, String unformattedMessage, Object[] args) at DotNetOpenAuth.OAuth2.Messages.AccessTokenRequestBase.EnsureValidMessage() at DotNetOpenAuth.OAuth2.Messages.MessageBase.DotNetOpenAuth.Messaging.IMessag e.EnsureValidMessage() at DotNetOpenAuth.Messaging.MessageSerializer.Deserialize(IDictionary`2 fields, MessageDictionary messageDictionary) at DotNetOpenAuth.Messaging.Reflection.MessageDictionary.Deserialize(IDictiona ry`2 fields) at DotNetOpenAuth.Messaging.Channel.Receive(Dictionary`2 fields, MessageReceivingEndpoint recipient) at DotNetOpenAuth.Messaging.Channel.ReadFromRequestCore(HttpRequestBase request) at DotNetOpenAuth.OAuth2.ChannelElements.OAuth2AuthorizationServerChannel.Read FromRequestCore(HttpRequestBase request) at DotNetOpenAuth.Messaging.Channel.ReadFromRequest(HttpRequestBase httpRequest) at DotNetOpenAuth.Messaging.Channel.TryReadFromRequest[TRequest](HttpRequestBa se httpRequest, TRequest& request) at DotNetOpenAuth.OAuth2.AuthorizationServer.HandleTokenRequest(HttpRequestBas e request) at TestDNOA.TestDNOA.OAuth2Controller.Token() at lambda_method(Closure , ControllerBase , Object[] ) at System.Web.Mvc.ActionMethodDispatcher.Execute(ControllerBase controller, Object[] parameters) at System.Web.Mvc.ReflectedActionDescriptor.Execute(ControllerContext controllerContext, IDictionary`2 parameters) at System.Web.Mvc.ControllerActionInvoker.InvokeActionMethod(ControllerContext controllerContext, ActionDescriptor actionDescriptor, IDictionary`2 parameters) at System.Web.Mvc.ControllerActionInvoker.<>c__DisplayClass15.<InvokeActionMet hodWithFilters>b__12() at System.Web.Mvc.ControllerActionInvoker.InvokeActionMethodFilter(IActionFilt er filter, ActionExecutingContext preContext, Func`1 continuation) at System.Web.Mvc.ControllerActionInvoker.<>c__DisplayClass15.<>c__DisplayClas s17.<InvokeActionMethodWithFilters>b__14() at System.Web.Mvc.ControllerActionInvoker.InvokeActionMethodWithFilters(Contro llerContext controllerContext, IList`1 filters, ActionDescriptor actionDescriptor, IDictionary`2 parameters) at System.Web.Mvc.ControllerActionInvoker.InvokeAction(ControllerContext controllerContext, String actionName) at System.Web.Mvc.Controller.ExecuteCore() at System.Web.Mvc.ControllerBase.Execute(RequestContext requestContext) at System.Web.Mvc.ControllerBase.System.Web.Mvc.IController.Execute(RequestCon text requestContext) at System.Web.Mvc.MvcHandler.<>c__DisplayClass6.<>c__DisplayClassb.<BeginProce ssRequest>b__5() at System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass1.<MakeVoidDelegat e>b__0() at System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass8`1.<BeginSynchron ous>b__7(IAsyncResult _) at System.Web.Mvc.Async.AsyncResultWrapper.WrappedAsyncResult`1.End() at System.Web.Mvc.MvcHandler.<>c__DisplayClasse.<EndProcessRequest>b__d() at System.Web.Mvc.SecurityUtil.<GetCallInAppTrustThunk>b__0(Action f) at System.Web.Mvc.SecurityUtil.ProcessInApplicationTrust(Action action) at System.Web.Mvc.MvcHandler.EndProcessRequest(IAsyncResult asyncResult) at System.Web.Mvc.MvcHandler.System.Web.IHttpAsyncHandler.EndProcessRequest(IA syncResult result) at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplicat ion.IExecutionStep.Execute() at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) at System.Web.HttpApplication.ApplicationStepManager.ResumeSteps(Exception error) at System.Web.HttpApplication.System.Web.IHttpAsyncHandler.BeginProcessRequest (HttpContext context, AsyncCallback cb, Object extraData) at System.Web.HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr) at System.Web.HttpRuntime.ProcessRequestNoDemand(HttpWorkerRequest wr) at System.Web.HttpRuntime.ProcessRequest(HttpWorkerRequest wr) at Microsoft.VisualStudio.WebHost.Request.Process() at Microsoft.VisualStudio.WebHost.Host.ProcessRequest(Connection conn)
2012-07-30 10:41:12,823 (GMT-4) [59] DEBUG DotNetOpenAuth.Messaging.Channel - Preparing to send AccessTokenFailedResponse (2.0) message. 2012-07-30 10:41:12,824 (GMT-4) [59] DEBUG DotNetOpenAuth.Messaging.Bindings - Binding element DotNetOpenAuth.OAuth2.ChannelElements.MessageValidationBindingElement did not apply to message. 2012-07-30 10:41:12,824 (GMT-4) [59] DEBUG DotNetOpenAuth.Messaging.Bindings - Binding element DotNetOpenAuth.OAuth2.ChannelElements.TokenCodeSerializationBindingElement did not apply to message. 2012-07-30 10:41:12,827 (GMT-4) [59] INFO DotNetOpenAuth.Messaging.Channel - Prepared outgoing AccessTokenFailedResponse (2.0) message for <response>: error: invalid_request
On Monday, July 30, 2012 10:27:45 AM UTC-4, Rich Miller wrote:
> Andrew -
> Thanks for the reply and suggestion. I attempted to activate logging > using the instructions provided at the link you included in your response. > However, using the logging instructions on that page didn't produce a log > file at all. Someone else had the same issue and reported it on the > comments on that page. Is there something I am missing in my configuration > that might not be included on that page? Do I have to add something in the > DNOA configuration section to make it write log entries?
> Thanks,
> Rich
> On Thursday, July 26, 2012 9:34:47 PM UTC-4, Andrew Arnott wrote:
>> Answers inline...
>> On Thursday, July 26, 2012, Rich Miller wrote:
>>> Andrew,
>>> Thanks for the response. I'll admit to being really new to all of this >>> -- both OAuth2 and DNOA -- and I guess one thing that has me a bit confused >>> at this point regarding DNOA. Could you explain in general terms what the >>> role of each of the server types is?
>> Authorization Server: the server that authenticates the user, asks the >> user to authorize a client to access his/her data, and issues refresh and >> access tokens. >> Resource Server: the server that actually provides access to the >> protected data. This server *accepts* access tokens as authorization. >> It does not issue any tokens.
>>> Is the use of the Authorization server appropriate and the name of the >>> endpoint wrong?
>> The URL itself isn't really that important, but seeing as an >> authorization server has two endpoints, called the authorization endpoint >> and access token endpoint, the fact that you were sending a message >> intended for the access token endpoint to one named /Authorize was a clue >> that either you named the URL in a confusing way, or you were calling the >> wrong one.
>>> What function does a Resource Server perform?
>> Answered above.
>>> If the client has received an access token from the Authorization >>> server, wouldn't I simply need to validate the token when the client >>> requested a resource from my API?
>> Yes. The resource server should new up a DNOA ResourceServer instance >> and ask it to verify the access token.
Can I just state here (mildly offtopic) that the logging-guide is hugely confusing for peoples who haven't used log4net before, and simply copy pastes the logging code. When you see code like that given to you telling you that "this will enable logging" you sort of just expect it to work. The code should be changed so that the file-appender is default, not the trace-thingy (which I still have no idea what is).
I'll second that motion! If I had not been using log4net in some of my current projects, I would not have noticed the config issue. And it still escaped my notice the first time through :-)
On Monday, July 30, 2012 11:42:05 AM UTC-4, Aleksander Heintz wrote:
> Can I just state here (mildly offtopic) that the logging-guide is hugely > confusing for peoples who haven't used log4net before, and simply copy > pastes the logging code. When you see code like that given to you telling > you that "this will enable logging" you sort of just expect it to work. The > code should be changed so that the file-appender is default, not the > trace-thingy (which I still have no idea what is).
Looking at the log, the other error that is popping up is " Protocol error: This message can only be sent over HTTPS. "
I tried to set the relaxSslRequirements option in my web.config to true, but it seems to be having no effect. I put code in my controller like this (which I think I should be able to do):
Public Function Token() As ActionResult Dim msgConf As MessagingElement = MessagingElement.Configuration Return authServer.HandleTokenRequest(Request).AsActionResult() End Function
and examing the RelaxSslRequirements property on the msgConf always seems to return false. Therefore, it looks like the ErrorUtilities.VerifyProtocol function call on AccessTokenRequestBase is always failing, which is why my request message is not being accepted and none of my authorization server host methods are being called??
This would seem to be a simply fix to the configuration section handler, but I'm having a hard time seeing anything wrong with it, other than perhaps it is an attribute as opposed to an element??
/// <summary> /// The name of the attribute that indicates whether to disable SSL requirements across the library. /// </summary> private const string RelaxSslRequirementsConfigName = "relaxSslRequirements";
/// <summary> /// Gets or sets a value indicating whether SSL requirements within the library are disabled/relaxed. /// Use for TESTING ONLY. /// </summary> [ConfigurationProperty(RelaxSslRequirementsConfigName, DefaultValue = false)] internal bool RelaxSslRequirements { get { return (bool)this[RelaxSslRequirementsConfigName]; } set { this[RelaxSslRequirementsConfigName] = value; }
}
Let me know if you concur and what the appropriate fix would be.
On Monday, July 30, 2012 10:47:36 AM UTC-4, Rich Miller wrote:
> Andrew,
> I worked out the logging problem with the code on the instructions page. > I was looking for the log entries in the file specified for the rolling > log file appender, but the root log4net element was putting log entries in > the tracefileappender. Made the change and the logging worked.
> Here is the log entry for the request I posted in my previous message. It > seems to be saying that DNOA is having trouble identifying the appropriate > message type for the incoming request, but I'd appreciate any help > interpreting what it is trying to tell me:
> 2012-07-30 10:39:49,899 (GMT-4) [46] INFO DotNetOpenAuth - > DotNetOpenAuth, Version=4.1.0.12182, Culture=neutral, > PublicKeyToken=2780ccd10d57b246 (official) > 2012-07-30 10:39:49,908 (GMT-4) [46] WARN DotNetOpenAuth.Messaging - > Message type EndUserAuthorizationImplicitRequest has more than one message > part named response_type. Inherited members will be hidden. > 2012-07-30 10:41:12,781 (GMT-4) [59] INFO > DotNetOpenAuth.Messaging.Channel - Scanning incoming request for messages: > http://localhost:61732/OAuth2/token > 2012-07-30 10:41:12,782 (GMT-4) [59] DEBUG > DotNetOpenAuth.Messaging.Channel - Incoming HTTP request: POST > http://localhost:61732/OAuth2/token > 2012-07-30 10:41:12,790 (GMT-4) [59] DEBUG DotNetOpenAuth.Messaging - The > following required parameters were missing from the > DotNetOpenAuth.OAuth2.AuthServer.Messages.AccessTokenRefreshRequestAS > message: {refresh_token, > } > 2012-07-30 10:41:12,792 (GMT-4) [59] DEBUG DotNetOpenAuth.Messaging - The > following required parameters were missing from the > DotNetOpenAuth.OAuth2.Messages.AccessTokenAuthorizationCodeRequestAS > message: {code, > } > 2012-07-30 10:41:12,793 (GMT-4) [59] DEBUG DotNetOpenAuth.Messaging - The > following required parameters were missing from the > DotNetOpenAuth.OAuth2.Messages.EndUserAuthorizationRequest message: > {response_type, > } > 2012-07-30 10:41:12,793 (GMT-4) [59] DEBUG DotNetOpenAuth.Messaging - The > following required parameters were missing from the > DotNetOpenAuth.OAuth2.Messages.EndUserAuthorizationImplicitRequest message: > {response_type, > } > 2012-07-30 10:41:12,793 (GMT-4) [59] DEBUG DotNetOpenAuth.Messaging - The > following required parameters were missing from the > DotNetOpenAuth.OAuth2.Messages.EndUserAuthorizationFailedResponse message: > {error, > } > 2012-07-30 10:41:12,795 (GMT-4) [59] WARN DotNetOpenAuth.Messaging - > Multiple message types seemed to fit the incoming data: > {AccessTokenResourceOwnerPasswordCredentialsRequest (2.0), > AccessTokenClientCredentialsRequest (2.0), > } > 2012-07-30 10:41:12,803 (GMT-4) [59] ERROR DotNetOpenAuth.Messaging - > Protocol error: This message can only be sent over HTTPS. > at DotNetOpenAuth.Messaging.ErrorUtilities.VerifyProtocol(Boolean > condition, String unformattedMessage, Object[] args) > at > DotNetOpenAuth.OAuth2.Messages.AccessTokenRequestBase.EnsureValidMessage() > at > DotNetOpenAuth.OAuth2.Messages.MessageBase.DotNetOpenAuth.Messaging.IMessag e.EnsureValidMessage() > at DotNetOpenAuth.Messaging.MessageSerializer.Deserialize(IDictionary`2 > fields, MessageDictionary messageDictionary) > at > DotNetOpenAuth.Messaging.Reflection.MessageDictionary.Deserialize(IDictiona ry`2 > fields) > at DotNetOpenAuth.Messaging.Channel.Receive(Dictionary`2 fields, > MessageReceivingEndpoint recipient) > at DotNetOpenAuth.Messaging.Channel.ReadFromRequestCore(HttpRequestBase > request) > at > DotNetOpenAuth.OAuth2.ChannelElements.OAuth2AuthorizationServerChannel.Read FromRequestCore(HttpRequestBase > request) > at DotNetOpenAuth.Messaging.Channel.ReadFromRequest(HttpRequestBase > httpRequest) > at > DotNetOpenAuth.Messaging.Channel.TryReadFromRequest[TRequest](HttpRequestBa se > httpRequest, TRequest& request) > at > DotNetOpenAuth.OAuth2.AuthorizationServer.HandleTokenRequest(HttpRequestBas e > request) > at TestDNOA.TestDNOA.OAuth2Controller.Token() > at lambda_method(Closure , ControllerBase , Object[] ) > at System.Web.Mvc.ActionMethodDispatcher.Execute(ControllerBase > controller, Object[] parameters) > at System.Web.Mvc.ReflectedActionDescriptor.Execute(ControllerContext > controllerContext, IDictionary`2 parameters) > at > System.Web.Mvc.ControllerActionInvoker.InvokeActionMethod(ControllerContext > controllerContext, ActionDescriptor actionDescriptor, IDictionary`2 > parameters) > at > System.Web.Mvc.ControllerActionInvoker.<>c__DisplayClass15.<InvokeActionMet hodWithFilters>b__12() > at > System.Web.Mvc.ControllerActionInvoker.InvokeActionMethodFilter(IActionFilt er > filter, ActionExecutingContext preContext, Func`1 continuation) > at > System.Web.Mvc.ControllerActionInvoker.<>c__DisplayClass15.<>c__DisplayClas s17.<InvokeActionMethodWithFilters>b__14() > at > System.Web.Mvc.ControllerActionInvoker.InvokeActionMethodWithFilters(Contro llerContext > controllerContext, IList`1 filters, ActionDescriptor actionDescriptor, > IDictionary`2 parameters) > at > System.Web.Mvc.ControllerActionInvoker.InvokeAction(ControllerContext > controllerContext, String actionName) > at System.Web.Mvc.Controller.ExecuteCore() > at System.Web.Mvc.ControllerBase.Execute(RequestContext requestContext) > at > System.Web.Mvc.ControllerBase.System.Web.Mvc.IController.Execute(RequestCon text > requestContext) > at > System.Web.Mvc.MvcHandler.<>c__DisplayClass6.<>c__DisplayClassb.<BeginProce ssRequest>b__5() > at > System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass1.<MakeVoidDelegat e>b__0() > at > System.Web.Mvc.Async.AsyncResultWrapper.<>c__DisplayClass8`1.<BeginSynchron ous>b__7(IAsyncResult > _) > at System.Web.Mvc.Async.AsyncResultWrapper.WrappedAsyncResult`1.End() > at > System.Web.Mvc.MvcHandler.<>c__DisplayClasse.<EndProcessRequest>b__d() > at System.Web.Mvc.SecurityUtil.<GetCallInAppTrustThunk>b__0(Action f) > at System.Web.Mvc.SecurityUtil.ProcessInApplicationTrust(Action action) > at System.Web.Mvc.MvcHandler.EndProcessRequest(IAsyncResult asyncResult) > at > System.Web.Mvc.MvcHandler.System.Web.IHttpAsyncHandler.EndProcessRequest(IA syncResult > result) > at > System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplicat ion.IExecutionStep.Execute() > at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& > completedSynchronously) > at > System.Web.HttpApplication.ApplicationStepManager.ResumeSteps(Exception > error) > at > System.Web.HttpApplication.System.Web.IHttpAsyncHandler.BeginProcessRequest (HttpContext > context, AsyncCallback cb, Object extraData) > at System.Web.HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr) > at System.Web.HttpRuntime.ProcessRequestNoDemand(HttpWorkerRequest wr) > at System.Web.HttpRuntime.ProcessRequest(HttpWorkerRequest wr) > at Microsoft.VisualStudio.WebHost.Request.Process() > at Microsoft.VisualStudio.WebHost.Host.ProcessRequest(Connection conn)
> 2012-07-30 10:41:12,823 (GMT-4) [59] DEBUG > DotNetOpenAuth.Messaging.Channel - Preparing to send > AccessTokenFailedResponse (2.0) message. > 2012-07-30 10:41:12,824 (GMT-4) [59] DEBUG > DotNetOpenAuth.Messaging.Bindings - Binding element > DotNetOpenAuth.OAuth2.ChannelElements.MessageValidationBindingElement did > not apply to message. > 2012-07-30 10:41:12,824 (GMT-4) [59] DEBUG > DotNetOpenAuth.Messaging.Bindings - Binding element > DotNetOpenAuth.OAuth2.ChannelElements.TokenCodeSerializationBindingElement > did not apply to message. > 2012-07-30 10:41:12,827 (GMT-4) [59] INFO > DotNetOpenAuth.Messaging.Channel - Prepared outgoing > AccessTokenFailedResponse (2.0) message for <response>: > error: invalid_request
FYI, the trace thingy you were trying to find appears to be a custom class in the DNOA samples that results in log messages being accumulated in memory and accessible from a global application property called LogMessages. Got curious myself and found it in the sample code...
On Monday, July 30, 2012 11:42:05 AM UTC-4, Aleksander Heintz wrote:
> Can I just state here (mildly offtopic) that the logging-guide is hugely > confusing for peoples who haven't used log4net before, and simply copy > pastes the logging code. When you see code like that given to you telling > you that "this will enable logging" you sort of just expect it to work. The > code should be changed so that the file-appender is default, not the > trace-thingy (which I still have no idea what is).
Considering that the samples work with relaxSslRequirements="true" with
HTTPS, I suspect there's something wrong with your .config file rather than
a bug in the library. Maybe double-check that you have the
<configSections> defined appropriately according to the samples? (or if you
used NuGet that should do it for you).
--
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 30, 2012 at 10:17 AM, Rich Miller <richmiller...@gmail.com>wrote:
> Looking at the log, the other error that is popping up is " Protocol
> error: This message can only be sent over HTTPS. "
> I tried to set the relaxSslRequirements option in my web.config to true,
> but it seems to be having no effect. I put code in my controller like this
> (which I think I should be able to do):
> Public Function Token() As ActionResult
> Dim msgConf As MessagingElement =
> MessagingElement.Configuration
> Return authServer.HandleTokenRequest(Request).AsActionResult()
> End Function
> and examing the RelaxSslRequirements property on the msgConf always seems
> to return false. Therefore, it looks like
> the ErrorUtilities.VerifyProtocol function call on AccessTokenRequestBase
> is always failing, which is why my request message is not being accepted
> and none of my authorization server host methods are being called??
> This would seem to be a simply fix to the configuration section handler,
> but I'm having a hard time seeing anything wrong with it, other than
> perhaps it is an attribute as opposed to an element??
> /// <summary>
> /// The name of the attribute that indicates whether to disable SSL
> requirements across the library.
> /// </summary>
> private const string RelaxSslRequirementsConfigName =
> "relaxSslRequirements";
> /// <summary>
> /// Gets or sets a value indicating whether SSL requirements within the
> library are disabled/relaxed.
> /// Use for TESTING ONLY.
> /// </summary>
> [ConfigurationProperty(RelaxSslRequirementsConfigName, DefaultValue =
> false)]
> internal bool RelaxSslRequirements {
> get { return (bool)this[RelaxSslRequirementsConfigName]; }
> set { this[RelaxSslRequirementsConfigName] = value; }
> }
> Let me know if you concur and what the appropriate fix would be.
> Thanks,
> Rich
> On Monday, July 30, 2012 10:47:36 AM UTC-4, Rich Miller wrote:
>> Andrew,
>> I worked out the logging problem with the code on the instructions page.
>> I was looking for the log entries in the file specified for the rolling
>> log file appender, but the root log4net element was putting log entries in
>> the tracefileappender. Made the change and the logging worked.
>> Here is the log entry for the request I posted in my previous message.
>> It seems to be saying that DNOA is having trouble identifying the
>> appropriate message type for the incoming request, but I'd appreciate any
>> help interpreting what it is trying to tell me:
>> 2012-07-30 10:39:49,899 (GMT-4) [46] INFO DotNetOpenAuth -
>> DotNetOpenAuth, Version=4.1.0.12182, Culture=neutral, PublicKeyToken=**2780ccd10d57b246
>> (official)
>> 2012-07-30 10:39:49,908 (GMT-4) [46] WARN DotNetOpenAuth.Messaging -
>> Message type EndUserAuthorizationImplicitRe**quest has more than one
>> message part named response_type. Inherited members will be hidden.
>> 2012-07-30 10:41:12,781 (GMT-4) [59] INFO DotNetOpenAuth.Messaging.**Channel
>> - Scanning incoming request for messages: http://localhost:61732/OAuth2/* >> *token <http://localhost:61732/OAuth2/token>
>> 2012-07-30 10:41:12,782 (GMT-4) [59] DEBUG DotNetOpenAuth.Messaging.**Channel
>> - Incoming HTTP request: POST http://localhost:61732/OAuth2/**token<http://localhost:61732/OAuth2/token>
>> 2012-07-30 10:41:12,790 (GMT-4) [59] DEBUG DotNetOpenAuth.Messaging - The
>> following required parameters were missing from the DotNetOpenAuth.OAuth2.
>> **AuthServer.Messages.**AccessTokenRefreshRequestAS message:
>> {refresh_token,
>> }
>> 2012-07-30 10:41:12,792 (GMT-4) [59] DEBUG DotNetOpenAuth.Messaging - The
>> following required parameters were missing from the DotNetOpenAuth.OAuth2.
>> **Messages.**AccessTokenAuthorizationCodeRe**questAS message: {code,
>> }
>> 2012-07-30 10:41:12,793 (GMT-4) [59] DEBUG DotNetOpenAuth.Messaging - The
>> following required parameters were missing from the DotNetOpenAuth.OAuth2.
>> **Messages.**EndUserAuthorizationRequest message: {response_type,
>> }
>> 2012-07-30 10:41:12,793 (GMT-4) [59] DEBUG DotNetOpenAuth.Messaging - The
>> following required parameters were missing from the DotNetOpenAuth.OAuth2.
>> **Messages.**EndUserAuthorizationImplicitRe**quest message:
>> {response_type,
>> }
>> 2012-07-30 10:41:12,793 (GMT-4) [59] DEBUG DotNetOpenAuth.Messaging - The
>> following required parameters were missing from the DotNetOpenAuth.OAuth2.
>> **Messages.**EndUserAuthorizationFailedResp**onse message: {error,
>> }
>> 2012-07-30 10:41:12,795 (GMT-4) [59] WARN DotNetOpenAuth.Messaging -
>> Multiple message types seemed to fit the incoming data: {**
>> AccessTokenResourceOwnerPasswo**rdCredentialsRequest (2.0),
>> AccessTokenClientCredentialsRe**quest (2.0),
>> }
>> 2012-07-30 10:41:12,803 (GMT-4) [59] ERROR DotNetOpenAuth.Messaging -
>> Protocol error: This message can only be sent over HTTPS.
>> at DotNetOpenAuth.Messaging.**ErrorUtilities.VerifyProtocol(**Boolean
>> condition, String unformattedMessage, Object[] args)
>> at DotNetOpenAuth.OAuth2.**Messages.**AccessTokenRequestBase.**
>> EnsureValidMessage()
>> at DotNetOpenAuth.OAuth2.**Messages.MessageBase.**
>> DotNetOpenAuth.Messaging.**IMessage.EnsureValidMessage()
>> at DotNetOpenAuth.Messaging.**MessageSerializer.Deserialize(**IDictionary`2
>> fields, MessageDictionary messageDictionary)
>> at DotNetOpenAuth.Messaging.**Reflection.MessageDictionary.**Deserialize(IDict ionary`2
>> fields)
>> at DotNetOpenAuth.Messaging.**Channel.Receive(Dictionary`2 fields,
>> MessageReceivingEndpoint recipient)
>> at DotNetOpenAuth.Messaging.**Channel.ReadFromRequestCore(**HttpRequestBase
>> request)
>> at DotNetOpenAuth.OAuth2.**ChannelElements.**
>> OAuth2AuthorizationServerChann**el.ReadFromRequestCore(**HttpRequestBase
>> request)
>> at DotNetOpenAuth.Messaging.**Channel.ReadFromRequest(**HttpRequestBase
>> httpRequest)
>> at DotNetOpenAuth.Messaging.**Channel.TryReadFromRequest[**TRequest](HttpReque stBase
>> httpRequest, TRequest& request)
>> at DotNetOpenAuth.OAuth2.**AuthorizationServer.**HandleTokenRequest(**HttpRequ estBase
>> request)
>> at TestDNOA.TestDNOA.**OAuth2Controller.Token()
>> at lambda_method(Closure , ControllerBase , Object[] )
>> at System.Web.Mvc.**ActionMethodDispatcher.**Execute(ControllerBase
>> controller, Object[] parameters)
>> at System.Web.Mvc.**ReflectedActionDescriptor.**Execute(ControllerContext
>> controllerContext, IDictionary`2 parameters)
>> at System.Web.Mvc.**ControllerActionInvoker.**InvokeActionMethod(**ControllerC ontext
>> controllerContext, ActionDescriptor actionDescriptor, IDictionary`2
>> parameters)
>> at System.Web.Mvc.**ControllerActionInvoker.<>c__**DisplayClass15.<**
>> InvokeActionMethodWithFilters>**b__12()
>> at System.Web.Mvc.**ControllerActionInvoker.**
>> InvokeActionMethodFilter(**IActionFilter filter, ActionExecutingContext
>> preContext, Func`1 continuation)
>> at System.Web.Mvc.**ControllerActionInvoker.<>c__**
>> DisplayClass15.<>c__**DisplayClass17.<**InvokeActionMethodWithFilters>**
>> b__14()
>> at System.Web.Mvc.**ControllerActionInvoker.**
>> InvokeActionMethodWithFilters(**ControllerContext controllerContext,
>> IList`1 filters, ActionDescriptor actionDescriptor, IDictionary`2
>> parameters)
>> at System.Web.Mvc.**ControllerActionInvoker.**InvokeAction(ControllerContext
>> controllerContext, String actionName)
>> at System.Web.Mvc.Controller.**ExecuteCore()
>> at System.Web.Mvc.ControllerBase.**Execute(RequestContext
>> requestContext)
>> at System.Web.Mvc.ControllerBase.**System.Web.Mvc.IController.**Execute(Reques tContext
>> requestContext)
>> at System.Web.Mvc.MvcHandler.<>c_**_DisplayClass6.<>c__**
>> DisplayClassb.<**BeginProcessRequest>b__5()
>> at System.Web.Mvc.Async.**AsyncResultWrapper.<>c__**DisplayClass1.<**
>> MakeVoidDelegate>b__0()
>> at System.Web.Mvc.Async.**AsyncResultWrapper.<>c__**DisplayClass8`1.<*
>> *BeginSynchronous>b__7(**IAsyncResult _)
>> at System.Web.Mvc.Async.**AsyncResultWrapper.**
>> WrappedAsyncResult`1.End()
>> at System.Web.Mvc.MvcHandler.<>c_**_DisplayClasse.<**
>> EndProcessRequest>b__d()
>> at System.Web.Mvc.SecurityUtil.<**GetCallInAppTrustThunk>b__0(**Action
>> f)
>> at System.Web.Mvc.SecurityUtil.**ProcessInApplicationTrust(**Action
>> action)
>> at System.Web.Mvc.MvcHandler.**EndProcessRequest(IAsyncResult
>> asyncResult)
>> at System.Web.Mvc.MvcHandler.**System.Web.IHttpAsyncHandler.**EndProcessReques t(IAsyncResult
>> result)
>> at System.Web.HttpApplication.**CallHandlerExecutionStep.**
>> System.Web.HttpApplication.**IExecutionStep.Execute()
>> at System.Web.HttpApplication.**ExecuteStep(IExecutionStep step,
>> Boolean& completedSynchronously)
>> at System.Web.HttpApplication.**ApplicationStepManager.**ResumeSteps(Exception
>> error)
>> at System.Web.HttpApplication.**System.Web.IHttpAsyncHandler.**
>> BeginProcessRequest(**HttpContext context, AsyncCallback cb, Object
>> extraData)
>> at System.Web.HttpRuntime.**ProcessRequestInternal(**HttpWorkerRequest
>> wr)
>> at System.Web.HttpRuntime.**ProcessRequestNoDemand(**HttpWorkerRequest
>> wr)
>> at System.Web.HttpRuntime.**ProcessRequest(**HttpWorkerRequest wr)
>> at
This is good feedback. I've fixed the log4net documentation.
--
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 30, 2012 at 9:05 AM, Rich Miller <richmiller...@gmail.com>wrote:
> I'll second that motion! If I had not been using log4net in some of my
> current projects, I would not have noticed the config issue. And it still
> escaped my notice the first time through :-)
> On Monday, July 30, 2012 11:42:05 AM UTC-4, Aleksander Heintz wrote:
>> Can I just state here (mildly offtopic) that the logging-guide is hugely
>> confusing for peoples who haven't used log4net before, and simply copy
>> pastes the logging code. When you see code like that given to you telling
>> you that "this will enable logging" you sort of just expect it to work. The
>> code should be changed so that the file-appender is default, not the
>> trace-thingy (which I still have no idea what is).
> 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.
Here is the full content of my web.config. I'm not sure there is anything else here that could be wrong. Am I referring to the appropriate section handler for DNOA? I'm running this under the built-in development server from VS2010 - that would not create a problem would it?
<!-- The uri section is necessary to turn on .NET 3.5 support for IDN (international domain names), which is necessary for OpenID urls with unicode characters in the domain/host name. It is also required to put the Uri class into RFC 3986 escaping mode, which OpenID and OAuth require. --> <uri> <idn enabled="All"/> <iriParsing enabled="true"/> </uri> <appSettings> <add key="webpages:Version" value="1.0.0.0"/> <add key="ClientValidationEnabled" value="true"/> <add key="UnobtrusiveJavaScriptEnabled" value="true"/> </appSettings>
<runtime> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> <dependentAssembly> <assemblyIdentity name="System.Web.Mvc" publicKeyToken="31bf3856ad364e35" /> <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="3.0.0.0" /> </dependentAssembly> </assemblyBinding> </runtime> <!-- this is an optional configuration section where aspects of dotnetopenauth can be customized --> <dotNetOpenAuth> <!-- Allow DotNetOpenAuth to publish usage statistics to library authors to improve the library. --> <reporting enabled="true" /> <oauth2> <authorizationServer> </authorizationServer> </oauth2>
<!-- Relaxing SSL requirements is useful for simple samples, but NOT a good idea in production. --> <messaging relaxSslRequirements="true"> <untrustedWebRequest> <whitelistHosts> <!-- since this is a sample, and will often be used with localhost --> <add name="localhost"/> </whitelistHosts> </untrustedWebRequest> </messaging> </dotNetOpenAuth>
On Tuesday, July 31, 2012 3:01:15 PM UTC-4, Andrew Arnott wrote:
> Considering that the samples work with relaxSslRequirements="true" with > HTTPS, I suspect there's something wrong with your .config file rather than > a bug in the library. Maybe double-check that you have the > <configSections> defined appropriately according to the samples? (or if you > used NuGet that should do it for you).
> -- > 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 30, 2012 at 10:17 AM, Rich Miller <richmiller...@gmail.com>wrote:
>> Andrew,
>> Looking at the log, the other error that is popping up is " Protocol >> error: This message can only be sent over HTTPS. "
>> I tried to set the relaxSslRequirements option in my web.config to true, >> but it seems to be having no effect. I put code in my controller like this >> (which I think I should be able to do):
>> Public Function Token() As ActionResult >> Dim msgConf As MessagingElement = >> MessagingElement.Configuration >> Return authServer.HandleTokenRequest(Request).AsActionResult() >> End Function
>> and examing the RelaxSslRequirements property on the msgConf always seems >> to return false. Therefore, it looks like >> the ErrorUtilities.VerifyProtocol function call on AccessTokenRequestBase >> is always failing, which is why my request message is not being accepted >> and none of my authorization server host methods are being called??
>> This would seem to be a simply fix to the configuration section handler, >> but I'm having a hard time seeing anything wrong with it, other than >> perhaps it is an attribute as opposed to an element??
>> /// <summary> >> /// The name of the attribute that indicates whether to disable SSL >> requirements across the library. >> /// </summary> >> private const string RelaxSslRequirementsConfigName = >> "relaxSslRequirements";
>> /// <summary> >> /// Gets or sets a value indicating whether SSL requirements within the >> library are disabled/relaxed. >> /// Use for TESTING ONLY. >> /// </summary> >> [ConfigurationProperty(RelaxSslRequirementsConfigName, DefaultValue = >> false)] >> internal bool RelaxSslRequirements { >> get { return (bool)this[RelaxSslRequirementsConfigName]; } >> set { this[RelaxSslRequirementsConfigName] = value; } >> }
>> Let me know if you concur and what the appropriate fix would be.
>> Thanks,
>> Rich
>> On Monday, July 30, 2012 10:47:36 AM UTC-4, Rich Miller wrote:
>>> Andrew,
>>> I worked out the logging problem with the code on the instructions page. >>> I was looking for the log entries in the file specified for the rolling >>> log file appender, but the root log4net element was putting log entries in >>> the tracefileappender. Made the change and the logging worked.
>>> Here is the log entry for the request I posted in my previous message. >>> It seems to be saying that DNOA is having trouble identifying the >>> appropriate message type for the incoming request, but I'd appreciate any >>> help interpreting what it is trying to tell me:
>>> 2012-07-30 10:39:49,899 (GMT-4) [46] INFO DotNetOpenAuth - >>> DotNetOpenAuth, Version=4.1.0.12182, Culture=neutral, PublicKeyToken=**2780ccd10d57b246 >>> (official) >>> 2012-07-30 10:39:49,908 (GMT-4) [46] WARN DotNetOpenAuth.Messaging - >>> Message type EndUserAuthorizationImplicitRe**quest has more than one >>> message part named response_type. Inherited members will be hidden. >>> 2012-07-30 10:41:12,781 (GMT-4) [59] INFO DotNetOpenAuth.Messaging.**Channel >>> - Scanning incoming request for messages: http://localhost:61732/OAuth2/ >>> **token <http://localhost:61732/OAuth2/token> >>> 2012-07-30 10:41:12,782 (GMT-4) [59] DEBUG DotNetOpenAuth.Messaging.**Channel >>> - Incoming HTTP request: POST http://localhost:61732/OAuth2/**token<http://localhost:61732/OAuth2/token> >>> 2012-07-30 10:41:12,790 (GMT-4) [59] DEBUG DotNetOpenAuth.Messaging - >>> The following required parameters were missing from the >>> DotNetOpenAuth.OAuth2.**AuthServer.Messages.**AccessTokenRefreshRequestAS >>> message: {refresh_token, >>> } >>> 2012-07-30 10:41:12,792 (GMT-4) [59] DEBUG DotNetOpenAuth.Messaging - >>> The following required parameters were missing from the >>> DotNetOpenAuth.OAuth2.**Messages.**AccessTokenAuthorizationCodeRe**questAS >>> message: {code, >>> } >>> 2012-07-30 10:41:12,793 (GMT-4) [59] DEBUG DotNetOpenAuth.Messaging - >>> The following required parameters were missing from the >>> DotNetOpenAuth.OAuth2.**Messages.**EndUserAuthorizationRequest message: >>> {response_type, >>> } >>> 2012-07-30 10:41:12,793
Rich, your section handler doesn't include assembly names. If you're using
DotNetOpenAuth v4.x, it's pretty out of date. Here's what you need,
assuming you're using the NuGet (non-unified) assemblies:
On Wednesday, August 1, 2012, Rich Miller wrote:
> Andrew -
> Here is the full content of my web.config. I'm not sure there is anything
> else here that could be wrong. Am I referring to the appropriate section
> handler for DNOA? I'm running this under the built-in development server
> from VS2010 - that would not create a problem would it?
> <!-- The uri section is necessary to turn on .NET 3.5 support for IDN
> (international domain names),
> which is necessary for OpenID urls with unicode characters in the
> domain/host name.
> It is also required to put the Uri class into RFC 3986 escaping
> mode, which OpenID and OAuth require. -->
> <uri>
> <idn enabled="All"/>
> <iriParsing enabled="true"/>
> </uri>
> <appSettings>
> <add key="webpages:Version" value="1.0.0.0"/>
> <add key="ClientValidationEnabled" value="true"/>
> <add key="UnobtrusiveJavaScriptEnabled" value="true"/>
> </appSettings>
> <runtime>
> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
> <dependentAssembly>
> <assemblyIdentity name="System.Web.Mvc"
> publicKeyToken="31bf3856ad364e35" />
> <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" newVersion="3.0.0.0"
> />
> </dependentAssembly>
> </assemblyBinding>
> </runtime>
> <!-- this is an optional configuration section where aspects of
> dotnetopenauth can be customized -->
> <dotNetOpenAuth>
> <!-- Allow DotNetOpenAuth to publish usage statistics to library
> authors to improve the library. -->
> <reporting enabled="true" />
> <oauth2>
> <authorizationServer>
> </authorizationServer>
> </oauth2>
> <!-- Relaxing SSL requirements is useful for simple samples, but NOT a
> good idea in production. -->
> <messaging relaxSslRequirements="true">
> <untrustedWebRequest>
> <whitelistHosts>
> <!-- since this is a sample, and will often be used with
> localhost -->
> <add name="localhost"/>
> </whitelistHosts>
> </untrustedWebRequest>
> </messaging>
> </dotNetOpenAuth>
> On Tuesday, July 31, 2012 3:01:15 PM UTC-4, Andrew Arnott wrote:
> Considering that the samples work with relaxSslRequirements="true" with
> HTTPS, I suspect there's something wrong with your .config file rather than
> a bug in the library. Maybe double-check that you have the
> <configSections> defined appropriately according to the samples? (or if you
> used NuGet that should do it for you).
> --
> 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 30, 2012 at 10:17 AM, Rich Miller <richmiller...@gmail.com>wrote:
> Andrew,
> Looking at the log, the other error that is popping up is " Protocol
> error: This message can only be sent over HTTPS. "
> I tried to set the relaxSslRequirements option in my web.config to true,
> but it seems to be having no effect. I put code in my controller like this
> (which I think I should be able to do):
> Public Function Token() As ActionResult
> Dim msgConf As MessagingElement =
> MessagingElement.Configuration
> Return authServer.HandleTokenRequest(**
> Request).AsActionResult()
> End Function
> and examing the RelaxSslRequirements property on the msgConf always seems
> to return false. Therefore, it looks like the ErrorUtilities.**VerifyProtocol
> function call on AccessTokenRequestBase is always failing, which is why my
> request message is not being accepted and none of my authorization server
> host methods are being called??
> This would seem to be a simply fix to the configuration section handler,
> but I'm having a hard time seeing anything wrong with it, other than
> perhaps it is an attribute as opposed to an element??
> /// <summary>
> /// The name of the attribute that indicates whether to disable SSL
> requirements across the library.
> /// </summary>
> private const string RelaxSslRequirementsConfigName =
> "relaxSslRequirements";
> /// <summary>
> /// Gets or sets a value indicating whether SSL requirements within the
> library are disabled/relaxed.
> /// Use for TESTING ONLY.
> /// </summary>
> [ConfigurationProperty(**RelaxSslRequirementsConfigName**, DefaultValue =
> false)]
> internal bool RelaxSslRequirements {
> get { return (bool)this[**RelaxSslRequirementsConfigName**]; }
> set { this[**RelaxSslRequirementsConfigName**] = value; }
> }
> Let me know if you concur and what the appropriate fix would be.
> Thanks,
> Rich
> On Monday, July 30, 2012 10:47:36 AM UTC-4, Rich Miller wrote:
> --
> 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/-/nZqi78iQgAYJ.
> To post to this group, send email to dotnetopenid@googlegroups.com<javascript:_e({}, 'cvml', 'dotnetopenid@googlegroups.com');>
> .
> To unsubscribe from this group, send email to
> dotnetopenid+unsubscribe@googlegroups.com <javascript:_e({}, 'cvml',
> 'dotnetopenid%2Bunsubscribe@googlegroups.com');>.
> For more options, visit this group at
Thanks for the updated config code. I inserted this into my web.config and found that the oauth2 section was unknown. I went back to some sample code from Dave Christiansen and added his config info for the oauth2 section group, and the problem went away. My request message was finally received and accepted, and my authorization server host methods were called.
So far so good. Baby steps. :-)
Now on to understanding why each of my authorization server host functions is called and what each should do when called.
On Wednesday, August 1, 2012 8:08:07 PM UTC-4, Andrew Arnott wrote:
> Rich, your section handler doesn't include assembly names. If you're > using DotNetOpenAuth v4.x, it's pretty out of date. Here's what you need, > assuming you're using the NuGet (non-unified) assemblies:
> If you *are *using the unified dotnetopenauth.dll assembly, just change > all the assembly names to match in the above snippet.
> On Wednesday, August 1, 2012, Rich Miller wrote:
>> Andrew -
>> Here is the full content of my web.config. I'm not sure there is >> anything else here that could be wrong. Am I referring to the appropriate >> section handler for DNOA? I'm running this under the built-in development >> server from VS2010 - that would not create a problem would it?
>> <!-- The uri section is necessary to turn on .NET 3.5 support for IDN >> (international domain names), >> which is necessary for OpenID urls with unicode characters in >> the domain/host name. >> It is also required to put the Uri class into RFC 3986 escaping >> mode, which OpenID and OAuth require. --> >> <uri> >> <idn enabled="All"/> >> <iriParsing enabled="true"/> >> </uri> >> <appSettings> >> <add key="webpages:Version" value="1.0.0.0"/> >> <add key="ClientValidationEnabled" value="true"/> >> <add key="UnobtrusiveJavaScriptEnabled" value="true"/> >> </appSettings>
>> <runtime> >> <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> >> <dependentAssembly> >> <assemblyIdentity name="System.Web.Mvc" >> publicKeyToken="31bf3856ad364e35" /> >> <bindingRedirect oldVersion="1.0.0.0-2.0.0.0" >> newVersion="3.0.0.0" /> >> </dependentAssembly> >> </assemblyBinding> >> </runtime> >> <!-- this is an optional configuration section where aspects of >> dotnetopenauth can be customized --> >> <dotNetOpenAuth> >> <!-- Allow DotNetOpenAuth to publish usage statistics to library >> authors to improve the library. --> >> <reporting enabled="true" /> >> <oauth2> >> <authorizationServer> >> </authorizationServer> >> </oauth2>
>> <!-- Relaxing SSL requirements is useful for simple samples, but NOT >> a good idea in production. --> >> <messaging relaxSslRequirements="true"> >> <untrustedWebRequest> >> <whitelistHosts> >> <!-- since this is a sample, and will often be used with >> localhost --> >> <add name="localhost"/> >> </whitelistHosts> >> </untrustedWebRequest> >> </messaging> >> </dotNetOpenAuth>
>> On Tuesday, July 31, 2012 3:01:15 PM UTC-4, Andrew Arnott wrote:
>> Considering that the samples work with relaxSslRequirements="true" with >> HTTPS, I suspect there's something wrong with your .config file rather than >> a bug in the library. Maybe double-check that you have the >> <configSections> defined appropriately according to the samples? (or if you >> used NuGet that should do it for you).
>> -- >> 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 30, 2012 at 10:17 AM, Rich Miller <richmiller...@gmail.com>wrote:
>> Andrew,
>> Looking at the log, the other error that is popping up is " Protocol >> error: This message can only be sent over HTTPS. "
>> I tried to set the relaxSslRequirements option in my web.config to true, >> but it seems to be having no effect. I put code in my controller like this >> (which I think I should be able to do):
>> Public Function Token() As ActionResult >> Dim msgConf As MessagingElement = >> MessagingElement.Configuration >> Return authServer.HandleTokenRequest(** >> Request).AsActionResult() >> End Function
>> and examing the RelaxSslRequirements property on the msgConf always seems >> to return false. Therefore, it looks like the ErrorUtilities.**VerifyProtocol >> function call on AccessTokenRequestBase is always failing, which is why my >> request message is not being accepted and none of my authorization server >> host methods are being called??
>> This would seem to be a simply fix to the configuration section handler, >> but I'm having a hard time seeing anything wrong with it, other than >> perhaps it is an attribute as opposed to an element??
>> /// <summary> >> /// The name of the attribute that indicates whether to disable SSL >> requirements across the library. >> /// </summary> >> private const string RelaxSslRequirementsConfigName = >> "relaxSslRequirements";
>> /// <summary> >> /// Gets or sets a value indicating whether SSL requirements within the >> library are disabled/relaxed. >> /// Use for TESTING ONLY. >> /// </summary> >> [ConfigurationProperty(**RelaxSslRequirementsConfigName**, DefaultValue >> = false)] >> internal bool RelaxSslRequirements { >> get { return (bool)this[**RelaxSslRequirementsConfigName**]; } >> set { this[**RelaxSslRequirementsConfigName**] = value; } >> }
>> Let me know if you concur and what the appropriate fix would
On Thursday, August 2, 2012, Rich Miller wrote:
> Andrew,
> Thanks for the updated config code. I inserted this into my web.config
> and found that the oauth2 section was unknown. I went back to some sample
> code from Dave Christiansen and added his config info for the oauth2
> section group, and the problem went away. My request message was finally
> received and accepted, and my authorization server host methods were called.
> So far so good. Baby steps. :-)
> Now on to understanding why each of my authorization server host functions
> is called and what each should do when called.
> Rich
> On Wednesday, August 1, 2012 8:08:07 PM UTC-4, Andrew Arnott wrote:
> Rich, your section handler doesn't include assembly names. If you're
> using DotNetOpenAuth v4.x, it's pretty out of date. Here's what you need,
> assuming you're using the NuGet (non-unified) assemblies:
> If you *are *using the unified dotnetopenauth.dll assembly, just change
> all the assembly names to match in the above snippet.
> On Wednesday, August 1, 2012, Rich Miller wrote:
> Andrew -
> Here is the full content of my web.config. I'm not sure there is anything
> else here that could be wrong. Am I referring to the appropriate section
> handler for DNOA? I'm running this under the built-in development server
> from VS2010 - that would not create a problem would it?
> <!-- The uri section is necessary to turn on .NET 3.5 support for IDN
> (international domain names),
> which is necessary for OpenID urls with unicode characters in the
> domain/host name.
> It is also required to put the Uri class into RFC 3986 escaping
> mode, which OpenID and OAuth require. -->
> <uri>
> <idn enabled="All"/>
> <iriParsing enabled="true"/>
> </uri>
> <appSettings>
> --
> 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/-/O3qnd7Ke5BEJ.
> To post to this group, send email to dotnetopenid@googlegroups.com<javascript:_e({}, 'cvml', 'dotnetopenid@googlegroups.com');>
> .
> To unsubscribe from this group, send email to
> dotnetopenid+unsubscribe@googlegroups.com <javascript:_e({}, 'cvml',
> 'dotnetopenid%2Bunsubscribe@googlegroups.com');>.
> For more options, visit this group at
> http://groups.google.com/group/dotnetopenid?hl=en.
-- --
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
Thanks for the link to the documentation, which is extremely helpful. What I also really need to do is gain an understanding of the flow of function calls in the authorization server and the when and why each function would be called. For example, when would IsAuthorizationValid ever be called? I thought that once the Authorization server did its job, it would be out of the way and would turn things over to a ResourceServer to check the access token and serve up resources to authorized clients. Is there a non-WCF sample you could point me to that demonstrates how the resource server and authorization server work together to do that?
Also, the docs for TryAuthorizeResourceOwnerCredentialGrant say that I should "record an authorization entry such that subsequent calls to IsAuthorizationValid(IAuthorizationDescription) would return true." Since none of the sample code I have implements this method -- they all throw a NotImplementedException -- I am assuming that I need to record the access token and the client information in a database somewhere so that I can look it back up in IsAuthorizationValid to confirm that the access token is legit and belongs to the client that sent it?
There also seems to be some cryptographic signing of the access tokens going on in the methods that create them. Are these methods called automatically? Is DNOA expecting a specific crypto provider to be used? Do I need crypto at all, since the OAuth 2 spec seems to require TLS as opposed to signed tokens.
>> Thanks for the updated config code. I inserted this into my web.config >> and found that the oauth2 section was unknown. I went back to some sample >> code from Dave Christiansen and added his config info for the oauth2 >> section group, and the problem went away. My request message was finally >> received and accepted, and my authorization server host methods were called.
>> So far so good. Baby steps. :-)
>> Now on to understanding why each of my authorization server host >> functions is called and what each should do when called.
>> Rich
>> On Wednesday, August 1, 2012 8:08:07 PM UTC-4, Andrew Arnott wrote:
>> Rich, your section handler doesn't include assembly names. If you're >> using DotNetOpenAuth v4.x, it's pretty out of date. Here's what you need, >> assuming you're using the NuGet (non-unified) assemblies:
>> If you *are *using the unified dotnetopenauth.dll assembly, just change >> all the assembly names to match in the above snippet.
>> On Wednesday, August 1, 2012, Rich Miller wrote:
>> Andrew -
>> Here is the full content of my web.config. I'm not sure there is >> anything else here that could be wrong. Am I referring to the appropriate >> section handler for DNOA? I'm running this under the built-in development >> server from VS2010 - that would not create a problem would it?
>> <!-- The uri section is necessary to turn on .NET 3.5 support for IDN >> (international domain names), >> which is necessary for OpenID urls with unicode characters in >> the domain/host name. >> It is also required to put the Uri class into RFC 3986 escaping >> mode, which OpenID and OAuth require. --> >> <uri> >> <idn enabled="All"/> >> <iriParsing enabled="true"/> >> </uri> >> <appSettings>
>> -- >> 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/-/O3qnd7Ke5BEJ. >> 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.
> -- > -- > 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
Sorry for taking so long to respond. Some responses inline...
On Thu, Aug 2, 2012 at 8:58 AM, Rich Miller <richmiller...@gmail.com> wrote:
> Thanks for the link to the documentation, which is extremely helpful.
> What I also really need to do is gain an understanding of the flow of
> function calls in the authorization server and the when and why each
> function would be called. For example, when would IsAuthorizationValid
> ever be called?
In response to the resource owner password grant type, the client may get
both a refresh token and an access token. When the access token expires,
the client can request a new access token using their refresh token. It is
at this point of requesting a new one that the IsAuthorizationValid is
called to verify that the user has not revoked access to that client.
> I thought that once the Authorization server did its job, it would be out
> of the way and would turn things over to a ResourceServer to check the
> access token and serve up resources to authorized clients.
That's correct.
> Is there a non-WCF sample you could point me to that demonstrates how the
> resource server and authorization server work together to do that?
> Also, the docs for TryAuthorizeResourceOwnerCredentialGrant say that I
> should "record an authorization entry such that subsequent calls to
> IsAuthorizationValid(IAuthorizationDescription) would return true." Since
> none of the sample code I have implements this method -- they all throw a
> NotImplementedException -- I am assuming that I need to record the access
> token and the client information in a database somewhere so that I can look
> it back up in IsAuthorizationValid to confirm that the access token is
> legit and belongs to the client that sent it?
Correct.
> There also seems to be some cryptographic signing of the access tokens
> going on in the methods that create them. Are these methods called
> automatically? Is DNOA expecting a specific crypto provider to be used?
> Do I need crypto at all, since the OAuth 2 spec seems to require TLS as
> opposed to signed tokens.
Your IAuthorizationServerHost needn't do any crypto itself. It merely
exposes RSACryptoServiceProviders and DNOA does the crypto.
The crypto that OAuth 2 does away with in favor of TLS is the crypto that
is negotiated between auth server and client, and between client and
resource server. Crypto is still applicable and frequently used between
auth server and resource server to allow the resource server to verify the
validity of the access token (since it goes through the untrusted client
third party). DNOA also encrypts the access token so that the auth server
can embed confidential information intended for the resource server without
the client seeing it.
The OAuth 2 spec could be implemented without any crypto (besides TLS) by
having the resource server make a callback to the auth server for every
incoming call to validate the access token. Most folks find that an
undesirable perf hit and load on the servers to double every incoming
request and take a database query hit at the auth server besides. That's
why crypto in the bearer access token itself is still popular.
Thanks for the reply. No problem about the delay -- I've managed to keep busy. :-)
Based on your reply and a read of the source code, I think some of this is starting to sink in. I understand now based on the source and your reply to another post that the access token you generate is not just a random unique token but an encrypted/serialized collection of information about the sender, including the client id, the username and the access token expiration date and time. In DNOA the authorization server is used to read the token request, authorize the request and generate and send the access token response, which I assume you send in the appropriate json format according to the spec. Do I have any way of manually sending the token response rather than using the method call to do it for me?
I looked at David Christiansen's example for Web API and saw that the ResourceServer is used to decrypt/deserialize the access token received in the resource request, validate the contents and store the user information in the Principal so that it can be accessed by the controller's action method code. I was a little surprised to see that there was no check by the resource server against some sort of token store -- probably like the one or the same one that would be used to reauthorize the token in a refresh -- to verify that the access token had actually been granted to the client. I guess the assumption is that if the client has the token and it can be successfully decrypted/deserialized that it must have been granted by the authorization server. Would it not be advisable to perform such a check? That would also allow me to provide sliding expiration for my access tokens if the tokens were in some sort of store that included an expiration date that could be updated based on the last access.
Also, is it possible to add custom data to the access token without altering the core source code of DNOA? It would be useful to store a small amount of other info about the user or client in the token if the resource server is not looking up some corresponding token information in a store on each request.
Thanks again for all of the clarifications you have provided. It has filled in a large number of gaps for me.
Rich
One of the checks being done is to compare the current UTC date against the token's issue date and expiration time to
On Friday, August 24, 2012 10:05:52 AM UTC-4, Andrew Arnott wrote:
> Hi Rich,
> Sorry for taking so long to respond. Some responses inline... > On Thu, Aug 2, 2012 at 8:58 AM, Rich Miller <richmi...@gmail.com<javascript:> > > wrote:
>> Thanks for the link to the documentation, which is extremely helpful. >> What I also really need to do is gain an understanding of the flow of >> function calls in the authorization server and the when and why each >> function would be called. For example, when would IsAuthorizationValid >> ever be called?
> In response to the resource owner password grant type, the client may get > both a refresh token and an access token. When the access token expires, > the client can request a new access token using their refresh token. It is > at this point of requesting a new one that the IsAuthorizationValid is > called to verify that the user has not revoked access to that client.
>> I thought that once the Authorization server did its job, it would be out >> of the way and would turn things over to a ResourceServer to check the >> access token and serve up resources to authorized clients.
> That's correct.
>> Is there a non-WCF sample you could point me to that demonstrates how the >> resource server and authorization server work together to do that?
>> Also, the docs for TryAuthorizeResourceOwnerCredentialGrant say that I >> should "record an authorization entry such that subsequent calls to >> IsAuthorizationValid(IAuthorizationDescription) would return true." Since >> none of the sample code I have implements this method -- they all throw a >> NotImplementedException -- I am assuming that I need to record the access >> token and the client information in a database somewhere so that I can look >> it back up in IsAuthorizationValid to confirm that the access token is >> legit and belongs to the client that sent it?
> Correct.
>> There also seems to be some cryptographic signing of the access tokens >> going on in the methods that create them. Are these methods called >> automatically? Is DNOA expecting a specific crypto provider to be used? >> Do I need crypto at all, since the OAuth 2 spec seems to require TLS as >> opposed to signed tokens.
> Your IAuthorizationServerHost needn't do any crypto itself. It merely > exposes RSACryptoServiceProviders and DNOA does the crypto. > The crypto that OAuth 2 does away with in favor of TLS is the crypto that > is negotiated between auth server and client, and between client and > resource server. Crypto is still applicable and frequently used between > auth server and resource server to allow the resource server to verify the > validity of the access token (since it goes through the untrusted client > third party). DNOA also encrypts the access token so that the auth server > can embed confidential information intended for the resource server without > the client seeing it.
> The OAuth 2 spec could be implemented without any crypto (besides TLS) by > having the resource server make a callback to the auth server for every > incoming call to validate the access token. Most folks find that an > undesirable perf hit and load on the servers to double every incoming > request and take a database query hit at the auth server besides. That's > why crypto in the bearer access token itself is still popular.
> Thanks for the reply. No problem about the delay -- I've managed to keep
> busy. :-)
> Based on your reply and a read of the source code, I think some of this is
> starting to sink in. I understand now based on the source and your reply
> to another post that the access token you generate is not just a random
> unique token but an encrypted/serialized collection of information about
> the sender, including the client id, the username and the access token
> expiration date and time. In DNOA the authorization server is used to read
> the token request, authorize the request and generate and send the access
> token response, which I assume you send in the appropriate json format
> according to the spec. Do I have any way of manually sending the token
> response rather than using the method call to do it for me?
> I looked at David Christiansen's example for Web API and saw that the
> ResourceServer is used to decrypt/deserialize the access token received in
> the resource request, validate the contents and store the user information
> in the Principal so that it can be accessed by the controller's action
> method code. I was a little surprised to see that there was no check by
> the resource server against some sort of token store -- probably like the
> one or the same one that would be used to reauthorize the token in a
> refresh -- to verify that the access token had actually been granted to the
> client. I guess the assumption is that if the client has the token and it
> can be successfully decrypted/deserialized that it must have been granted
> by the authorization server. Would it not be advisable to perform such a
> check? That would also allow me to provide sliding expiration for my
> access tokens if the tokens were in some sort of store that included an
> expiration date that could be updated based on the last access.
> Also, is it possible to add custom data to the access token without
> altering the core source code of DNOA? It would be useful to store a small
> amount of other info about the user or client in the token if the resource
> server is not looking up some corresponding token information in a store on
> each request.
> Thanks again for all of the clarifications you have provided. It has
> filled in a large number of gaps for me.
> Rich
> One of the checks being done is to compare the current UTC date against
> the token's issue date and expiration time to
> On Friday, August 24, 2012 10:05:52 AM UTC-4, Andrew Arnott wrote:
>> Hi Rich,
>> Sorry for taking so long to respond. Some responses inline...
>> On Thu, Aug 2, 2012 at 8:58 AM, Rich Miller <richmi...@gmail.com> wrote:
>>> Thanks for the link to the documentation, which is extremely helpful.
>>> What I also really need to do is gain an understanding of the flow of
>>> function calls in the authorization server and the when and why each
>>> function would be called. For example, when would IsAuthorizationValid
>>> ever be called?
>> In response to the resource owner password grant type, the client may get
>> both a refresh token and an access token. When the access token expires,
>> the client can request a new access token using their refresh token. It is
>> at this point of requesting a new one that the IsAuthorizationValid is
>> called to verify that the user has not revoked access to that client.
>>> I thought that once the Authorization server did its job, it would be
>>> out of the way and would turn things over to a ResourceServer to check the
>>> access token and serve up resources to authorized clients.
>> That's correct.
>>> Is there a non-WCF sample you could point me to that demonstrates how
>>> the resource server and authorization server work together to do that?
>>> Also, the docs for **TryAuthorizeResourceOwnerCrede**ntialGrant say
>>> that I should "record an authorization entry such that subsequent calls to
>>> IsAuthorizationValid(**IAuthorizationDescription) would return true."
>>> Since none of the sample code I have implements this method -- they all
>>> throw a NotImplementedException -- I am assuming that I need to record the
>>> access token and the client information in a database somewhere so that I
>>> can look it back up in IsAuthorizationValid to confirm that the access
>>> token is legit and belongs to the client that sent it?
>> Correct.
>>> There also seems to be some cryptographic signing of the access tokens
>>> going on in the methods that create them. Are these methods called
>>> automatically? Is DNOA expecting a specific crypto provider to be used?
>>> Do I need crypto at all, since the OAuth 2 spec seems to require TLS as
>>> opposed to signed tokens.
>> Your IAuthorizationServerHost needn't do any crypto itself. It merely
>> exposes RSACryptoServiceProviders and DNOA does the crypto.
>> The crypto that OAuth 2 does away with in favor of TLS is the crypto that
>> is negotiated between auth server and client, and between client and
>> resource server. Crypto is still applicable and frequently used between
>> auth server and resource server to allow the resource server to verify the
>> validity of the access token (since it goes through the untrusted client
>> third party). DNOA also encrypts the access token so that the auth server
>> can embed confidential information intended for the resource server without
>> the client seeing it.
>> The OAuth 2 spec could be implemented without any crypto (besides TLS) by
>> having the resource server make a callback to the auth server for every
>> incoming call to validate the access token. Most folks find that an
>> undesirable perf hit and load on the servers to double every incoming
>> request and take a database query hit at the auth server besides. That's
>> why crypto in the bearer access token itself is still popular.
> --
> 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/-/kovP36Cic9gJ.
> 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.
> On Fri, Aug 24, 2012 at 1:25 PM, Rich Miller <richmi...@gmail.com<javascript:>
> > wrote:
>> Andrew,
>> Thanks for the reply. No problem about the delay -- I've managed to keep >> busy. :-)
>> Based on your reply and a read of the source code, I think some of this >> is starting to sink in. I understand now based on the source and your >> reply to another post that the access token you generate is not just a >> random unique token but an encrypted/serialized collection of information >> about the sender, including the client id, the username and the access >> token expiration date and time. In DNOA the authorization server is used >> to read the token request, authorize the request and generate and send the >> access token response, which I assume you send in the appropriate json >> format according to the spec. Do I have any way of manually sending the >> token response rather than using the method call to do it for me?
>> I looked at David Christiansen's example for Web API and saw that the >> ResourceServer is used to decrypt/deserialize the access token received in >> the resource request, validate the contents and store the user information >> in the Principal so that it can be accessed by the controller's action >> method code. I was a little surprised to see that there was no check by >> the resource server against some sort of token store -- probably like the >> one or the same one that would be used to reauthorize the token in a >> refresh -- to verify that the access token had actually been granted to the >> client. I guess the assumption is that if the client has the token and it >> can be successfully decrypted/deserialized that it must have been granted >> by the authorization server. Would it not be advisable to perform such a >> check? That would also allow me to provide sliding expiration for my >> access tokens if the tokens were in some sort of store that included an >> expiration date that could be updated based on the last access.
>> Also, is it possible to add custom data to the access token without >> altering the core source code of DNOA? It would be useful to store a small >> amount of other info about the user or client in the token if the resource >> server is not looking up some corresponding token information in a store on >> each request.
>> Thanks again for all of the clarifications you have provided. It has >> filled in a large number of gaps for me.
>> Rich
>> One of the checks being done is to compare the current UTC date against >> the token's issue date and expiration time to
>> On Friday, August 24, 2012 10:05:52 AM UTC-4, Andrew Arnott wrote:
>>> Hi Rich,
>>> Sorry for taking so long to respond. Some responses inline...
>>> On Thu, Aug 2, 2012 at 8:58 AM, Rich Miller <richmi...@gmail.com> wrote:
>>>> Thanks for the link to the documentation, which is extremely helpful. >>>> What I also really need to do is gain an understanding of the flow of >>>> function calls in the authorization server and the when and why each >>>> function would be called. For example, when would IsAuthorizationValid >>>> ever be called?
>>> In response to the resource owner password grant type, the client may >>> get both a refresh token and an access token. When the access token >>> expires, the client can request a new access token using their refresh >>> token. It is at this point of requesting a new one that the >>> IsAuthorizationValid is called to verify that the user has not revoked >>> access to that client.
>>>> I thought that once the Authorization server did its job, it would be >>>> out of the way and would turn things over to a ResourceServer to check the >>>> access token and serve up resources to authorized clients.
>>> That's correct.
>>>> Is there a non-WCF sample you could point me to that demonstrates how >>>> the resource server and authorization server work together to do that?
>>>> Also, the docs for **TryAuthorizeResourceOwnerCrede**ntialGrant say >>>> that I should "record an authorization entry such that subsequent calls to >>>> IsAuthorizationValid(**IAuthorizationDescription) would return true." >>>> Since none of the sample code I have implements this method -- they all >>>> throw a NotImplementedException -- I am assuming that I need to record the >>>> access token and the client information in a database somewhere so that I >>>> can look it back up in IsAuthorizationValid to confirm that the access >>>> token is legit and belongs to the client that sent it?
>>> Correct.
>>>> There also seems to be some cryptographic signing of the access tokens >>>> going on in the methods that create them. Are these methods called >>>> automatically? Is DNOA expecting a specific crypto provider to be used? >>>> Do I need crypto at all, since the OAuth 2 spec seems to require TLS as >>>> opposed to signed tokens.
>>> Your IAuthorizationServerHost needn't do any crypto itself. It merely >>> exposes RSACryptoServiceProviders and DNOA does the crypto.
>>> The crypto that OAuth 2 does away with in favor of TLS is the crypto >>> that is negotiated between auth server and client, and between client and >>> resource server. Crypto is still applicable and frequently used between >>> auth server and resource server to allow the resource server to verify the >>> validity of the access token (since it goes through the untrusted client >>> third party). DNOA also encrypts the access token so that the auth server >>> can embed confidential information intended for the resource server without >>> the client seeing it.
>>> The OAuth 2 spec could be implemented without any crypto (besides TLS) >>> by having the resource server make a callback to the auth server for every >>> incoming call to validate the access token. Most folks find that an >>> undesirable perf hit and load on the servers to double every incoming >>> request and take a database query hit at the auth server besides. That's >>> why crypto in the bearer access token itself is still popular.
>> -- >> 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/-/kovP36Cic9gJ.
>> To post to this group, send email to dotnet...@googlegroups.com<javascript:>
>> .
>> To unsubscribe from this group, send email to >> dotnetopenid...@googlegroups.com <javascript:>.
>> For more options, visit this group at >> http://groups.google.com/group/dotnetopenid?hl=en.
On Fri, Aug 24, 2012 at 1:25 PM, Rich Miller <richmiller...@gmail.com>wrote:
> Based on your reply and a read of the source code, I think some of this is
> starting to sink in. I understand now based on the source and your reply
> to another post that the access token you generate is not just a random
> unique token but an encrypted/serialized collection of information about
> the sender, including the client id, the username and the access token
> expiration date and time. In DNOA the authorization server is used to read
> the token request, authorize the request and generate and send the access
> token response, which I assume you send in the appropriate json format
> according to the spec. Do I have any way of manually sending the token
> response rather than using the method call to do it for me?
No, DNOA does not use a JSON format for its access tokens. The OAuth 2 spec
does not describe the access token format in any way. There is a
collection of specs around "JWT"s that do describe a possible format for
access tokens, but the specs are so difficult and costly (in dev time) to
comply with, and so little demand for that format from DNOA users, that
DNOA uses a much simpler format of its own. Using a proprietary format
turns out to not be any problem at all -- as long as DNOA is at both the
authorization server and resource server roles. The client end is
inconsequential.
As for whether you can construct an access token yourself, *maybe*. I
don't recall for sure. What is your scenario? (i.e. why wouldn't you want
DNOA to do it for you?)
> I looked at David Christiansen's example for Web API and saw that the
> ResourceServer is used to decrypt/deserialize the access token received in
> the resource request, validate the contents and store the user information
> in the Principal so that it can be accessed by the controller's action
> method code. I was a little surprised to see that there was no check by
> the resource server against some sort of token store -- probably like the
> one or the same one that would be used to reauthorize the token in a
> refresh -- to verify that the access token had actually been granted to the
> client. I guess the assumption is that if the client has the token and it
> can be successfully decrypted/deserialized that it must have been granted
> by the authorization server.
It's not just decrypted. It has a signature that is verified, which
verifies to the resource server that this is a legit access token from the
authorization server.
> Would it not be advisable to perform such a check?
Absolutely. But signature verification is sufficient to confirm the token's
validity, unless your requirements mandate a live check that the
authorization hasn't been revoked. For most purposes, an access token with
a short lifetime (say, 2-5 minutes) will shut a client down soon enough
after revocation to satisfy security requirements. This avoids the tax of
the extra HTTP call from resource server to the auth server and a DB lookup.
That would also allow me to provide sliding expiration for my access tokens
> if the tokens were in some sort of store that included an expiration date
> that could be updated based on the last access.
Yes, a backchannel would be the only way to provide a sliding expiration.
But IMO a sliding expiration would be redundant with the purpose of
refresh tokens. I advise against reinventing this and sticking with the
OAuth 2 spec, which has a fixed lifetime (or no set lifetime at all) for
access tokens.
> Also, is it possible to add custom data to the access token without
> altering the core source code of DNOA? It would be useful to store a small
> amount of other info about the user or client in the token if the resource
> server is not looking up some corresponding token information in a store on
> each request.
Yes, we've had this request before. In
IAuthorizationServerHost.CreateAccessToken, you create an
AuthorizationServerAccessToken, which has an ExtraData dictionary in it.
You can fill whatever you want in this dictionary to be received by the
resource server.
I don't think I stated my first question clearly enough. I was referring to the access token *response*, not the access token itself. According to the OAuth 2 spec, the authorization server typically sends back the access token in an OAuth 2.0 access token response, like so:
HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache
There is a method in DNOA used in the MVC controller samples for the authorization server that sends the response back from the token request like this:
Since I am using Web API to handle the token request, I wanted to understand if there is a method in DNOA to return the access token as an HttpResponseMessage with the format above or if I need to model an object and return it on my own. My assumption was that *AsActionResult *was returning the data as above.
On Friday, August 24, 2012 10:53:49 PM UTC-4, Andrew Arnott wrote:
> On Fri, Aug 24, 2012 at 1:25 PM, Rich Miller <richmi...@gmail.com<javascript:> > > wrote:
>> Based on your reply and a read of the source code, I think some of this >> is starting to sink in. I understand now based on the source and your >> reply to another post that the access token you generate is not just a >> random unique token but an encrypted/serialized collection of information >> about the sender, including the client id, the username and the access >> token expiration date and time. In DNOA the authorization server is used >> to read the token request, authorize the request and generate and send the >> access token response, which I assume you send in the appropriate json >> format according to the spec. Do I have any way of manually sending the >> token response rather than using the method call to do it for me?
> No, DNOA does not use a JSON format for its access tokens. The OAuth 2 > spec does not describe the access token format in any way. There is a > collection of specs around "JWT"s that do describe a possible format for > access tokens, but the specs are so difficult and costly (in dev time) to > comply with, and so little demand for that format from DNOA users, that > DNOA uses a much simpler format of its own. Using a proprietary format > turns out to not be any problem at all -- as long as DNOA is at both the > authorization server and resource server roles. The client end is > inconsequential.
> As for whether you can construct an access token yourself, *maybe*. I > don't recall for sure. What is your scenario? (i.e. why wouldn't you want > DNOA to do it for you?)
>> I looked at David Christiansen's example for Web API and saw that the >> ResourceServer is used to decrypt/deserialize the access token received in >> the resource request, validate the contents and store the user information >> in the Principal so that it can be accessed by the controller's action >> method code. I was a little surprised to see that there was no check by >> the resource server against some sort of token store -- probably like the >> one or the same one that would be used to reauthorize the token in a >> refresh -- to verify that the access token had actually been granted to the >> client. I guess the assumption is that if the client has the token and it >> can be successfully decrypted/deserialized that it must have been granted >> by the authorization server.
> It's not just decrypted. It has a signature that is verified, which > verifies to the resource server that this is a legit access token from the > authorization server.
>> Would it not be advisable to perform such a check?
> Absolutely. But signature verification is sufficient to confirm the > token's validity, unless your requirements mandate a live check that the > authorization hasn't been revoked. For most purposes, an access token with > a short lifetime (say, 2-5 minutes) will shut a client down soon enough > after revocation to satisfy security requirements. This avoids the tax of > the extra HTTP call from resource server to the auth server and a DB lookup.
> That would also allow me to provide sliding expiration for my access >> tokens if the tokens were in some sort of store that included an expiration >> date that could be updated based on the last access.
> Yes, a backchannel would be the only way to provide a sliding expiration. > But IMO a sliding expiration would be redundant with the purpose of > refresh tokens. I advise against reinventing this and sticking with the > OAuth 2 spec, which has a fixed lifetime (or no set lifetime at all) for > access tokens.
>> Also, is it possible to add custom data to the access token without >> altering the core source code of DNOA? It would be useful to store a small >> amount of other info about the user or client in the token if the resource >> server is not looking up some corresponding token information in a store on >> each request.
> Yes, we've had this request before. In > IAuthorizationServerHost.CreateAccessToken, you create an > AuthorizationServerAccessToken, which has an ExtraData dictionary in it. > You can fill whatever you want in this dictionary to be received by the > resource server.
I'm in the same boat. Its not built in to dnoa, however, you web api is a
mvc4 project. You can easily run it as MVC for the with server and web api
as the resource server.
Since dnoa works in a distributed environment, this method works great.
Trick is to only consider your web api as the resource serer only.
On Aug 27, 2012 10:11 AM, "Rich Miller" <richmiller...@gmail.com> wrote:
> I don't think I stated my first question clearly enough. I was referring
> to the access token *response*, not the access token itself. According
> to the OAuth 2 spec, the authorization server typically sends back the
> access token in an OAuth 2.0 access token response, like so:
> There is a method in DNOA used in the MVC controller samples for the
> authorization server that sends the response back from the token request
> like this:
> Since I am using Web API to handle the token request, I wanted to
> understand if there is a method in DNOA to return the access token as an
> HttpResponseMessage with the format above or if I need to model an object
> and return it on my own. My assumption was that *AsActionResult *was
> returning the data as above.
> Thanks for the rest of the info. Very helpful.
> Rich
> On Friday, August 24, 2012 10:53:49 PM UTC-4, Andrew Arnott wrote:
>> On Fri, Aug 24, 2012 at 1:25 PM, Rich Miller <richmi...@gmail.com> wrote:
>>> Based on your reply and a read of the source code, I think some of this
>>> is starting to sink in. I understand now based on the source and your
>>> reply to another post that the access token you generate is not just a
>>> random unique token but an encrypted/serialized collection of information
>>> about the sender, including the client id, the username and the access
>>> token expiration date and time. In DNOA the authorization server is used
>>> to read the token request, authorize the request and generate and send the
>>> access token response, which I assume you send in the appropriate json
>>> format according to the spec. Do I have any way of manually sending the
>>> token response rather than using the method call to do it for me?
>> No, DNOA does not use a JSON format for its access tokens. The OAuth 2
>> spec does not describe the access token format in any way. There is a
>> collection of specs around "JWT"s that do describe a possible format for
>> access tokens, but the specs are so difficult and costly (in dev time) to
>> comply with, and so little demand for that format from DNOA users, that
>> DNOA uses a much simpler format of its own. Using a proprietary format
>> turns out to not be any problem at all -- as long as DNOA is at both the
>> authorization server and resource server roles. The client end is
>> inconsequential.
>> As for whether you can construct an access token yourself, *maybe*. I
>> don't recall for sure. What is your scenario? (i.e. why wouldn't you want
>> DNOA to do it for you?)
>>> I looked at David Christiansen's example for Web API and saw that the
>>> ResourceServer is used to decrypt/deserialize the access token received in
>>> the resource request, validate the contents and store the user information
>>> in the Principal so that it can be accessed by the controller's action
>>> method code. I was a little surprised to see that there was no check by
>>> the resource server against some sort of token store -- probably like the
>>> one or the same one that would be used to reauthorize the token in a
>>> refresh -- to verify that the access token had actually been granted to the
>>> client. I guess the assumption is that if the client has the token and it
>>> can be successfully decrypted/deserialized that it must have been granted
>>> by the authorization server.
>> It's not just decrypted. It has a signature that is verified, which
>> verifies to the resource server that this is a legit access token from the
>> authorization server.
>>> Would it not be advisable to perform such a check?
>> Absolutely. But signature verification is sufficient to confirm the
>> token's validity, unless your requirements mandate a live check that the
>> authorization hasn't been revoked. For most purposes, an access token with
>> a short lifetime (say, 2-5 minutes) will shut a client down soon enough
>> after revocation to satisfy security requirements. This avoids the tax of
>> the extra HTTP call from resource server to the auth server and a DB lookup.
>> That would also allow me to provide sliding expiration for my access
>>> tokens if the tokens were in some sort of store that included an expiration
>>> date that could be updated based on the last access.
>> Yes, a backchannel would be the only way to provide a sliding expiration.
>> But IMO a sliding expiration would be redundant with the purpose of
>> refresh tokens. I advise against reinventing this and sticking with the
>> OAuth 2 spec, which has a fixed lifetime (or no set lifetime at all) for
>> access tokens.
>>> Also, is it possible to add custom data to the access token without
>>> altering the core source code of DNOA? It would be useful to store a small
>>> amount of other info about the user or client in the token if the resource
>>> server is not looking up some corresponding token information in a store on
>>> each request.
>> Yes, we've had this request before. In IAuthorizationServerHost.**CreateAccessToken,
>> you create an AuthorizationServerAccessToken**, which has an ExtraData
>> dictionary in it. You can fill whatever you want in this dictionary to be
>> received by the resource server.
> --
> 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/-/w-L9cLFsnQsJ.
> 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.
