Re: [dotnetopenauth] DNOA Using OAuth2 to Implement Resource Owner Password Flow?

Message has been deleted

Andrew Arnott

unread,

Jul 24, 2012, 8:19:51 PM7/24/12

to dotnet...@googlegroups.com

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 <richmi...@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:

POST http://localhost:61732/OAuth2/Authorize HTTP/1.1

User-Agent: Fiddler
Host: localhost:61732
Accept: application/json

Content-Type: application/x-www-form-urlencoded
Content-Length: 72

grant_type=password&client_id=Canon&username=rmiller&password=4GETmeknot

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 dotnet...@googlegroups.com.
To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.

Rich Miller

unread,

Jul 26, 2012, 11:20:45 AM7/26/12

to dotnet...@googlegroups.com

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? 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.

Thanks for your patience.

Rich

<security

requireSsl="false"

minimumRequiredOpenIdVersion="V10"

minimumHashBitLength="160"

maximumHashBitLength="256"

requireDirectedIdentity="false"

requireAssociation="false"

rejectUnsolicitedAssertions="false"

rejectDelegatingIdentifiers="false"

ignoreUnsignedExtensions="false"

protectDownlevelReplayAttacks="true"

privateSecretMaximumAge="07:00:00" />

</behaviors>

</relyingParty>

<security

requireSsl="false"

protectDownlevelReplayAttacks="true"

unsolicitedAssertionVerification="RequireSuccess|LogWarningOnFailure|NeverVerify"

minimumHashBitLength="160"

maximumHashBitLength="512">

</associations>

</security>

</behaviors>

</provider>

</openid>

<untrustedWebRequest

timeout="00:00:10"

readWriteTimeout="00:00:01.500"

maximumBytesToRead="1048576"

maximumRedirections="10">

</whitelistHosts>

</whitelistHostsRegex>

</blacklistHosts>

</blacklistHostsRegex>

</untrustedWebRequest>

</messaging>

</dotNetOpenAuth>

To unsubscribe from this group, send email to dotnetopenid+unsubscribe@googlegroups.com.

Rich Miller

unread,

Jul 26, 2012, 1:27:28 PM7/26/12

to dotnet...@googlegroups.com

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:

</authorizationServer>

</oauth2>

</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:

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 <richmi...@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:

POST http://localhost:61732/OAuth2/Authorize HTTP/1.1

User-Agent: Fiddler
Host: localhost:61732
Accept: application/json

Content-Type: application/x-www-form-urlencoded
Content-Length: 72

grant_type=password&client_id=Canon&username=rmiller&password=xxxxx

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 dotnet...@googlegroups.com.

To unsubscribe from this group, send email to dotnetopenid+unsubscribe@googlegroups.com.

Andrew Arnott

unread,

Jul 26, 2012, 9:34:46 PM7/26/12

to dotnet...@googlegroups.com

Hi Rich,

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 to see what's wrong?

To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/0krNIbyg4ekJ.

To post to this group, send email to dotnet...@googlegroups.com.

To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.

--

Andrew Arnott

unread,

Jul 26, 2012, 9:34:47 PM7/26/12

to dotnet...@googlegroups.com

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.

--

Rich Miller

unread,

Jul 30, 2012, 10:27:45 AM7/30/12

to dotnet...@googlegroups.com

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

Rich Miller

unread,

Jul 30, 2012, 10:47:36 AM7/30/12

to dotnet...@googlegroups.com

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.IMessage.EnsureValidMessage()

at DotNetOpenAuth.Messaging.MessageSerializer.Deserialize(IDictionary`2 fields, MessageDictionary messageDictionary)

at DotNetOpenAuth.Messaging.Reflection.MessageDictionary.Deserialize(IDictionary`2 fields)

at DotNetOpenAuth.Messaging.Channel.Receive(Dictionary`2 fields, MessageReceivingEndpoint recipient)

at DotNetOpenAuth.Messaging.Channel.ReadFromRequestCore(HttpRequestBase request)

at DotNetOpenAuth.OAuth2.ChannelElements.OAuth2AuthorizationServerChannel.ReadFromRequestCore(HttpRequestBase request)

at DotNetOpenAuth.Messaging.Channel.ReadFromRequest(HttpRequestBase httpRequest)

at DotNetOpenAuth.Messaging.Channel.TryReadFromRequest[TRequest](HttpRequestBase httpRequest, TRequest& request)

at DotNetOpenAuth.OAuth2.AuthorizationServer.HandleTokenRequest(HttpRequestBase 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.<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(RequestContext 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.EndProcessRequest(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 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

2012-07-30 10:41:12,829 (GMT-4) [59] DEBUG DotNetOpenAuth.Messaging.Channel - Sending message: AccessTokenFailedResponse

Thanks again,

Rich

Aleksander Heintz

unread,

Jul 30, 2012, 11:42:05 AM7/30/12

to dotnet...@googlegroups.com

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).

Rich Miller

unread,

Jul 30, 2012, 12:05:14 PM7/30/12

to dotnet...@googlegroups.com

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 :-)

Rich Miller

unread,

Jul 30, 2012, 1:17:49 PM7/30/12

to dotnet...@googlegroups.com

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

Rich Miller

unread,

Jul 30, 2012, 4:09:39 PM7/30/12

to dotnet...@googlegroups.com

Aleksander,

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...

Rich

On Monday, July 30, 2012 11:42:05 AM UTC-4, Aleksander Heintz wrote:

Andrew Arnott

unread,

Jul 31, 2012, 3:01:15 PM7/31/12

to dotnet...@googlegroups.com

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

--

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/-/Hk_IqNSbKg8J.

To post to this group, send email to dotnet...@googlegroups.com.

To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.

Andrew Arnott

unread,

Jul 31, 2012, 3:13:01 PM7/31/12

to dotnet...@googlegroups.com

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

--

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/-/bg7tEadb0IwJ.

To post to this group, send email to dotnet...@googlegroups.com.

To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.

Rich Miller

unread,

Aug 1, 2012, 10:58:43 AM8/1/12

to dotnet...@googlegroups.com

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?

<?xml version="1.0"?>

<!--

For more information on how to configure your ASP.NET application, please visit

http://go.microsoft.com/fwlink/?LinkId=152368

-->

<section name="uri" type="System.Configuration.UriSection,

System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />

<section name="dotNetOpenAuth" type="DotNetOpenAuth.Configuration.DotNetOpenAuthSection"

requirePermission="false" allowLocation="true"/>

</configSections>

<!-- 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>

</uri>

</appSettings>

<system.web>

</assemblies>

</compilation>

</authentication>

<pages>

</namespaces>

</pages>

</system.web>

<system.webServer>

</system.webServer>

</dependentAssembly>

</assemblyBinding>

</runtime>

</authorizationServer>

</oauth2>

</whitelistHosts>

</untrustedWebRequest>

</messaging>

</dotNetOpenAuth>

</layout>

</appender>

</layout>

</appender>

<root>

<appender-ref ref="RollingFileAppender" />

</root>

</logger>

</log4net>

</configuration>

Thanks,

Rich

To unsubscribe from this group, send email to dotnetopenid+unsubscribe@googlegroups.com.

Andrew Arnott

unread,

Aug 1, 2012, 8:08:07 PM8/1/12

to dotnet...@googlegroups.com

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:

</sectionGroup>

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 -

To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/nZqi78iQgAYJ.

To post to this group, send email to dotnet...@googlegroups.com.

To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.

Rich Miller

unread,

Aug 2, 2012, 10:12:16 AM8/2/12

to dotnet...@googlegroups.com

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

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

unread,

Aug 2, 2012, 10:49:58 AM8/2/12

to dotnet...@googlegroups.com

Great.

Hopefully this will help you on your next steps:

http://docs.dotnetopenauth.net/v4.1/html/AllMembers_T_DotNetOpenAuth_OAuth2_IAuthorizationServerHost.htm

--

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 dotnet...@googlegroups.com.

To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/dotnetopenid?hl=en.

Rich Miller

unread,

Aug 2, 2012, 11:58:45 AM8/2/12

to dotnet...@googlegroups.com

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,

Rich

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

unread,

Aug 24, 2012, 10:05:52 AM8/24/12

to dotnet...@googlegroups.com

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?

Yes: David's is here: https://github.com/DavidChristiansen/DotNetOpenAuth.WebAPI.40

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.

Rich Miller

unread,

Aug 24, 2012, 4:25:54 PM8/24/12

to dotnet...@googlegroups.com

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

Øyvind Sean Kinsey

unread,

Aug 24, 2012, 4:43:16 PM8/24/12

to dotnet...@googlegroups.com

Hey Rich - using self-describing tokens vs backchannel verification has been discussed multiple times - you might find the answer you are looking for in one of the previous threads:

https://groups.google.com/forum/#!searchin/dotnetopenid/backchannel

Øyvind Sean Kinsey
San Francisco, CA

--

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.

To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.

Rich Miller

unread,

Aug 24, 2012, 4:49:46 PM8/24/12

to dotnet...@googlegroups.com

Thanks. So that's referred to as a backchannel verification? I think I saw that term in some posts. I will take a look at the threads you suggested.

Rich

Andrew Arnott

unread,

Aug 24, 2012, 10:53:49 PM8/24/12

to dotnet...@googlegroups.com

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.

Rich Miller

unread,

Aug 27, 2012, 11:11:40 AM8/27/12

to dotnet...@googlegroups.com

Andrew,

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

{

"access_token":"mF_9.B5f-4.1JqM",

"token_type":"Bearer",

"expires_in":3600,

"refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA"

}

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:

return this.authorizationServer.HandleTokenRequest(this.Request).AsActionResult();

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

Brad Laney

unread,

Aug 27, 2012, 11:43:19 AM8/27/12

to dotnet...@googlegroups.com

Hey,

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.

--

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 dotnet...@googlegroups.com.

To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.

Andrew Arnott

unread,

Aug 28, 2012, 12:06:10 AM8/28/12

to dotnet...@googlegroups.com

Good tip, Brad.

We could certainly add an extension method like "AsActionResult" that returns it as an HttpResponseMessage. But so long as this straightforward workaround is a reasonable fit, I'd consider that as a low priority request. Do you agree?

--
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

Brad Laney

unread,

Aug 29, 2012, 12:16:42 AM8/29/12

to dotnet...@googlegroups.com

Well, you might need to ask someone using self-hosted Web Api. I don't know if that one runs along MVC.

If it doesn't then there isn't a very simple solution.

For me this was the easiest solution that makes sense for us.

But I don't think self-host web api supports MVC action results.

Rich Miller

unread,

Aug 29, 2012, 10:36:43 AM8/29/12

to dotnet...@googlegroups.com

Brad,

Thanks for the idea, but unfortunately my project is self-hosted and I cannot self-host MVC 4. Therefore, my Web API has to be both authorization and resource server.

Rich

Rich Miller

unread,

Aug 29, 2012, 10:41:20 AM8/29/12

to dotnet...@googlegroups.com

Andrew,

I'd agree that the solution sounds good and that it is probably a low priority for most DNOA users since I would imagine there will be a lot fewer developers using the self-hosting capabilities of Web API.

Unfortunately, my requirements call for self-hosting, so I am going to have to find a way to generate the access token response in json format before the extension method is implemented. Is there a way to retrieve the access token, refresh token, and expires in value from the authorization server so that I can build my own HttpResponseMessage object with them as content? I suppose I could also try to work up my own extension method also.

Thanks,

Rich

Andrew Arnott

unread,

Aug 29, 2012, 11:18:51 AM8/29/12

to dotnet...@googlegroups.com

Rich,

Thanks for explaining the residual problem. Writing your own extension method is quite straightforward. All you have to do is create an HttpResponseMessage and set its properties based on what you observe in the DNOA OutgoingWebResponse type that is returned from HandleTokenRequest() method. And when you're done with the method, please consider contributing back to DNOA. :)

Let me know if you have specific questions on how to do this.

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

To view this discussion on the web visit https://groups.google.com/d/msg/dotnetopenid/-/cMO5hR9Y8cUJ.

Andrew Arnott

unread,

Oct 10, 2012, 12:29:18 PM10/10/12

to dotnet...@googlegroups.com

When using the client_credentials grant type, you never get a refresh token, per the spec.

--
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, Oct 9, 2012 at 4:45 AM, Adhikesh <adhike...@gmail.com> wrote:

Hi Rich,

What are the parameters you have send to get this response, i have send the parameters such as,
scope=admin&grant_type=client_credentials&client_id=zamd&client_secret=test1243

I am getting the reponse without refresh token, how to get the refresh token?

--
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/-/5Z6UFZZMuY0J.

To post to this group, send email to dotnet...@googlegroups.com.

To unsubscribe from this group, send email to dotnetopenid...@googlegroups.com.

Adhikesh

unread,

Oct 12, 2012, 12:52:56 AM10/12/12

to dotnet...@googlegroups.com

Thanks Andrew,

Actually, i used this link http://zamd.net/category/asp-net-web-apis/ to implement OAuth protocol, in this link mentioned that implementing "Resource Owner Password Flow", but the requesting for Client Credential Flow. After you mentioned the link at the first i.e., http://sourceforge.net/projects/dnoa/files/latest/, now i clearly understood how to get the refresh token for the resource owner password flow.

Request:

POST http://localhost:50172/OAuth/Token HTTP/1.1

User-Agent: Fiddler

Content-Type: application/x-www-form-urlencoded

Host: localhost:50172

Content-Length: 72

grant_type=password&client_id=sampleconsumer&username=adhi&password=adhi

Response:

{"access_token":"gAAAALtJjcazHI4DWq31hjA5jtn1G-V_D9g2AKPE3lotl5jC-gSRZtmB916vUw0guHrmN_71WrPgpsp1QEHIyAYknBa_IiXip_PYhamc77zRGLAyhz8yWQ7d7NRLke30GbS9XFzb0zrcZD4Rr4FAAg2DF_Ta1m6MOFCJPBl-OFprkg2E9AAAAIAAAABZFhb7XB-SEJotoJW89esJ8tWgzbsWOy2KWvJxbGwS8Wi6dZTYZM4yfL98Np8vxC0WXtneSlNPCai4UcgxxsHhN1oMmH92-AEa6piUT_3SAGKojNCK6R_rebJ1sfAyYG4w-lBknLky4jme115mWWhq_pkJSzijq4eLYeYLSQIEIt2qV0KUzPz3CrxhGLxWQmvfHjwWF_VwDfGedxD4Pu5AqVQSIawTpxzP1OK7uvi3Brh-FDrcOjY8F5qyNwgXRqkb4EtvCxk8tcz4_UxP8LWmVNxwYlphKiLzDX1LEuK4jaA2betUWgQJO3__gK1HTxc","token_type":"bearer","expires_in":"120","refresh_token":"A2WJ!IAAAALSYmf4Fz9HYlzKphBHWj1E3cwkB3Ar8lxtzwwLSbZ-LgQAAAAHNAve-b8-Mx0jmWD3X0ELxWzWhk2urFOIBUGwKtGBrvUssVREvnbXhqBXtettbQQ0XxBzvslM1V4TKXrN2BaO74ygXfzJBak9Zq9cAC7kV-pzWNn0g0k5LfGzu1JczCoC0bH1MDseLzAj389lXFNq-QpjglEcZADu4jGqjeeqheg"}

Reply all

Reply to author

Forward