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
