While this isn't the original use case I had in mind, this could be covered by something in the OAuth2 Instance extension:
http://tools.ietf.org/html/draft-richer-oauth-instance-00 -- Justin On Fri, 2011-04-08 at 12:22 -0400, Phil Hunt wrote: > Why not have the client app generate a random text string to be used as a > request secret. The random text string would be matched during all > subsequent requests by the client surrounding a particular authorization. > Assuming the endpoints all require TLS for request side operations it would > prevent interception issues and bind the authz code to a particular client > instance even when matching client credentials are used by an intercepting > hacker. > > Would this help to satisfy at least some of the client app instance > identification issues? > > Note: it had also occurred to me that client apps should have static > client_instance identifiers. In practical terms this might be tied to an IMEI > number for example on a smart phone or other static information. However, I > don't think it would solve this security issue since it would be easy to > imitate. The above solution suggests a changing random string instead. > > Phil > phil.h...@oracle.com > > > > > On 2011-04-08, at 12:10 AM, Skylar Woodward wrote: > > > Yes, I can see how this might seem confusing. Actually, we're > > authenticating the client with authorization server - not a resource > > request. On the MAC threads we discussed how the token can be used for > > both. Hopefully that clears everything up, but I'll briefly address some > > of the questions inline. > > > > On Apr 7, 2011, at 11:26 PM, Torsten Lodderstedt wrote: > > > >> Hi Skylar, > >> > >> Am 06.04.2011 18:02, schrieb Skylar Woodward: > >>> Well, I should elaborate. The method of authorization is open to the > >>> client, and in this case (Kiva), MAC tokens are being used. The client > >>> authenticates on the access_token request by presenting a MAC > >>> authentication header. Creating the MAC signature requires a secret. In > >>> the native client case, since there is no secret, it signs with the empty > >>> string. So, how would you interpret this mechanism? Are we using an empty > >>> string secret or signing without a secret? In terms of communicating to > >>> the developers, they are told they don't have a secret. For purposes of > >>> signing, they are instructed to sign with them empty string when they > >>> have no secret. > >> > >> You are talking about using the client secret to authenticate resource > >> server request, correct? This is not in scope of the core spec. I was > >> talking about authenticating the client with the authorization server. > >> > >> Apart from that, do you think singing with an empty string adds any > >> security to your solution? > > > > No. It's about congruence at this point. Also, a MAC token by definition is > > signed so it has to be some other assertion if it is not signed. > > > >> Moreover as far as I understand the MAC-Spec, it recommends to use > >> authorization server issued secrets to sign the request. So why do you > >> need a client secret for request signing? > >> > >>> Alternatively, one could use Bearer token for client authentication in > >>> this case where the token is just the client ID. To me this is more > >>> confusing because they must authenticate with different token types for > >>> secret vs. non-secret. Other opinions? > >> > >> I'm confused now, why is the token the client id? A token is used by the > >> authorization server and may contain (or refer to) any data you need to > >> authorize access of the client to the resource server. > > > > Right, you're confusing the spec with the use. I'm considering the case of > > a simple Bearer assertion in cases of client authentication where clients > > have no secret since an ID/password assertion would imply an empty-string > > password or secret. As Marius said, we're splitting hairs at this point. > > Section 3.1 makes no notes on the possible value of client_secret for > > clients w/o secrets, so the assumption was that a value of > > "client_secret=&..." would be ignored resulting in an invalid Client > > Password submission. > > > >> > >>> As to the question of interoperability, the fact that OAuth allows > >>> freedom of choice to the AS for method of authentication makes this point > >>> moot. Would you agree? (short of various providers could pooling together > >>> to standardize on an auth method outside of the spec). > >> > >> What authentication are you refering to? Who do you want to authenticate? > > > > Client authentication. Section 3.2. > > > >> > >> regards, > >> Torsten. > >> > >>> > >>> > >>> On Apr 4, 2011, at 10:15 PM, tors...@lodderstedt.net wrote: > >>> > >>>> Hi Skylar, > >>>> > >>>> Thank you for sharing this information with us. Some thougts: > >>>> > >>>> The empty string makes your implementation syntactically compliant but > >>>> does obviously not comply with its semantics and the security > >>>> considerations/expectations associated with a secret. Moreover, what > >>>> about interoperability? > >>>> > >>>> I think not using secrets for such clients is the honest solution. We > >>>> can just change the spec's text to express what we think is the right > >>>> way. > >>>> > >>>> regards, > >>>> Torsten. > >>>> Gesendet mit BlackBerry® Webmail von Telekom Deutschland > >>>> > >>>> -----Original Message----- > >>>> From: Skylar Woodward<sky...@kiva.org> > >>>> Date: Mon, 4 Apr 2011 19:14:53 > >>>> To: Torsten Lodderstedt<tors...@lodderstedt.net> > >>>> Cc: Zeltsan, Zachary (Zachary)<zachary.zelt...@alcatel-lucent.com>; Kris > >>>> Selden<kris.sel...@gmail.com>; oauth@ietf.org<oauth@ietf.org> > >>>> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth > >>>> > >>>> In our implementation (not yet public) we accept the empty string ("") > >>>> as the value for clients not issued secrets. While this was done to > >>>> simplify the interface and implementation, it would make it compliant in > >>>> my view. In this case, the authorization server is validating the > >>>> credentials, which are the client ID and the empty string, which is > >>>> equivalent security-wise to any other length of "secret" issued to a > >>>> native client. > >>>> > >>>> Besides, for many providers, the client credentials will only be a > >>>> client ID. They would plan to secure all exchanges over TLS and > >>>> credentials serve just as a tracking device or at best, a weak form of > >>>> identification. > >>>> > >>>> skylar > >>>> > >>>> On Apr 4, 2011, at 5:01 PM, Torsten Lodderstedt wrote: > >>>> > >>>>> Am 04.04.2011 21:38, schrieb Zeltsan, Zachary (Zachary): > >>>>>> According to section "6 Refreshing an Access Token" (-13.txt), client > >>>>>> when making a request for exchanging a refresh token for an access > >>>>>> token has to include its authentication credentials, and the > >>>>>> "authorization server MUST validate the client credentials". > >>>>>> How can this be done if a client is an application that can't have a > >>>>>> client secret? > >>>>>> The authorization code grant does require client authentication (per > >>>>>> section 4.1): > >>>>>> > >>>>>> (D) The client requests an access token from the authorization > >>>>>> server's token endpoint by authenticating using its client > >>>>>> credentials, and includes the authorization code received in the > >>>>>> previous step. > >>>>>> > >>>>>> It appears that the clients that cannot keep its secret cannot use (be > >>>>>> issued) the refresh tokens. > >>>>> In my opinion, this part of the spec is misleading. Authorization code > >>>>> MUST be possible without client authentication. Otherwise, OAuth is > >>>>> useless for native apps. > >>>>> > >>>>> http://tools.ietf.org/html/draft-lodderstedt-oauth-securityconsiderations-01#section-2.10 > >>>>> describes how the flow can be protected in such cases. > >>>>> > >>>>> regards, > >>>>> Torsten. > >>>>>> Zachary > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > >>>>>> Of Marius Scurtescu > >>>>>> Sent: Monday, April 04, 2011 2:30 PM > >>>>>> To: Kris Selden > >>>>>> Cc: oauth@ietf.org > >>>>>> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth > >>>>>> > >>>>>> On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden<kris.sel...@gmail.com> > >>>>>> wrote: > >>>>>>> A typical iPhone app cannot be shipped with a client secret and > >>>>>>> rightly or wrongly users expect to only have to enter their > >>>>>>> credentials once. > >>>>>>> > >>>>>>> What is the best profile to use for an app that can't have a client > >>>>>>> secret and needs a refresh token or a long lived access token? > >>>>>> The authorization code grant, aka web server flow. > >>>>>> > >>>>>> The spec is misleading in this respect IMO. > >>>>>> > >>>>>> Marius > >>>>>> _______________________________________________ > >>>>>> OAuth mailing list > >>>>>> OAuth@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>>> _______________________________________________ > >>>>>> OAuth mailing list > >>>>>> OAuth@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/oauth > >>>>> _______________________________________________ > >>>>> OAuth mailing list > >>>>> OAuth@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
