Announcement Announcement Module
No announcement yet.
Oath2Template for implicit authorization scenario Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Oath2Template for implicit authorization scenario


    I am connecting to a new service that doesn't have an existing spring social client project. This provider uses Oauth2 client side implicit authorization flow. I am creating the ServiceProvider class and need to instantiate an OAuth2Template and I don't have an accessTokenUrl and it looks like it can't be null. I looked at some existing major service providers spring social libraries but I can't seem to find this scenario. I see it mentioned in the docs for service provider online and they set the GrantType when calling oauthOperations.buildAuthorizeUrl but not sure what is the correct thing to do in the ServiceProvider class.


  • #2
    So, this provider only supports implicit grant flow? May I ask who the provider is and why you're trying to use implicit grant from Spring Social?

    First a quick fix, but then I have some questions for you:: If you're doing GrantType.IMPLICIT_GRANT, then you're right in saying that you shouldn't need an accessTokenUrl. But it seems that OAuth2Template requires one. Simple (hack) solution: Pass in an empty string or some bogus URL. If all you're doing is implicit grant, it will never be used.

    One thing that needs to be done is to lift that restriction...maybe. But the thing is that I'm not even sure that Spring Social should support implicit grant, because it's a grant type most suited for the client-side (e.g., JavaScript)...and even then I question its value. Therefore, I'm *more* inclined to remove GrantType.IMPLICIT_GRANT altogether and simply not support it.

    But I doubt I'll do that right away. Instead, let me ask you again: Why are you using implicit grant with Spring Social. Is it because that's the only option that the API offers? Or is the a much deeper reason behind your decision? I want to understand the problem better so that I know best how to address this. And, as I've already asked at the outset of this reply, which API provider are we talking about?

    Are you using Spring Social on a server-side project, as part of a Spring for Android-based project, or something else? Sorry for all of the questions, but implicit grant is something that has (to me) long seemed out of place in Spring Social and since you brought it up, I thought I'd get some input from you on why and how it's being used.


    • #3
      FWIW, I created to track this.


      • #4
        Thanks for the suggestions. The Provider is NetDocuments and their API is at

        They do provide a JS client to access their REST API which makes sense for the Implicit Grant (from the reasons I have read). The odd thing is when you sign up to get access to their API you are given a client secret and it is noted this is for OAuth2 but I don't see any calls where it is accepted in the REST API. I opened a ticket on their side asking if I was missing something. I am using Spring Social because this is part of a bigger server side project and it fits nicely into our stack. Thanks for the prompt reply.


        • #5
          Another issue I have run into in this scenario is using the connect controller to perform the dance but ask for the token instead of a code as request parameter. I may be mis reading the code but it seems when I step through the code the Controller calls buildOAuthURL which then calls buildOAuth2Url in ConnectSupport which passes GrantType.AUTHORIZATION_CODE to oauthoperations which comes from my self created connectionFactory/serviceProvider and results in the stock OAuth2Template. I am having trouble finding an elegant way to do this. Any recommendations? Right now , I have created my own OAuth2Template that implements OAuth2Operations which works

          I am not seeing support in the controller for implicit authorization where the token is handed back immediately. Any recommendations here?


          • #6
            Yeah, you're right...the controller doesn't really support implicit grant. That's largely for all of the same reasons why I am wondering if Spring Social should support it at all.

            History: The only reason Spring Social supports implicit grant at all is because at one time we misunderstood the purpose of implicit grant and thought it to be the best choice when building a native application using Spring for Android. Hindsight, as they say, is 20/20 and we now know better. In the case of a native Android app, either authorization code or password grant are better (the choice depends on whether you want to redirect to a web page and back in a native app vs. asking the user for their credentials so that you can exchange the for an access token).

            But as I said, implicit grant seems to have a very narrow set of use cases (and I even question the validity of those use cases). And none of those use cases are fitting for a server-oriented web application. Therefore ConnectController doesn't support it. (And I'm unlikely to change that.)

            One possible choice is to subclass ConnectController to make it do your bidding. Not ideal, but it can be done. A better choice is for NetDocuments to support authorization code grant (which is the *RIGHT* thing to do).

            Another thing to try is to see if they already offer authorization code grant. They may not document it, but you could try setting the response_type parameter to "code" instead of "token" and see if they will return an authorization code in the redirect. If they do, then that's a clue that maybe they do have authorization code support buried in there somewhere. Then, the next trick is to figure out what the access token URL is. Their authorization URL doesn't follow any common pattern, so this part might be tricky.


            • #7
              Is the issue with the OAuth2 implicit grant flow for a server app - how secure it is?I might not be able to do anything about it with this provider but trying to understand at a higher level the pros/cons with t.


              • #8
                That's largely the concern, yes. The key difference security-wise is that in authorization code grant, the client must be authenticated in the exchange for the access token. But in implicit grant there is no exchange for an access token (because the client receives the token in the callback) and thus no authentication of the client is performed.

                The other troublesome thing with implicit grant is that the token is short-lived with no chance for refresh other than to go through the authorization flow again. With authorization code grant, providers may issue a refresh token that can be exchanged for a new access token without going through the authorization flow again. (Note: Facebook and LinkedIn are examples of providers that do not support refresh tokens even for authorization code grant.)

                Again, each of the grant types in OAuth 2 exists to meet a certain use-case. For server-side apps, authorization code grant *is* the most secure and most appropriate choice. Implicit grant is more suitable for applications or widgets that are entirely client-side (e.g., Javascript). Password grant (aka, resource owner credentials grant) is most appropriate for native applications where a redirect would be awkward or even impossible. Client credentials grant is appropriate for obtaining a token where the resources to be accessed aren't user-centric and thus no user authorization or credentials are necessary.

                There's also the special case where an application has a mix of client and server-side code that needs access to an API. In that case you could either use implicit grant and have the client share the token with the serverside or use authorization code grant and have the server share its token the the client side. In that scenario, I'd favor authorization code grant.

                In the case of NetDocuments, they seem to be misusing implicit grant to cover all scenarios. While it is technically possible to use implicit grant for server-side apps, it's not what implicit grant was meant for nor is it the most secure choice.

                And you never know...they may be open to recommendations. I'm sure that they might not like to hear that they are misusing implicit grant, but they might be open to supporting authorization code grant if you were to explain the benefits and purpose for it to them. I'd say it's worth a shot to politely ask them (e.g., annoy the crap out of them) why they chose not to support authorization code grant.


                • #9
                  I have gone down the route of subclassing Connect Controller but I am not sure this will work. What I attempted to do was create my own controller that extended connect controller and supply my own method that would be the callback for the token but key components(connectionRepository and connectionFactoryLocator) in the controller are private and I can't access them.

                  When I went the route of creating my own OAuth2Template I was able to override the outbound request to the service provider to request a token instead of a code but its at the point where the callback request from the service provider to the app doesn't do anything.

                  I wanted to try to re use as much as I could from the project so I wanted to get your opinion on this. I have another idea but I would have to move further away from reusing the existing web component.


                  • #10
                    Incase anyone else browses this thread - I was able to accomplish this for my situation although I had to modify spring-social-web to handle this which is not ideal. It turns out NetDocuments does support the authorization flow but it requires a separate refresh token which looks like it may not be fully supported yet in Spring Social(


                    • #11
                      To be clear, Spring Social does support refresh tokens in the sense that it captures them, keeps them in the connection table, and you can use the connection's refresh() method (or at a lower-level, OAuth2Template's refreshAccess() ) to exchange the refresh token for a new access token. This has been part of Spring Social since pre-1.0.

                      What isn't supported (yet) and is the subject of SOCIAL-263 is automatic refresh of tokens once they expire. That is, once a refresh token expires it's up to you to handle the expiration and trigger the exchange (using either of the options described in the first paragraph above). Spring Social currently has no mechanism to automatically detect the expiration of a token and exchange a refresh token for a new access token.

                      (Although Spring Social 1.1.0 builds now have a ReconnectFilter that handles expired tokens at the web level and refreshes them by redirecting back through the authorization flow. This should probably work with any provider, OAuth 1 or OAuth 2, but it works perfectly for providers like Facebook and LinkedIn that don't support refresh tokens.)