I don't think you are looking at it quite correctly. The token/auth code is a session asserted by the server. The generated secret is asserted by the client. This allows the server to detect more faults with the client or attempts to intercept a particular sequence.
I'm not yet convinced it is useful. I brought it up because of the ongoing issue of trying to uniquely authenticate clients. Phil [email protected] On 2011-04-08, at 11:18 AM, Skylar Woodward wrote: > I can't see the purpose of "generated secret" by the client. I fear this is > going to lead down the same confusing path as the last thread on auth codes. > > Essentially what you're asking for is a unique session ID per grant request. > If TLS is required across all connections to protect the generated secret/ID, > then this secret serves no security purpose. The token (and auth code > represented by it during the first leg) serves as the session ID anyway, so > the client-generated secret is redundant. Additionally you have to deal with > the provider rejecting secrets if they are not unique. > > Such a secret would provide no identity guarantee beyond the "same session" > guarantee provided the token. Any application can use an existing client ID, > make up a secret, and authenticate. The server knows nothing more about the > identity of the client. Identity and secrets must be established outside the > OAuth handshake - at the same point where application identity data (icon, > name, owner) is managed. > > > On Apr 8, 2011, at 9:49 AM, Phil Hunt wrote: > >> I am assuming the outbound requests are secured by TLS, but for various >> reasons the return path (e.g. the redirect) might not be. Thus, one >> restriction would be that the server never returns the code to the client. >> >> Thus, you could submit a secret simply for the purpose of verifying the same >> specific requestor for each operation. >> >> Phil >> [email protected] >> >> >> >> >> On 2011-04-08, at 9:36 AM, [email protected] wrote: >> >>> This would be another possible standard option. As you pointed out, it >>> would help to detect authz code theft even for native apps. It would not >>> help wrt client authorization since there are no properties associated with >>> the new credential. >>> >>> The key is: how does the authz server get to know this secret? As the >>> redirects are not fully protected against leaks (history, referers) I would >>> not pass it in as a parameter to the authz request. >>> >>> Regards, >>> Torsten. >>> Gesendet mit BlackBerry® Webmail von Telekom Deutschland >>> >>> -----Original Message----- >>> From: Phil Hunt <[email protected]> >>> Date: Fri, 8 Apr 2011 09:22:18 >>> To: Skylar Woodward<[email protected]> >>> Cc: Torsten Lodderstedt<[email protected]>; Kris >>> Selden<[email protected]>; Zeltsan, Zachary >>> \(Zachary\)<[email protected]>; >>> [email protected]<[email protected]> >>> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth >>> >>> 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 >>> [email protected] >>> >>> >>> >>> >>> 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, [email protected] 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<[email protected]> >>>>>>> Date: Mon, 4 Apr 2011 19:14:53 >>>>>>> To: Torsten Lodderstedt<[email protected]> >>>>>>> Cc: Zeltsan, Zachary (Zachary)<[email protected]>; >>>>>>> Kris Selden<[email protected]>; [email protected]<[email protected]> >>>>>>> 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: [email protected] [mailto:[email protected]] On >>>>>>>>> Behalf Of Marius Scurtescu >>>>>>>>> Sent: Monday, April 04, 2011 2:30 PM >>>>>>>>> To: Kris Selden >>>>>>>>> Cc: [email protected] >>>>>>>>> Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth >>>>>>>>> >>>>>>>>> On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden<[email protected]> >>>>>>>>> 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 >>>>>>>>> [email protected] >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>>> _______________________________________________ >>>>>>>>> OAuth mailing list >>>>>>>>> [email protected] >>>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>>>> _______________________________________________ >>>>>>>> OAuth mailing list >>>>>>>> [email protected] >>>>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/oauth >>> >> > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
