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

Nat Sakimura sakimura at gmail.com
Mon Jul 29 08:39:27 UTC 2013


Could you give me a concrete text so that I will be able to understand your
point exactly.

Nat

On Jul 29, 2013, at 10:29, Anthony Nadalin <tonynad at microsoft.com> wrote:

  Not in our case as our auth server serves many tenants and each tenant
has many apps each app with different scopes, different revocation, etc,
server is not very granular



*From:* Torsten Lodderstedt
[mailto:torsten at lodderstedt.net<torsten at lodderstedt.net>]

*Sent:* Monday, July 29, 2013 1:19 AM
*To:* Anthony Nadalin
*Cc:* openid-specs-ab at lists.openid.net
*Subject:* RE: [Openid-specs-ab] Transient Client Secret Extension for OAuth



Based on our experiences I would state, this data is the same across apps
as this is server meta data.

Am 29.07.2013 10:13, schrieb Anthony Nadalin:

 A single authorization server can support thousands of apps, so a config
file is very problematic if not per  app and per app is very data
intensive. The other point is exposing information gives attack points and
to prevent those we have to get into authorization and seems we would
repeat all the xri/xrd



*From:* Torsten Lodderstedt
[mailto:torsten at lodderstedt.net<torsten at lodderstedt.net>]

*Sent:* Monday, July 29, 2013 1:08 AM
*To:* Anthony Nadalin
*Cc:* openid-specs-ab at lists.openid.net
*Subject:* RE: [Openid-specs-ab] Transient Client Secret Extension for OAuth



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<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

           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





-- 
Nat Sakimura (=nat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en





-- 
Nat Sakimura (=nat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en





-- 
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







_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20130729/3373b7a9/attachment-0001.html>


More information about the Openid-specs-ab mailing list