LinkedIn OAuth2 Authorization server encountered an unexpected condition

8
votes

We're getting this weird error for some of our users who are trying to authenticate via linked in OAuth2 API from mobile within a webview.

https://www.linkedin.com/uas/oauth2/authorization?response_type=code&client_id=XXX&state=XXX&redirect_uri=XXX&scope=r_emailaddress%20r_basicprofile

After the submit ( https://www.linkedin.com/uas/oauth2/authorizedialog/submit ), there is a redirect to our redirect uri with the following params.

?error=server_error&error_description=XXX&state=the+authorization+server+encountered+an+unexpected+condition

I went through this => http://chriskief.com/2014/04/23/linkedin-api-unable-to-retrieve-access-token/ .

Creating a new application or generating fresh keys is a problem as it would break the linked in login for already installed apps. We have never use OAuth1 before.

2
androidloginlinkedinoauth2
I'm getting this too -- notably for mobile users. Did you get any further insights? - Amichai Schreiber
I'm getting this too, especially for mobile users. We managed to reproduce the bug once: it bugged with one account only and only on mobile (Android Chrome, iPhone Safari, and iPhone Chrome) but it worked on Desktop (OSX Safari and OSX Chrome). With other accounts on the same devices everything worked fine. After 15 min of testing it worked again... - Antoine Dusséaux
did u manage to fix it ? - jony89

2 Answers

2
votes

We were able to reproduce this error when a space character is added before or after the user's email address on the LinkedIn authorization form. LinkedIn doesn't do any trimming of extraneous whitespace on this field.

My hypothesis is that this happens on mobile when people use the space bar as a way to accept an autocompletion recommendation on the email address. So the user starts typing their email address, the OS recommends a known email address and, generally, mobile OSs will use the recommendation when the space bar is pressed.

0
votes

I had this exact problem. In my case, the problem was that I was overriding the default authorization scope (using ?scope=..). I'm not sure why this caused the problem, or why it always happened to mobile users. But removing the override made it go away.