[Openid-specs-ab] Transient Client Secret Extension for OAuth

Torsten Lodderstedt torsten at lodderstedt.net
Mon Jul 29 08:08:04 UTC 2013


 

Can you give an example? 

Am 29.07.2013 10:03, schrieb Anthony
Nadalin: 

> I think this gets us in a bind with information exposure,
as this all can be very app dependent and not authorization server
general 
> 
> FROM: openid-specs-ab-bounces at lists.openid.net
[mailto:openid-specs-ab-bounces at lists.openid.net] ON BEHALF OF Torsten
Lodderstedt
> SENT: Monday, July 29, 2013 12:58 AM
> TO:
openid-specs-ab at lists.openid.net
> SUBJECT: Re: [Openid-specs-ab]
Transient Client Secret Extension for OAuth 
> 
> Hi all, 
> 
> I think
OAuth authorization servers need a way to announce their capabilities
(e.g. grant types, dyn client reg, revocation, support for tcse :-)) and
respective endpoints. Using a config file at a well-known location 
> 
>
/.well-known/oauth-configuration
> 
> seems straightforward. For
authorization servers, which are also OIDC OPs, the same (or a
different) file might be exposed at 
> 
>
/.well-known/openid-configuration. 
> 
> Thoughts? 
> 
> regards,
>
Torsten. 
> 
> Am 29.07.2013 09:45, schrieb Nat Sakimura: 
> 
>> Hmmm.
Then, the client has lost its capability to find out whether the server
is secure or not dynamically. 
>> 
>> Do you mean that the client should
find it out out-of-band? 
>> 
>> That's possible, and is more OAuthy.

>> 
>> So, instead of current 3.2, it can just state : 
>> 
>> The
client MUST find out if the server supports this mode before issuing the
authorizaiton request. The exact method of how it can be done is out of
scope. 
>> 
>> Is that what you mean? 
>> 
>> Nat 
>> 
>> 2013/7/29
Brian Campbell <bcampbell at pingidentity.com> 
>> 
>>> Pretty much just
removing 3.1 and 3.2 and 2.2 from your draft. 
>>> 
>>> On Mon, Jul 29,
2013 at 9:36 AM, Nat Sakimura <sakimura at gmail.com> wrote: 
>>> 
>>>>
Yup. It is too late. The client needs to know whether the server is
secure or not to start with. 
>>>> 
>>>>> I still think that a base
definition of this shouldn't try and address discovering or publishing
support for the functionality. 
>>>> 
>>>> Could you kindly propose a
concrete method? A concrete text would be even better. 
>>>> 
>>>>
2013/7/29 Brian Campbell <bcampbell at pingidentity.com> 
>>>> 
>>>>> As
John pointed out, putting metainfo about support into the token response
is too late in the flow. 
>>>>> 
>>>>> I still think that a base
definition of this shouldn't try and address discovering or publishing
support for the functionality. 
>>>>> 
>>>>> On Mon, Jul 29, 2013 at
9:28 AM, Nat Sakimura <sakimura at gmail.com> wrote: 
>>>>> 
>>>>>> OK.
Fair enough. 
>>>>>> 
>>>>>> I will change it to the invalid_grant.

>>>>>> 
>>>>>> What do you think about the idea for "meta"? 
>>>>>>

>>>>>> 2013/7/29 Brian Campbell <bcampbell at pingidentity.com> 
>>>>>>

>>>>>>> It's really not client authentication. It's something that
links the initial authorization request with the corresponding access
token request, which enables detecting a particular problem/attack.
Similar to a mismatch on the redirect URI value between the
authorization request and the corresponding access token request, it's
the grant (or transaction) that is invalid. 
>>>>>>> 
>>>>>>>
http://tools.ietf.org/html/rfc6749#section-5.2 [4]
>>>>>>> 
>>>>>>>
invalid_grant
>>>>>>> 
>>>>>>> The provided authorization grant (e.g.,
authorization
>>>>>>> 
>>>>>>> code, resource owner credentials) or
refresh token is
>>>>>>> 
>>>>>>> invalid, expired, revoked, does not
match the redirection
>>>>>>> 
>>>>>>> URI used in the authorization
request, or was issued to
>>>>>>> 
>>>>>>> another client. 
>>>>>>>

>>>>>>> Discovery is maybe useful but is definitely not necessary. What
is necessary is to define the parameter(s) and their treatment on the
authorization request and access token request so that clients and
servers can interop. 
>>>>>>> 
>>>>>>> On Mon, Jul 29, 2013 at 9:07 AM,
Nat Sakimura <sakimura at gmail.com> wrote:
>>>>>>> 
>>>>>>>> Hi Brian,

>>>>>>>> 
>>>>>>>> inline: 
>>>>>>>> 
>>>>>>>> 2013/7/29 Brian Campbell
<bcampbell at pingidentity.com>
>>>>>>>> 
>>>>>>>>> IMHO, invalid_grant is
the proper error response code, not invalid_client.
>>>>>>>> 
>>>>>>>> I
have thought a bit about that when I was writing it down. 
>>>>>>>>

>>>>>>>> invalid_grant is concerned about the token which has been
previously issued. 
>>>>>>>> 
>>>>>>>> invalid_client is concerned about
the client authentication. 
>>>>>>>> 
>>>>>>>> In the initial path, I
had it as invalid_grant, then, I thought - well, it is the client

>>>>>>>> 
>>>>>>>> authentication that is failing when the client has
provided invalid tcs. 
>>>>>>>> 
>>>>>>>> The code is correct. It is the
client authentication which is going wrong, is it not? 
>>>>>>>>

>>>>>>>>> Along the same lines, I'd like to see it named something more
like "message correlation id" rather than anything involving client
secret.
>>>>>>>> 
>>>>>>>> The name "message correlation identifier"
does not convey the nature of the parameter, which is the high entropy
credential for the client. Just for the sake of the correlation, it does
not have to have a high entropy. Thus, I have chosen the name. 
>>>>>>>>

>>>>>>>> I have thought of making a new file but then that would amount
to having the client hit those discovery endpoints twice. 
>>>>>>>>

>>>>>>>> I did not want the duplicate situation that resulted in the
dynamic client registration. That's why I am referring OpenID Connect.

>>>>>>>> 
>>>>>>>> OpenID Connect originated the Discovery and
Registration. On the hind site, even registration should have been
referring OpenID Connect documents instead of duplicating. At least,
that's how academic papers work :-) 
>>>>>>>> 
>>>>>>>> Another idea is
to have the metadata come back in the token response. 
>>>>>>>>

>>>>>>>> I actually prefer this. It increases the server traffic a bit,
though. 
>>>>>>>> 
>>>>>>>> The way it works is this. 
>>>>>>>>

>>>>>>>> Instead of doing the discovery and caching it at the client,
the client finds the server capability from the token endpoint
reference. For this, the server includes something like: 
>>>>>>>>

>>>>>>>> "meta": { 
>>>>>>>> 
>>>>>>>> "tcs_supported":true; 
>>>>>>>>

>>>>>>>> } 
>>>>>>>> 
>>>>>>>> You guys know that I like this idea
because then I would have a stub to put link relationship there as well.

>>>>>>>> 
>>>>>>>> Do you like the idea? If so, I can update the draft
in this manner. 
>>>>>>>> 
>>>>>>>> Well, perhaps I should anyways.

>>>>>>>> 
>>>>>>>> Thanks for pointing out. 
>>>>>>>> 
>>>>>>>> Best,

>>>>>>>> 
>>>>>>>> Nat 
>>>>>>>> 
>>>>>>>> On Sun
>>>>>>>> 
>>>>>>>>>
m">sakimura at gmail.com> wrote: 
>>>>>>>>> 
>>>>>>>>>> As some of you
knows, passing the code securely to a native app on iOS platform is next
to impossible. Malicious application may register the same custom scheme
as the victim application and hope to obtain the code, whose success
rate is rather high. 
>>>>>>>>>> 
>>>>>>>>>> We have discussed about it
during the OpenID Conenct Meeting at IETF 87 today, and I have captured
the discussion in the form of I-D. It is pretty short and hopefully easy
to read. 
>>>>>>>>>> 
>>>>>>>>>> You can find it at: 
>>>>>>>>>>

>>>>>>>>>> https://bitbucket.org/Nat/drafts/src/ [1] 
>>>>>>>>>>

>>>>>>>>>> Comments are welcome. 
>>>>>>>>>> 
>>>>>>>>>> -- 
>>>>>>>>>>
Nat Sakimura (=nat) 
>>>>>>>>>> 
>>>>>>>>>> Chairman, OpenID
Foundation
>>>>>>>>>> http://nat.sakimura.org/ [2]
>>>>>>>>>> @_nat_en

>>>>>>>>>> 
>>>>>>>>>>
_______________________________________________
>>>>>>>>>>
Openid-specs-ab mailing list
>>>>>>>>>>
Openid-specs-ab at lists.openid.net
>>>>>>>>>>
http://lists.openid.net/mailman/listinfo/openid-specs-ab [3]
>>>>>>>>>

>>>>>>>>> -- 
>>>>>>>>> Nat Sakimura (=nat) 
>>>>>>>>> 
>>>>>>>>>
Chairm
>>>>>>>> undation
>>>>>>>> http://nat.sakimura.org/ [2]
>>>>>>>>
@_nat_en
>>>>>> 
>>>>>> -- 
>>>>>> Nat Sakimura (=nat) 
>>>>>> 
>>>>>>
Chairman, OpenID Foundation
>>>>>> http://nat.sakimura.org/ [2]
>>>>>>
@_nat_en
>>>> 
>>>> -- 
>>>> Nat Sakimura (=nat) 
>>>> 
>>>> Chairman,
OpenID Foundation
>>>> http://nat.sakimura.org/ [2]
>>>> @_nat_en
>> 
>>
-- 
>> Nat Sakimura (=nat) 
>> 
>> Chairman, OpenID Foundation
>>
http://nat.sakimura.org/ [2]
>> @_nat_en 
>> 
>>
_______________________________________________
>> 
>> Openid-specs-ab
mailing list
>> 
>> Openid-specs-ab at lists.openid.net
>> 
>>
http://lists.openid.net/mailman/listinfo/openid-specs-ab [3]




Links:
------
[1] https://bitbucket.org/Nat/drafts/src/
[2]
http://nat.sakimura.org/
[3]
http://lists.openid.net/mailman/listinfo/openid-specs-ab
[4]
http://tools.ietf.org/html/rfc6749#section-5.2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130729/c239083b/attachment-0001.html>


More information about the Openid-specs-ab mailing list