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?
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 <http://bit.ly/dnoawish>?
--
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 Wed, Aug 15, 2012 at 1:21 AM, fantastischIdee
<fantastischi...@gmail.com>wrote:
> 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?
> --
> 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 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 Thursday, August 16, 2012 4:09:17 PM UTC+2, Andrew Arnott wrote:
> 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 <http://bit.ly/dnoawish>? > -- > 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 Wed, Aug 15, 2012 at 1:21 AM, fantastischIdee <fantast...@gmail.com<javascript:> > > wrote:
>> 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?
>> -- >> 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<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.
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:
> 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 <http://bit.ly/dnoawish>? > -- > 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 Wed, Aug 15, 2012 at 1:21 AM, fantastischIdee <fantast...@gmail.com<javascript:> > > wrote:
>> 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?
>> -- >> 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<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.
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: dotnetopenid@googlegroups.com
Subject: Re: [dotnetopenauth] Resource Owner Password Credentials Grant and
Refresh Token?
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:
> 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 <http://bit.ly/dnoawish>?
> --
> 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 Wed, Aug 15, 2012 at 1:21 AM, fantastischIdee <fantast...@gmail.com<javascript:>
> > wrote:
>> 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?
>> --
>> 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<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.
> --
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/-/1WsVQht4EWkJ.
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.
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");
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:
> 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 <javascript:> > Subject: Re: [dotnetopenauth] Resource Owner Password Credentials Grant > and Refresh Token?
> 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:
>> 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 <http://bit.ly/dnoawish>? >> -- >> 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 Wed, Aug 15, 2012 at 1:21 AM, fantastischIdee <fantast...@gmail.com>wrote:
>>> 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?
>>> -- >>> 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.
>> -- > 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/-/1WsVQht4EWkJ. > 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.
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
On Mon, Aug 27, 2012 at 12:38 AM, fantastischIdee <fantastischi...@gmail.com
> wrote:
> 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");
> 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:
>> 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?
>> 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:
>>> 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 <http://bit.ly/dnoawish>?
>>> --
>>> 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 Wed, Aug 15, 2012 at 1:21 AM, fantastischIdee <fantast...@gmail.com>wrote:
>>>> 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?
> 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.
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:
> 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
> On Mon, Aug 27, 2012 at 12:38 AM, fantastischIdee <fantast...@gmail.com<javascript:> > > wrote:
>> 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");
>> 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:
>>> 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?
>>> 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:
>>>> 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 <http://bit.ly/dnoawish>? >>>> -- >>>> 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 Wed, Aug 15, 2012 at 1:21 AM, fantastischIdee <fantast...@gmail.com>wrote:
>>>>> 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?
>> 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.
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
On Tue, Aug 28, 2012 at 12:35 PM, fantastischIdee <fantastischi...@gmail.com
> wrote:
> 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:
>> 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
>> On Mon, Aug 27, 2012 at 12:38 AM, fantastischIdee <fantast...@gmail.com>wrote:
>>> 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");
>>> 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:
>>>> 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?
>>>> 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:
>>>>> 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 <http://bit.ly/dnoawish>?
>>>>> --
>>>>> 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 Wed, Aug 15, 2012 at 1:21 AM, fantastischIdee <fantast...@gmail.com
>>>>> > wrote:
>>>>>> 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?
>>> 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<http://groups.google.com/group/dotnetopenid?hl=en>
>>> .
> 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.
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?
On Wednesday, August 29, 2012 5:09:53 PM UTC+2, Andrew Arnott wrote:
> 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
> On Tue, Aug 28, 2012 at 12:35 PM, fantastischIdee <fantast...@gmail.com<javascript:> > > wrote:
>> 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:
>>> 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
>>> On Mon, Aug 27, 2012 at 12:38 AM, fantastischIdee <fantast...@gmail.com>wrote:
>>>> 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");
>>>> 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:
>>>>> 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?
>>>>> 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:
>>>>>> 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 <http://bit.ly/dnoawish>? >>>>>> -- >>>>>> 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 Wed, Aug 15, 2012 at 1:21 AM, fantastischIdee < >>>>>> fantast...@gmail.com> wrote:
>>>>>>> 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?
>>>> 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<http://groups.google.com/group/dotnetopenid?hl=en> >>>> .
>> 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.
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 ?
On Tuesday, September 4, 2012 12:41:27 PM UTC+2, fantastischIdee wrote:
> 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
> On Wednesday, August 29, 2012 5:09:53 PM UTC+2, Andrew Arnott wrote:
>> 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
>> On Tue, Aug 28, 2012 at 12:35 PM, fantastischIdee <fantast...@gmail.com>wrote:
>>> 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:
>>>> 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
>>>> On Mon, Aug 27, 2012 at 12:38 AM, fantastischIdee <fantast...@gmail.com >>>> > wrote:
>>>>> 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");
>>>>> 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:
>>>>>> 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?
>>>>>> 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:
>>>>>>> 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 <http://bit.ly/dnoawish>? >>>>>>> -- >>>>>>> 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 Wed, Aug 15, 2012 at 1:21 AM, fantastischIdee < >>>>>>> fantast...@gmail.com> wrote:
>>>>>>>> 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?
>>>>>>> -- >>>>>> 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/ >>>>>> **ms**g/dotnetopenid/-/**1WsVQht4EWkJ<https://groups.google.com/d/msg/dotnetopenid/-/1WsVQht4EWkJ> >>>>>> . >>>>>> 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<http://groups.google.com/group/dotnetopenid?hl=en> >>>>>> .
>>>>> 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<http://groups.google.com/group/dotnetopenid?hl=en> >>>>> .
>>> 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.
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
On Tue, Sep 4, 2012 at 5:09 AM, fantastischIdee
<fantastischi...@gmail.com>wrote:
> 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 ?
> On Tuesday, September 4, 2012 12:41:27 PM UTC+2, fantastischIdee wrote:
>> 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
>> On Wednesday, August 29, 2012 5:09:53 PM UTC+2, Andrew Arnott wrote:
>>> 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
>>> On Tue, Aug 28, 2012 at 12:35 PM, fantastischIdee <fantast...@gmail.com>wrote:
>>>> 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:
>>>>> 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
>>>>> On Mon, Aug 27, 2012 at 12:38 AM, fantastischIdee <
>>>>> fantast...@gmail.com> wrote:
>>>>>> 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");
>>>>>> 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:
>>>>>> 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:
>>>>>>> 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?
>>>>>>> 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:
>>>>>>>> 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 <http://bit.ly/dnoawish>?
>>>>>>>> --
>>>>>>>> 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 Wed, Aug 15, 2012 at 1:21 AM, fantastischIdee <
>>>>>>>> fantast...@gmail.com> wrote:
>>>>>>>>> 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?
>>>>>> To post to this group, send email to dotnet...@googlegroups.com.
>>>>>> To unsubscribe from this group, send email to dotnetopenid...@**
>>>>>> googlegroups.**com.
