Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
When parsing OAuth2 access token response a nested JSON object causes the response parsing to fail #6463
When parsing OAuth2 access token response a nested JSON object causes the response parsing to fail.
When attempting to use Spring Security OAuth to allow logins against a provider that responds with objects in their access token reponse an error message is shown:
According to the OAuth spec https://tools.ietf.org/html/rfc6749#section-5.1 clients must ignore values they don't understand. The value should either end up in the
Jackson is being used to parse the JSON response (seems to be default in my spring-boot application).
Spring Security 5.1.3, issue also looks to be present on master.
You can see a test case that currently fails in: https://github.com/spring-projects/spring-security/compare/master...buckett:oauth-response?expand=1
To workaround this I copied
Then I just connect this converter up to the
This isn't the actual code I'm using as I've removed other changes that aren't needed so it may not work as expected.
@buckett The solution you implemented with providing your own
It's not clear to me if you're still having a problem or are you expecting a different way of implementing your setup?
As per spec:
Based on my understanding how the spec reads, each parameter must be at the highest (root) structure level and are either strings or numbers. However, your example token response has a JSON object value at the root level with the parameter names/values at the next level below the object. So therefore the value of the root level parameter is an object and not a string or number as the spec dictates.
Does this make sense?
When I read the spec I was reading that paragraph as applying to the previously specified parameters (access_token, token_type, expires_in, refresh_token, scope).
It also goes on to say that the "the client MUST ignore unrecognized values names in the response", which again suggests we should be a little more forgiving in how we deal with unexpected value names.
If nothing else it would have been helpful if this was easier to code around as this took me a little while to debug (I came across this upgrading from Spring 5 to Spring 5.1, Spring 5 was forgiving of extra values I think).
As per spec:
I see your point based on the reference in bold.
Our goal is to make it easy for the user so this is valuable feedback for us. Do you have a suggestion on improving? Are you possibly interested in submitting a PR for this improvement?