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

Brian Campbell bcampbell at pingidentity.com
Mon Jul 29 07:23:29 UTC 2013


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

           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.
>
>
>>
>> This is a general OAuth problem and I believe the solution should be
>> general too. Thus, at least the base definition of 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 <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/
>>>
>>> Comments are welcome.
>>>
>>> --
>>> Nat Sakimura (=nat)
>>> Chairman, OpenID Foundation
>>> http://nat.sakimura.org/
>>> @_nat_en
>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>>
>>
>
>
> --
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130729/00e10d33/attachment.html>


More information about the Openid-specs-ab mailing list