Resource Owner Password Credentials Grant and Refresh Token?

[fantastischIdee]

In the Resource Owner Password Credentials Grant I can get a Refresh Token back from the Authorization Server. This is working fine with DNOA. I don't need to specify the client (client_id / client_secret)

When I want to use the Refresh Token, then I need to specify the client. Is this correct? 

Can I specity the client using the body parameters? Or do I need to use HTTP Basic Authorization?

[Andrew Arnott]

The client id should be the same for when you obtain the refresh token as when you send it back in for an access token.  If you didn't supply it before, you shouldn't supply it later.  If DNOA supports no client_id to obtain the refresh token but gives an error when you try to get a new access token with no client_id, then that's a bug in DNOA and will you please file it?
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

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

[fantastischIdee]

Ok, will do. Thanks.

[fantastischIdee]

Ok, I solved it by supplying the client id in the first request for an access token (Authorize). DNOA accepts the client id and client secret, even in the Resource Owner Password Credentials Grant! Although this is not part of the spec. Maybe the spec can be changed to allow the client_id / client_secret optionally in this specific grant?

On Thursday, August 16, 2012 4:09:17 PM UTC+2, Andrew Arnott wrote:

[Andrew Arnott]

I agree it's not clear, but the spec does in fact allow for (and even expect) client creds to be included with any grant type, IIRC.

Sent from my Windows Phone

---

From: fantastischIdee
Sent: 8/17/2012 8:52 AM
To: dotnet...@googlegroups.com
Subject: Re: [dotnetopenauth] Resource Owner Password Credentials Grant and Refresh Token?

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

[fantastischIdee]

Hi Andrew,

previous post were a result of testing it from an html/javascript client.

Now I'm trying to use your DNOA UserAgentClient, and I ran into the next problems:

I'm initializing the UserAgentClient like this 

• wcf = new UserAgentClient(authServer, "client_id", "client_secret");
  

Next step is to get an AccessToken:            

• AccessToken = wcf.ExchangeUserCredentialForToken(txtUsername.Text, txtPassword.Text);
  

I think the ExchangeUserCredentialForToken is not using the client_id / client_secret ? So the returned accesstoken does NOT include the client_id. 

Then when trying to Refresh the AccessToken:

• wcf.RefreshAuthorization(AccessToken)
  

I also think the client_id / client_secret is not send over? I get an invalid client_id msg, so I'm not able to refresh anything in this particular flow.

Can you please verify what I'm trying to say here. Is this a bug or am I missing things? Is there a workaround possible?

Thanks,

Hans

Op vrijdag 17 augustus 2012 18:41:22 UTC+2 schreef Andrew Arnott het volgende:

[Andrew Arnott]

I think this is because UserAgentClient is designed for use by installed applications, which generally speaking cannot keep a secret.  If this is an installed client, how are you proposing to keep a secret?  If this is a web server, can you use WebServerClient?

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

[fantastischIdee]

Probably you are right. But I was thinking/hoping this client_id/client_secret would be optional in this flow? 

The RefreshToken does not work with this client then. 

In the html/javascript client I was able to add the client_id/client_secret in the header of the request as a workaround to get the RefreshToken to work. But in the windows client I'm not able to add the client_id/client_secret? So I can't get the RefreshToken working in this windows client. Perhaps you know a workaround in this specific case?

Thanks,

Hans

Op dinsdag 28 augustus 2012 06:05:06 UTC+2 schreef Andrew Arnott het volgende:

[Andrew Arnott]

You shouldn't be using client_secrets in html/javascript clients (since javascript can't keep a secret).  The same is typically true for your Windows client apps.  

The fix in DNOA would likely be to allow refresh tokens to be issued to and consumed by clients without secrets, which the OAuth2 spec started allowing in recent drafts but this part of DNOA was coded against an earlier draft.  

So there is a bug here, but in the mean time, I suggest you reconsider your use of secrets in clients that don't run on your web server.  In the meantime, since you're using an exchange user credential flow, the WebServerClient should probably work for you on the non web-server client.

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

[fantastischIdee]

Hi Adrew,

I understand what you are saying. 

It would be nice though if, for client usage statistics, the client_id could be in each access token. Also for windows clients. It would therefore be nice if the ExchangeUserCredentialForToken method would except optional parameters client_id and client_secret:

ExchangeUserCredentialForToken(string userName, string password, IEnumerable<string> scopes = null, string clientIdentifier = null, string clientSecret = null)

This same method is used by WebServerClient and UserAgentClient. So changing the client did not help me.

I also tried to do changes myself in the Source Code but ran into problems with the signing of your dll. If I have to do without the client_id, can you please tell me when I can expect the new release of DNOA where a refreshing a token is possible without client_id?

Thanks for all your help.

Hans

[fantastischIdee]

Reading the spec again, I found in 2.3.1. Client Password, that although not RECOMMENDED, the authorization server MAY support including the client credentials in the request body. Maybe this is an opening to add the optional parameters client_id, client_secret in ExchangeUserCredentialForToken ?

[Andrew Arnott]

The client_id is already included in the access token, when the authorization server knows what it is.  The client_id isn't included in the ExchangeUserCredentialForToken as a parameter because you instead set it on the ClientBase instance itself.  Where the client_id shows up in the HTTP request (whether in the body or Authorization header) is irrelevant to this... so long as it appears somewhere.  

If you haven't already filed a bug stating that DNOA won't include the ClientBase.ClientIdentifier in the exchange user password request, please do so.  I can't promise a timeline for a fix though.

Thanks.

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

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