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

Torsten Lodderstedt torsten at lodderstedt.net
Mon Jul 29 07:57:33 UTC 2013


 

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. 
>>>>>>> 
>>>>>>>> f the parameter(s)
should not require discovery or rely on any of the Connect documents.

>>>>>>>> 
>>>>>>>> OAuth generally does not need discovery. However,
this spec really needs it, at least in one form or another.
>>>>>>>

>>>>>>> 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,
Jul 28, 2013 at 9:39 PM, Nat Sakimura <
>>>>> 
>>>>> -- 
>>>>> 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/decac036/attachment.html>


More information about the Openid-specs-ab mailing list