This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.
Although I can't honestly say I've tried it with LinkedIn, you should be able to obtain the connection (via a ConnectionRepository) and call refresh() on it. In fact, this should work with any OAuth2-secured API (except for Facebook who doesn't quite play by the OAuth2 spec).
I've not tried it with LinkedIn yet, because up until recently Spring Social was working with LinkedIn via their OAuth 1.0a authentication. But it sounds like a good thing to test.
Therefore, Spring Social supports refresh of access tokens. But it is a manual effort on your part to (1) catch the ExpiredAuthorizationException, (2) use ConnectionRepository to fetch the Connection, and (3) call refresh() to update the connection.
What would be more awesome is if Spring Social were to somehow catch that ExpiredAuthorizationException for you, automatically call refresh() and then reattempt the call that triggered the exception; making it seamless for the caller. That is something I've been pondering, but there's no implementation yet.
One possible solution is an aspect. But it'd need to be configured by the developer to properly wrap whatever API binding types (LinkedInTemplate, for example) the application is using. Another option I'm thinking over is to dig down into AbstractOAuth2ApiBinding and configure the RestTemplate that it exposes to handle that exception. It's a bit iffy on whether it can work, but if it does work, then any API binding that extends AbstractOAuth2ApiBinding would automatically get refresh capability...except, again, for Facebook who doesn't play by OAuth2 rules.
According to http://developer.linkedin.com/blog/t...g-access-token , it requires user to be logged into LinkedIn in order to refresh. If a user comes back to my site after 60 days, since LinkedIn OAuth2 access token cannot be refreshed without user intervention, I would have to ask the user to re-grant permission. It definitely makes a site a lot less user-friendly.
Since OAuth1 doesn't require token refresh and LinkedIn still supports OAuth1, is it possible to extend Spring Social LinkedIn to support both OAuth1 and 2? If that is possible, I think it will make a lot of developers and users happy.
I believe you're right. I hadn't read up on LinkedIn's approach to refreshing OAuth 2 tokens until recently and it turns out that (if I fully understand what I read) they do refresh much like Facebook (and not like the OAuth 2 spec defines with refresh tokens). That makes things a bit tricky.
Without a refresh token, the refresh() won't work. Therefore, you'll have to go through the redirect dance to get a new access token. If LinkedIn implements this like Facebook (and as they should), then the authorization should still be valid (even if the token has expired) and so the user will not be bothered with an authorization dialog. You'll redirect to LinkedIn and LinkedIn will redirect right back to you without involving the user.
One way of dealing with this is to create a filter that catches any exception where a token is not valid or has expired and from there to kick off the "dance". That's precisely what ReconnectFilter in the latest 1.1.0 snapshots of Spring Social is supposed to do. (Although I've not tried it with LinkedIn.) I'd be happy to have a few more eyes on ReconnectFilter to test it out and let me know how it works for Facebook, LinkedIn, etc. (It should even work for Twitter in the case where a user has revoked authorization.)
Again, this is based on what I read. I've not actually tried any of this. But now that I'm aware of it, I've put a task on my TODO list to explore it with LinkedIn and from there make a plan for handling this in Spring Social. With any luck, the automatic token renewal stuff that I've got in the latest 1.1.0 snapshots of Spring Social should work for LinkedIn.
This is my problem: first image rapresented how I will should do, in the circle red there is (in italian) duration of access to linkedin from app (sproutsocial.com).
In second image is my app's access to linkedin, but why intro access is different from the first? Attachment Attachment
Unless I am misunderstanding you, these two shots came from different apps, right? The first is from SproutSocial and the second is from a different app...right?
My guess is this: The first screenshot appears to be an OAuth 1.0a authorization page and the second appears to be an OAuth 2 authorization page. LinkedIn currently supports both, but Spring Social Linkedin now only supports OAuth 2.
But again, this is just a guess based on what I see.
Ok, I'll explain: my app (second image) menages social account (facebook,twitter,linkedin,g+...), but I've trouble with linkedin's access token because it expires after 60 days. In SproutSocial screenshoot I've seen a particular select (circled in red in first image) for select duration of linking with app and linkedin. I would reproduce this feature in my app. Is it possible with spring social api or I must use reconnectfilter with human interaction?
I understand OAuth 2 is a newer version and a lot of effort has been spent on moving Spring Social LinkedIn from OAuth 1.0a to 2.0.
If we take a look at the last section of LinkedIn documentation on Authentication http://developer.linkedin.com/docume...tion#migration, the first line reads "If you're already happy with your current OAuth 1.0a solution, a migration to OAuth 2.0 isn't necessary" It does seem to me that LinkedIn is not exactly encouraging migration from 1.0a to 2.0, even though it does offer the possibility.
I also read a bit on OAuth 2 on Wikipedia, following are quotes from http://en.wikipedia.org/wiki/OAuth "In comparing OAuth 2.0 with 1.0, Hammer points out that it has become 'more complex, less interoperable, less useful, more incomplete, and most importantly, less secure.'" "OAuth 2.0 has had numerous security flaws exposed in implementations. The protocol itself has been described as inherently insecure by security experts and a primary contributor to the specification stated that implementation mistakes are almost inevitable."
From user experience perspective, with LinkedIn's current implementation of OAuth 2, if a user comes back to my website after 60 days, I would have to ask him/her to re-authorize my application. And I need to do that every single time he/she doesn't come back before token expiration. If I grant permission to a website to access my LinkedIn account and half a year later, it asks me to do it again, while other websites that access my LinkedIn account don't do that, as a user I would be suspicious about engineering of the website. For a new website that is trying to grow, it simply can't afford to lose user's confidence like that..
Spring Social LinkedIn has made integration with LinkedIn API tremendously easy for my project. I am well aware that a lot of effort has gone into moving this module to OAuth 2. If it is not possible to go back to 1.0a, maybe I suggest that at least we make it 1.0a compatible?
First, if there are issues with Spring Social LinkedIn and OAuth 2, I'd rather work through those than to revert back to OAuth 1.0a. Please feel free to open improvement or bug issues at https://jira.springsource.org/browse/SOCIALLI and I'll do what I can to address them.
I don't disagree with your selection of quotes regarding OAuth 2...I've read them all, too...but I do disagree with the conclusion. Stepping back from Wikipedia and going straight to Eran's blog, you'll see that he followed up a few days later with the following: "As I said before, in the right hands, after applying the right security and making some decisions, OAuth 2.0 can be great. Facebook made those decision (one of which was to ignore the last 20-something drafts) and so did Google." Looking at LinkedIn's implementation of OAuth 2, I find that it greatly resembles that of Facebook. I can't speak for Eran, but I'd suspect that Eran would have no issue with it.
Eran goes on to say: "I would have been thrilled if the final result was a documentation of the Google or Facebook implementations and nothing else. That would have been a useful protocol." Again, LinkedIn's OAuth 2 implementation is very much like that of Facebook.
One more Eran quote: "If you are not sure what I am so upset about, it is the total lack of making choices. Given the new architecture and capabilities, OAuth 2.0 should have been much more restrictive and narrow." I totally agree with him on this. OAuth 2 suffered greatly from scope creep, and took way too long to produce. There are too many little side alleys and corners in the collection of OAuth 2 specifications and if you were to implement all of them, then it is more complex and potentially less secure.
Eran continues to claim that OAuth 2 is complex. I don't really understand that statement, at least not if you stick to the basics (what Facebook, Google, and LinkedIn have implemented). It's *TREMENDOUSLY* simpler than OAuth 1.0a. If Eran is referring to the labyrinth of side-specifications and some of the unnecessary features that crept in, then yes...I agree that it could be more complex. Stick to the basics and it's much much simpler than OAuth 1.0a.
Eran also claims OAuth 2 to be less secure. To some degree, I'd agree with that with regard to bearer tokens. By definition bearer tokens are simply tokens that afford the bearer the privileges granted to the token. It's like if I gave you my car keys...you'd have full power to unlock and drive my car, because my car doesn't require any additional credentials beyond the possession of the keys. For many applications (such as social APIs), that's considered secure enough. For stronger security, OAuth 2 offers MAC tokens, which are much more like OAuth 1.0a-style tokens and require additional proof that the bearer of the token is authorized to use the token. Spring Social doesn't include support for MAC tokens because I've yet to see any API that implements that part of the spec; but will support it if the need arises.
One more thought on OAuth 2 and security: The very reason that this thread started is because of a need to refresh an access token. Expiring tokens are one measure taken in OAuth 2 to make it more secure. If the token were non-expiring, then it would be less secure. The fact that LinkedIn doesn't support refresh tokens is what makes it more difficult to obtain a new access token; on the other hand, their redirect-based approach to refreshing tokens (which is also how Facebook does it) is arguably more secure.
Finally, the belief that LinkedIn doesn't seem to be encouraging OAuth 2 is confusing to me. If you click on the authorization link in their documentation it takes you to the OAuth 2 authorization documentation. And on that page it refers to OAuth 1.0a as "legacy". I wouldn't say that they're discouraging the use of OAuth 2. Also, their API is now strongly restricted to specific scopes per resource (an OAuth 2 concept). In fact, I'd say that they're encouraging you to use it and only offer OAuth 1.0a as a convenience for those not ready to move forward (hint: I'd guess that they'll retire OAuth 1.0a support within a year or so).
Again, if there are issues with regard to Spring Social LinkedIn's use of OAuth 2, then I'd rather work through those than to retro back to OAuth 1.0a. Work with me via the issue tracker to iron out any wrinkles you find.
Craig, thank you so much for the detailed explanation! Apparently, there is still a lot more about OAuth for me to learn. Spring Social LinkedIn definitely stays in my project and I would be happy to help out with issues should I come across any. Again, thanks a lot for your support and the great work!!