Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 04 Apr 2011 18:48:16 +0200

+1

Am 01.04.2011 03:00, schrieb Marius Scurtescu:
> On Thu, Mar 31, 2011 at 4:56 PM, Phil Hunt<[email-masked]>  wrote:
>> Done.
>>
>> It isn't quite what the flow shows in the earlier diagram. I was originally avoiding client type and trying to focus on section 4 options.
>>
>> But this should be a better diagram.
>>
>> http://independentidentity.blogspot.com/2011/03/oauth-flows-extended.html
> A native app with no client secret is still advised to use the
> implicit grant, which is wrong IMO.
>
> The right question I think is "does the client need long term offline access"?
>
> JavaScript clients typically don't need offline access (only with the
> user at the browser). Some native apps and web apps could be OK with a
> short term offline access, one off import for example.
>
> Marius

---

From: Kris Selden <[email-masked]>
Date: Mon, 4 Apr 2011 10:47:18 -0700

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?

Why doesn't implicit_grant have a refresh_token? I would think a non-expiring access_token like FB offline_access would be worse option since it is transmitted to more end points.

A lot of FB Connect sites request offline_access when you connect. Like Foursquare, Quora, Gowalla for example.

On Mar 31, 2011, at 6:00 PM, Marius Scurtescu wrote:

> On Thu, Mar 31, 2011 at 4:56 PM, Phil Hunt <[email-masked]> wrote:
>> Done.
>> 
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Phil Hunt <[email-masked]>
Date: Mon, 4 Apr 2011 11:02:28 -0700

See below...

Phil
[email-masked]

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

My understanding (and I'm not an iOS expert) is that each iOS application has a secure keystore where the client credential could be stored. I am told this is fairly straight forward. The client app would issue a call out to the external safari browser for the authorization with a redirect back to the app registered (local redirect) such as myapp://authorization_code

Note that in security considerations it is recommended against having an app collect user credentials directly. It is always preferred to use the external browser. This is so that the user can see the UI as being legit and that appropriate security measures are in place. It also protects the client app from problems that might occur from screen scraping a service provider UI that is subject to change.
> 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?

You can use the typical client credential flow as per my comment above.  If no client credential you are forced to use "Implicit" which I don't believe was intended for these types of apps. Note that Implicit also is restricted to uid/password type user credential.
> Why doesn't implicit_grant have a refresh_token? I would think a non-expiring access_token like FB offline_access would be worse option since it is transmitted to more end points.

The issuing of a token in Implicit flow depends solely on the authentication of the end-user. Without client credentials you can't authenticate the client to refresh the token. Thus you must repeat the implicit flow every time.

---

From: Skylar Woodward <[email-masked]>
Date: Mon, 4 Apr 2011 14:21:20 -0400

Having worked many years with native Internet consumer software applications, and having worked in those teams in attempt to secure client secrets (be they keys or obfuscated dynamic algorithms), I can say with reasonable confidence that it is impossible to secure client credentials for publicly available applications (where the same credential is shared against all instances of the application).  Both iPhone and PlayStation represent some of the most formidable efforts to secure secrets or data in publicly distributed consumer products.  Systems on these have been successfully broken and this will continue to be the case.  Even if someone has a new technology to propose that they think can prove this wrong, there is no reliable record of success for hiding secrets in the field. We should assume any system distributed for public review can be reverse engineered, and secrets obtained.

I propose that for the sake of this discussion, we continue with the assumption that no native apps with public distribution are able to have client secrets.

(Btw, Kris seemed to be suggesting that users could be prompted to enter a (unique?) app ID and client secret, but this would complicate usability, working against the goals of OAuth in the first place. I'd agree - if native app users had to enter a custom client secret, they might as well obtain their own private access token and enter it instead, by passing OAuth completely).

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 4 Apr 2011 11:29:58 -0700

> 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

---

From: Skylar Woodward <[email-masked]>
Date: Mon, 4 Apr 2011 14:54:06 -0400

I agree with Marius' points. We plan to support the auth-code flow for native apps as well.  There is no reason why native apps can't perform a successful auth-code flow, they just do so without client credentials.  However, the spec doesn't make it clear that this is viable option.

skylar

---

From: Kris Selden <[email-masked]>
Date: Mon, 4 Apr 2011 12:09:52 -0700

I completely agree with you regarding not being able to authenticate a native client.

The problem with web flow is the user experience is bad for a native app.  Why does this matter?  Because of competition – if competitors use a user friendly but less secure method and the end user does not know it is bad for them, then because of market forces you have to do the same.

As a startup developer, I cannot tell the business side that our UI has to be worse than their Facebook app, Twitter client or Instagram on their phone because that isn't secure.  They're going to look at me like I'm crazy.

If the end user is ignorant, educating them comes at too high of a price for a startup.  The end user cares about their safety but assumes that big companies are the bar for security.

---

From: Anthony Nadalin <[email-masked]>
Date: Mon, 4 Apr 2011 19:12:58 +0000

> I completely agree with you regarding not being able to authenticate a native client.

I suggest you read the security considerations draft to make sure this is correct and points out the issues

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kris Selden
Sent: Monday, April 04, 2011 12:10 PM
To: Skylar Woodward
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth

The problem with web flow is the user experience is bad for a native app.  Why does this matter?  Because of competition - if competitors use a user friendly but less secure method and the end user does not know it is bad for them, then because of market forces you have to do the same.

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 4 Apr 2011 12:14:46 -0700

> The problem with web flow is the user experience is bad for a native app.  Why does this matter?  Because of competition – if competitors use a user friendly but less secure method and the end user…

User experience should be identical for both User-Agent and Web Server
flows. With User-Agent typically you get only a short lived access
token, so for more cases this will not work at all for native apps.

Marius

---

From: Phil Hunt <[email-masked]>
Date: Mon, 4 Apr 2011 12:28:50 -0700

Marius/Kris,

Are we talking about Native apps where no browser (internal or external) is available (e.g. set-top-box)?

If a browser is available, I would not want to confuse the user with authentication at the service provider with local branding of the app. OAuth does a nice job of keeping these separate as we've already seen in the OAuth 1 implementations. Per what Marius is saying, the user experience [for a particular resource provider] should be the same regardless of user-agent or web server.

If a browser is not available, I've seen out-of-band methods work very well too.  E.g. code via SMS, code via email. 

The issue that client credentials on installed apps aren't very good is becoming well known (see the other threads on authorization code security).  Even if well protected (which is debatable), the problem is there are many many clients with the same legit code. We need something that so that a server can determine it is accepting an access token request from the same client that originally requested an authorization.

There is also a follow on problem that without a unique client app (per instance) identifier, you can't easily revoke access to that client without impacting every other client with the same identifier.

Phil
[email-masked]

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Mon, 4 Apr 2011 14:38:40 -0500

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.

Zachary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Marius Scurtescu
Sent: Monday, April 04, 2011 2:30 PM
To: Kris Selden
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth

Marius

---

From: Justin Richer <[email-masked]>
Date: Mon, 4 Apr 2011 16:09:57 -0400

Agreed - we are planning to use the auth-code flow for native apps and
have no immediate plans to use implicit mode for native clients, either.
We'd be using the auth-code flow with a client id only and no client
secret, which I think is the pattern that everyone else is planning to
follow.

 -- justin

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 4 Apr 2011 13:46:43 -0700

> It appears that the clients that cannot keep its secret cannot use (be issued) the refresh tokens.

Right, so something has to give, otherwise there is no solution for native apps.

An authorization server will have to accept clients with no secrets.
Google chose to actually issue secrets even for native apps, with the
understanding that they cannot be guarded properly. It just keeps the
flows and code paths uniform.

Marius

---

From: Phil Hunt <[email-masked]>
Date: Mon, 4 Apr 2011 13:59:13 -0700

Does section 3.2 help you?
"In addition, the authorization server MAY allow unauthenticated access token requests when the client identity does not matter (e.g. anonymous client) or when the client identity is established via other means."

Phil
[email-masked]

---

From: Torsten Lodderstedt <[email-masked]>
Date: Mon, 04 Apr 2011 23:01:01 +0200

> 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.
> On Mon, Apr 4, 2011 at 10:47 AM, Kris Selden<[email-masked]>  wrote:

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Mon, 4 Apr 2011 17:49:47 -0500

Torsten,

I agree that the described measures would protect the native application clients. 
But the current specification, as I understand it, does not allow the use of the authorization code without client's authentication. It also requires client authentication whenever the refresh tokens are used. In my opinion the authorization code, as presently specified, is not suitable for an application "that can't have a client secret and needs a refresh token or a long lived access token".

I agree with Marius that unless the authorization code's specification is modified, it is not useful for the native applications.

Regards,   

Zachary
-----Original Message-----
From: Torsten Lodderstedt [mailto:[email-masked]] 
Sent: Monday, April 04, 2011 5:01 PM
To: Zeltsan, Zachary (Zachary)
Cc: 'Marius Scurtescu'; Kris Selden; [email-masked]
Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth

regards,
Torsten.

---

From: Skylar Woodward <[email-masked]>
Date: Mon, 4 Apr 2011 19:14:53 -0400

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:

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

---

From: Marius Scurtescu <[email-masked]>
Date: Mon, 4 Apr 2011 17:08:54 -0700

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

I am splitting hairs now, but according to the spec an empty parameter
value should be treated the same as if the parameter was not sent at
all. So, empty secret violates the requirement for the parameter to be
present.

Marius

---

From: Phil Hunt <[email-masked]>
Date: Mon, 4 Apr 2011 17:10:12 -0700

Read 3.2. I believe you'll find an escape clause there.

Phil
[email-masked]

---

From: [email-masked]
Date: Tue, 5 Apr 2011 05:15:12 +0000

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-masked]>
Date: Mon, 4 Apr 2011 19:14:53 
To: Torsten Lodderstedt<[email-masked]>
Cc: Zeltsan, Zachary (Zachary)<[email-masked]>; Kris Selden<[email-masked]>; [email-masked]<[email-masked]>
Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth

skylar

---

From: Justin Richer <[email-masked]>
Date: Tue, 5 Apr 2011 09:24:51 -0400

Phil,

It's completely within the normative language of the spec to do things
this way right now -- the question is how the editorial text surrounding
the normative text presents different flows and use cases and how to map
between them. As it's written in the latest drafts, it sounds like the
implicit flow is the best option for native clients, but that doesn't
match with current and planned deployments.

 -- Justin

---

From: Phillip Hunt <[email-masked]>
Date: Tue, 5 Apr 2011 07:55:51 -0700

Yes agreed. The way I read it any flow can omit client credential if they have another means to identify it. 

Phil

Sent from my phone.

---

From: Chuck Mortimore <[email-masked]>
Date: Tue, 5 Apr 2011 07:57:44 -0700

In respect to current deployments we have a pretty broad deployment of different clients using implicit grant.  We also support the code flow as described here, but haven't found good reason to use it.  

- cmort

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Tue, 5 Apr 2011 10:14:17 -0500

+1 for making the specification clear. It should say that the native application clients participating in the authorization code flow do not use the client secrets. 

Zachary
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, April 05, 2011 1:15 AM
To: Skylar Woodward
Cc: Zeltsan, Zachary (Zachary); Kris Selden; [email-masked]
Subject: AW: Re: [OAUTH-WG] Flowchart for legs of OAuth

Hi Skylar,

regards,
Torsten.
Gesendet mit BlackBerry(r) Webmail von Telekom Deutschland  

-----Original Message-----
From: Skylar Woodward <[email-masked]>
Date: Mon, 4 Apr 2011 19:14:53 
To: Torsten Lodderstedt<[email-masked]>
Cc: Zeltsan, Zachary (Zachary)<[email-masked]>; Kris Selden<[email-masked]>; [email-masked]<[email-masked]>
Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth

skylar

---

From: Skylar Woodward <[email-masked]>
Date: Wed, 6 Apr 2011 09:02:30 -0700

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.

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?

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 08 Apr 2011 08:26:42 +0200

Hi Skylar,

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

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?

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

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.

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

What authentication are you refering to? Who do you want to authenticate?

regards,
Torsten.

>> From: Skylar Woodward<[email-masked]>

---

From: Skylar Woodward <[email-masked]>
Date: Fri, 8 Apr 2011 00:10:01 -0700

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:

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

> What authentication are you refering to? Who do you want to authenticate?

Client authentication. Section 3.2.

---

From: Skylar Woodward <[email-masked]>
Date: Fri, 8 Apr 2011 00:35:35 -0700

I think I see the confusion now between this and Torsten's questions. The assumption is that if the client has no secret, no assertion would be made. No client authentication is performed. The app is essentially anonymous. That's how folks interpret this?

So while I agree in theory, I propose that many providers still want to know the proposed identity of client, primarily for statistics or record-tracking purposes. There is barely an incentive for a malicious client to forge that of a secret-less client other than to skew the statistics of that client. What's more, the Kiva system, as many others, allow developers to revoke or disable all tokens associated with their client. This would not be possible w/o some proposal of client ID during authorization. Native clients are clients without secrets, but the don't fall into the category of fully "anonymous" apps as I understand this term to be used in the spec.

So, perhaps this explains why we would allow password-less or secret-less identity to be passed during authorization. Rather than invent a new way to suggest identity in these cases, we simply use the same mechanism (MAC) with no secret. It's a valid argument that we should use another mechanism such as a provider-specific field or Bearer.

For what it's worth, we use the terminology VERIFIABLE and FORGEABLE in our documentation to refer to clients with secrets and those without, respectively. Forgeable clients are neither privileged nor punished (as it were) for their spoof-able nature - native clients are an important part of the ecosystem.

skylar

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 08 Apr 2011 18:13:25 +0200

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

One possible standard for clients without the capability to protect 
secrets would be to just omit secrets. Do you agree?
And the spec itself could (should in my opinion) set this standard.

regards,
Torsten.

---

From: Phil Hunt <[email-masked]>
Date: Fri, 8 Apr 2011 09:22:18 -0700

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

---

From: [email-masked]
Date: Fri, 8 Apr 2011 16:36:30 +0000

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.

-----Original Message-----
From: Phil Hunt <[email-masked]>
Date: Fri, 8 Apr 2011 09:22:18 
To: Skylar Woodward<[email-masked]>
Cc: Torsten Lodderstedt<[email-masked]>; Kris Selden<[email-masked]>; Zeltsan, Zachary \(Zachary\)<[email-masked]>; [email-masked]<[email-masked]>
Subject: Re: [OAUTH-WG] Flowchart for legs of OAuth

Phil
[email-masked]

---

From: Phil Hunt <[email-masked]>
Date: Fri, 8 Apr 2011 09:49:29 -0700

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

---

From: Skylar Woodward <[email-masked]>
Date: Fri, 8 Apr 2011 11:18:02 -0700

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.

---

From: Skylar Woodward <[email-masked]>
Date: Fri, 8 Apr 2011 11:27:11 -0700

Torsten, that's what the spec recommends already. That's my assumption for everything I've discussed thus far - that clients who can't keep secrets are never issued them and thus must omit them out of lack of having any.

We're just splitting hairs on the definition of "omit."  Also, there's confusion because not everyone has considered the alternative client auth methods apart from the 3.1 password mechanism. I feel a more productive discussion would be to discuss the details of what it means for a client to "omit" secrets for various auth mechanisms. So

- password auth
- HTTP MAC auth
- HTTP Basic?

Additionally if the Password Auth mechanism forbids omission of secrets (including sending empty string as a secret) then we should suggest an alternative, or advise that providers must use another self-defined mechanism for passing unauthenticated client IDs if they wish to require them for record tracking purposes.

skylar

On Apr 8, 2011, at 9:13 AM, Torsten Lodderstedt wrote:

> One possible standard for clients without the capability to protect secrets would be to just omit secrets. Do you agree?

---

From: Phil Hunt <[email-masked]>
Date: Fri, 8 Apr 2011 11:51:18 -0700

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

---

From: Justin Richer <[email-masked]>
Date: Mon, 11 Apr 2011 11:19:03 -0400

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

---

From: Phillip Hunt <[email-masked]>
Date: Mon, 11 Apr 2011 08:37:38 -0700

Will take a look. 

Phil

Sent from my phone.