Explicit resource authorization as part of OAuth itself?

[Adam Rosien]

The OpenFile spec currently says that the authorization endpoint is
protected by OAuth, so first the User authorizes the Client, then the
Client accesses the authorization endpoint where the User chooses
resources. What if instead--this is Ben's idea originally--the user
authorizes the Client and at the same time chooses the resources to
authorize, and the Authorized Feed was returned as a parameter when
the Client is granted an OAuth Access Token?

Current the spec says this:

1. Client accesses the Authorization Endpoint, but is denied.
2. Client requests OAuth Request Token.
3. User authorizes Client's Request Token.
4. Client requests OAuth Access Token.
5. Client accesses the Authorization Endpoint, where the User selects
the resources to grant, and the Client is returned the Authorized Feed
URL.
6. Client requests the Authorized Feed with the OAuth Access Token.

I propose a change to:

1. Client requests OAuth Request Token, but with extra parameters
detailing the type, number, and operations requested.
2. User authorizes Client's Request Token and selects the resources to grant.
3. Client requests OAuth Access Token and is returned an additional
parameter that is the URL of the Authorized Feed.
4. Client requests the Authorized Feed with the OAuth Access Token.

Notice how there is no Authorization Endpoint. The Client simply
requests a token that will later be linked to a Authorized Feed that
can only be accessed with the token. The biggest benefit of this
change is that it reduces the steps a user is required to take and is
OAuth-compatible. I see it as an solution to the warning in the OAuth
spec:

---
Appendix B.9. Scoping of Access Requests

By itself, OAuth does not provide any method for scoping the access
rights granted to a Consumer. A Consumer either has access to
Protected Resources or it doesn't. Many applications will, however,
require greater granularity of access rights. For example, Service
Providers may wish to make it possible to grant access to some
Protected Resources but not others, or to grant only limited access
(such as read-only access) to those Protected Resources.

When implementing OAuth, Service Providers should consider the types
of access Users may wish to grant Consumers, and should provide
mechanisms to do so. Service Providers should also take care to ensure
that Users understand the access they are granting, as well as any
risks that may be involved.
---

Your thoughts?

.. Adam

[Adam Rosien]

> I propose a change to:
>
> 1. Client requests OAuth Request Token, but with extra parameters
> detailing the type, number, and operations requested.
> 2. User authorizes Client's Request Token and selects the resources to grant.
> 3. Client requests OAuth Access Token and is returned an additional
> parameter that is the URL of the Authorized Feed.
> 4. Client requests the Authorized Feed with the OAuth Access Token.

Actually I think it would be better to put the extra parameters in
step #2 (user authorization) rather than in the request for a request
token.

.. Adam