Announcement Announcement Module
No announcement yet.
Setting authorization scope: Using backend instead of HTML/JSP? Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Setting authorization scope: Using backend instead of HTML/JSP?

    How can I have the "backend developer" gain control over the OAuth authorization scope for some social provider?
    For example, in the "Spring Social Showcase" sample webapp, it is inside JSPs (e.g. views/connect/facebookConnect.jsp and views/signin/signin.jsp) how the web application controls the requested authorization scope. Here is some sample code how setting the authoritzation scope is done currently in an HTML file:

    <form action="<c:url value="/connect/facebook" />" method="POST">
    <input type="hidden" name="scope" value="publish_stream,user_photos,offline_access" />
    <button type="submit">Connect</button>
    I find the approach of having HTML specify the requested authorization scope problematic for the following reasons:
    • It makes it easier for a web application user to "tinker" with the authoritzation scope. This makes it easier for the user to request or decline permissions on behalf of the web application that the web application didn't want so.
    • It moves a business domain-related concept (authorization scope) to a user interaction domain-related environment (HTML/JSP)
    • As a backend developer, I now have to consider JSP/HTML concepts such as "hidden field" and "form".

    ConnectController and ProviderSignInController take care of handling the HTTP POST and form-contained "scope" with methods annotated with
    @RequestMapping(value="/{providerId}", method=RequestMethod.POST)
    Internally, they delegate to a ConnectSupport object and have it extract the scope parameter from the request.

    In case Spring Social currently doesn't have means of specifying the scope other than with a user-initiated POST-with-scope-parameter-in-an-HTML-form, what about enhancing ConnectController and ProviderSignInController?

  • #2
    I understand your concerns here, but they'd be equally debated if the scope were entirely specified on the server. I'm not sure either approach is the "right" approach, nor is either the "wrong" approach. The client-side specification is the one we went with and is what exists today.

    But specifying the scope at the ConnectController and ProviderSignInController is definitely not the right place on the server-side to specify it. Scope values are a provider-specific concern, while those controllers are deliberately provider-agnostic. If you were to set the scope on one of those controllers to one of Facebook's several dozen possible values, then those would also be sent to any other OAuth2-based provider the application may interact with.

    Therefore, while I agree that there may be value in specifying the scope on the server side, it should probably be done at the ConnectionFactory level (or more appropriately at the OAuth2ConnectionFactory level since scope only applies to OAuth2).

    Even so, such a configuration should be handled as a default value that can be overridden by the client-side. The client may choose different scopes (based on user behavior or choices). As it is, they're hardcoded in the sample apps, but that doesn't mean that they must be hardcoded. A statically configured choice (at the connection factory level) should be able to be overridden by the application as it sees fit, to ask for different scope...and then again go through the connection process later to expand the scope if new authorization is needed.