couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: OAuth for authorization (not authentication)
Date Mon, 18 Jul 2011 13:44:59 GMT
As also noted on IRC, you are indeed wrong, you just don't like the
granularity of the operation you are authorized to perform after
successfully authenticating. :)

B.

On 18 July 2011 14:23, Camille Harang <mammique@yooook.net> wrote:
> Hi all, as discussed yesterday on IRC, it seems that the OAuth layer of
> CouchDB only covers the authentication mechanisms of OAuth, but not the
> authorization mechanisms (if I understood correctly, tell me if I'm
> wrong). However, the authorization layer is IMHO the most interesting
> part of OAuth:
>
> http://tools.ietf.org/html/draft-ietf-oauth-v2-18 :
>
> Abstract
>
>   The OAuth 2.0 authorization protocol enables a third-party
>   application to obtain limited access to an HTTP service, either on
>   behalf of a resource owner by orchestrating an approval interaction
>   between the resource owner and the HTTP service, or by allowing the
>   third-party application to obtain access on its own behalf.
>
> But, as it's closely related to read access limitations (in time and
> scope), it doesn't fit well in the all-or-nothing ready access policy
> for a given database in CouchDB. After discussion, it seems that the
> proper way to do this with CouchDB is to set a DB per user and per
> permission. Following the example given in the OAuth RFC, where a user
> wants to grant access to his/her pictures (and only his/her pictures) to
> a printing shop for a limited time (time to print), it seems that in
> CouchDB we would need to set up a DB for the user's private data, and a
> for the the user's pictures (and for the user's bookmarks, and so on for
> each right's scope). Then we just need to grant or not read access to
> this or that DB, regarding the credentials of the third party request,
> but I don't know how to do this with the current ACL policy wich doesn't
> seems to match the OAuth's token system (the third party request must
> show a token, but how/where can I check it? How/where can I handle
> token's expiration time?).
>
> Do you think there is anyway to handle this? Or should I fallback to the
> "smart proxy" solution?
>
> Thanks,
>
> Regards,
>
> Camille.
>
> --
> The Good, the Bad and the Ugly under Creative Commons! https://yooook.net/r/lp1
>
>

Mime
View raw message