Announcement Announcement Module
Collapse
No announcement yet.
OAuth, security policies & permissions Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • OAuth, security policies & permissions

    Hello,

    I am studying the OAuth implementation and I am curious about the support for fine-grained permissions. I have a first use case, and wonder if/how it is supported by Spring Social.

    The OAuth Service Provider is an application that allows people to manage photo albums. They can create albums, upload photos & metadata, organize their photos, etc. (think of it as a Flickr-like app).

    What I would like, is to define a security policy for the OAuth Service Provider that would allow me: i) to have a read and a write permissions (allowing the consumer to retrieve photos, resp. to upload/delete photos after getting user approval) and ii) to have different permissions for every photo album (there could be a "public" album that oauth consumers can access, and a "private" one that oauth consumers cannot access.

    I understand that when the user is redirected to the Service Provider site at te beginning of the authorization process, it is the responsibility of the Service Provider to present a UI to ask the user what permissions he wants to grant.

    I then imagine that the Service Provider has to request a token, and that the specific permissions have to indicated. What happens then? Is it up to the Service Provider to keep track of all the granted tokens and how they map to the tokens? Is that something that is supported by Spring Social?

  • #2
    Tokens

    From what I understand, looking at the greenhouse example application, the AppConnection table contains the access tokens for the user.

    When the user grants access to an OAuth consumer, then an entry is created in this table. Based on my observations, this record stays in the table until there is an explicit "disconnect" by the user. In other words, there does not seem to be an expiration mechanism for request tokens.

    I imagine that the model could be extended, and that I would be able to associate permissions and possibly a scope to these AppConnection elements. I am not sure that this would be the best approach, so it would be great to have your opinion on this.

    Imagine that I do that, then I am still not quite sure about how to fetch the permissions when a service is invoked. I have seen how to retrieve the Account (in other words the information about the user, on behalf of which the OAuth consumer is making the call). What I would like to do, is to retrieve information associated with the request token. Not sure if this should be captured by the OAuth filtering process (spring security level), or if I should do a lookup on the request token (AppConnection) from my service. I would think that the first method is better, but I still don't have a very clear picture.

    Comment


    • #3
      Hi,

      Yes, a Connection represents a link to between a local user account and an account the user has with a ServiceProvider. The Connection consists of an access token, and yes, in Greenhouse an Connection remains established until the user chooses to disconnect. A third-party ServiceProvider we are connecting to may choose to invalidate the access token at any time, however, as we don't control that.

      OAuth2 introduces the concept of "scope", where a OAuth connection can have specific authorization scope e.g. READ_ONLY vs. READ_WRITE. Facebook is an example of a ServiceProvider that uses this concept heavily, as you can use a variety of scopes when connecting to their API. The "scope" concept is definitely a property of the Connection, which has an association with a local Account. In Greenhouse, we're not doing anything with such a concept as we don't have a requirement for different access levels for our API. If we did, yes, I could imagine being able to lookup a scope property of the Connection object to determine what the user has allowed access to.

      Keith

      Comment

      Working...
      X