I know I have harped on that too many times previously, but just for the
purpose of counting "votes," I think that option 2) is NOT an option.
(Vote: -2 for 2)
That leaves option 1) as a must as far as I am concerned.
Igor
On 6/28/2011 6:26 AM, Mark Mcgloin wrote:
The question below remains unanswered in relation to native apps being able
to use grant type auth code to utilize refresh tokens. Which of these is
the best option
1) Change oauth spec so client credentials are optional when requesting
access token for grant type 'authorization_code' and for refresh token
requests
2) Edit section 9 on security considerations to remove any references to
native apps using auth code
The difficulty with option 1 is how do you then prevent attackers using a
legitimate client identifier. If we change the spec to say the client
SHOULD pre-register it's redirect-uri, would that suffice?
Regards
Mark
oauth-boun...@ietf.org wrote on 23/05/2011 05:40:22:
From:
Shane B Weeden<swee...@au1.ibm.com>
To:
oauth@ietf.org
Date:
23/05/2011 06:26
Subject:
[OAUTH-WG] Draft 16 comment
Sent by:
oauth-boun...@ietf.org
First, I'd like to add my support for Brian Eaton's comments on Draft 16.
They actually helped clarify the comment I have below....
I found section 9 to be in contradiction to a part of section 6. In
particular in section 9:
Native applications SHOULD use the authorization code grant type flow
without client password credentials (due to their inability to keep
the credentials confidential) to obtain short-lived access tokens,
and use refresh tokens to maintain access.
In section 6 the specification is quite clear that client authentication
is
REQUIRED for the use of refresh tokens:
The authorization server MUST validate the client credentials, ensure
that the refresh token was issued to the authenticated client,
validate the refresh token, and verify that the resource owner's
authorization is still valid.
My understanding is that refresh tokens are being used as a kind of
long-lived, rolling "instance secret" for the native application and
represent the grant authorized by the end user during initial
establishment
of the authorization code which is used to get the first refresh token.
It seems to me this use case needs to be allowed for in the wording of
section 6.
Regards,
Shane.
_______________________________________________
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
