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