Spring Social
  1. Spring Social
  2. SOCIAL-135

Upgrade OAuth permissions on an as-needed basis

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 2.0.0 Backlog
    • Component/s: Connection Web
    • Labels:
      None

      Description

      As the developer of an application that integrates with an OAuth 2 service provider, I'd like to be able to request additional permissions for that provider after the initial connection has been made so that I won't need to request all needed permissions up front.

      Currently, the only time to request the scope of an access token is at connection-time, when the user authorizes the application. This requires the application to know up-front what permissions it will need and request all of them at that time. It'd be better to request permissions as-needed. Two scenarios illustrate the benefits of this:

      Suppose that a certain feature of an application needs "read_friendslist" permission from Facebook. But this feature may or may not be used by all users. If asking for this permission up-front, the user may be unclear as to why they should agree to that permission. But if the request for that permission is delayed until it is needed, the user may have additional context that makes it clear why they should agree.

      For the other scenario, suppose that an application has been in production use for awhile with several users already connected with Facebook. Then, a new feature that requires "publish_checkins" permissions is added. None of the existing users will have granted that permission, because it wasn't even known that it would be needed at the time they authorized. But if as-needed permissions are supported, then the user will be prompted to grant that permission at the time they attempt to use the new feature.

        Activity

        Hide
        Craig Walls added a comment -

        See SOCIALFB-87 for a possible solution to this (and a few other problems).

        Show
        Craig Walls added a comment - See SOCIALFB-87 for a possible solution to this (and a few other problems).
        Hide
        Craig Walls added a comment -

        Reintroducing into 1.1.0.M4 release to explore a possible annotation-based solution for upping necessary scope and to also test ReconnectFilter to see if it will handle scope upgrades as-is.

        Show
        Craig Walls added a comment - Reintroducing into 1.1.0.M4 release to explore a possible annotation-based solution for upping necessary scope and to also test ReconnectFilter to see if it will handle scope upgrades as-is.
        Hide
        marc schipperheyn added a comment -

        This is a great feature. I know that the LinkedIn API doesn't support it and I'm also wondering how to deal with the oauth provider caching their connections.

        Show
        marc schipperheyn added a comment - This is a great feature. I know that the LinkedIn API doesn't support it and I'm also wondering how to deal with the oauth provider caching their connections.
        Hide
        Oscar Guindzberg added a comment - - edited

        I need this so I would like to implement this improvement now. Has work on this issue already started? Is there any info I should know about?

        Show
        Oscar Guindzberg added a comment - - edited I need this so I would like to implement this improvement now. Has work on this issue already started? Is there any info I should know about?
        Hide
        marc schipperheyn added a comment -

        IMHO I'm not sure how this can work with all providers. E.g. LinkedIn doesn't have a way to force reauthorization, like Google does. So how do you avoid cached responses based on the wrong permission set in a consistent way? Looking at LinkedIn, even if you connect and then disconnect from the provider, you will get a cached ok response if you connect within their session timeout span.

        Show
        marc schipperheyn added a comment - IMHO I'm not sure how this can work with all providers. E.g. LinkedIn doesn't have a way to force reauthorization, like Google does. So how do you avoid cached responses based on the wrong permission set in a consistent way? Looking at LinkedIn, even if you connect and then disconnect from the provider, you will get a cached ok response if you connect within their session timeout span.

          People

          • Assignee:
            Unassigned
            Reporter:
            Craig Walls
          • Votes:
            5 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

            • Created:
              Updated: