Hi Doug,
Am 19.05.2011 04:09, schrieb Doug Tangren:
Followup questions from draft 16
1. On storing user password for the resource owner creds flow. If the
client stores a access token along with the refresh token [1] to
refresh it, there should be no need to store the users password as
mentioned here [2] right?
Yes. That's what meant with "It reduces the overall risk of storing
username and password in the client".
2. What value does adding the client password to a basic auth encoded
header with duplicated client_id info add? [3]
The goal is a cleaner protocol design. The protocol design separates
client identification as part of the flow (URI parameter) and originator
authentication. While the client_id parameter is required, the
authentication can be omitted (unauthenticated access) or performed
using other authentication mechanisms. And such mechanisms not
neccessarily use client_id's. Moreover, the spec just says, "The
authorization server MUST ensure the two identifiers belong to the same
client". So the client_id's (request parameter and header) may differ.
<someone else should answer questions 3-5, pls.>
6. Native modified usage of the auth code flow - "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" [7]
The issue was brought up earlier that clients the implicit flow should
not be issued a refresh token because there'd be no way for the server
to identify the client without the client secret. Here its suggested
they do just that. Does this mean there may be a step added in the
implicit flow in the future that will enable the client to refresh
their access token without involving the user if the user has already
chosen to authorize the app?
The text recommends to use the authorization code grant type not the
implicit grant.
regards,
Torsten.
Those are some of the things that jump out at me. I'll read if a few
more times so see if anything else comes up.
I'm happy to see this is all coming together! This is great work.
[1]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-4.3.3
[2]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-10.12
[3]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-3.1
[4]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-1.5
[5]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-2.2
[6]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-4.3.2
[7]: http://tools.ietf.org/html/draft-ietf-oauth-v2-16#section-9
-Doug Tangren
http://lessis.me
_______________________________________________
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
