Add additional parameters to OAuth2UserRequest

[XYUU]

Summary

Add additional parameters to OAuth2UserRequest, some third-party OAuth2.0 service UserInfoService must have additional parameters in OAuth2AccessTokenResponse.

Actual Behavior

Cannot be used now because of missing parameters.

Expected Behavior

Expect to implement additional parameters by configuring userInfoUri.

Configuration

user-info-uri: https://api.weibo.com/2/users/show.json?uid={uid}

[jgrandja]

@XYUU This is not clear to me:

some third-party OAuth2.0 service UserInfoService must have additional parameters in OAuth2AccessTokenResponse

How is the UserInfoService related to a OAuth2AccessTokenResponse? Please provide more detail.

[XYUU]

Some third-party OAuth2.0 service UserInfoService needs to add the additional parameters in OAuth2AccessTokenResponse to OAuth2UserRequest in order to use these parameters in UserInfoService.

Such as OAuth2 AccessToken Response:

{
    "access_token": "1.a6b7dbd428f731035f771b8d15063f61.86400.1292922000-2346678-124328",
    "expires_in": 86400,
    "refresh_token": "2.385d55f8615fdfd9edb7c4b5ebdc3e39.604800.1293440400-2346678-124328",
    "scope": "basic email",
    "uid": "90090909",
}

user-info-uri: https://api.weibo.com/2/users/show.json?uid={uid}

UserInfoService expects to expand：

https://api.weibo.com/2/users/show.json?uid=90090909&access_token=1.a6b7dbd428f731035f771b8d15063f61.86400.1292922000-2346678-124328

[jgrandja]

I understand. Let me see what I can do and I'll get back to you shortly.

[mhyeon-lee]

related: #5500
RFC-6750 2.3. URI Query Parameter (https://tools.ietf.org/html/rfc6750#section-2.3)

However, the Nimbus SDK does not support URI Query Parameter requests.
(SDK support Authorization Request Header Field, Form-Encoded Body Parameter)
I contacted Connect2id Support, which supports the Nimbus SDK, and I received the following response.

---

Hi,

First, thanks for this report.

Support including the access token as URI query parameter was deliberately omitted from the SDK because that pattern is discouraged, to prevent the token from accidentally getting recorded in server and proxy logs, etc.

https://tools.ietf.org/html/rfc6750#section-2.3
Because of the security weaknesses associated with the URI method
(see Section 5), including the high likelihood that the URL
containing the access token will be logged, it SHOULD NOT be used
unless it is impossible to transport the access token in the
"Authorization" request header field or the HTTP request entity-body.
Resource servers MAY support this method.

This method is included to document current use; its use is not
recommended, due to its security deficiencies (see Section 5) and
also because it uses a reserved query parameter name, which is
counter to URI namespace best practices, per "Architecture of the
World Wide Web, Volume One" [W3C.REC-webarch-20041215].
Are you aware of this recommendation, or do you need to cover a service that for some reason cannot handle the header and POST methods?
Cheers,

Yavor

Your Connect2id Support Team

[jgrandja]

@XYUU This issue has been resolved. You will now have access to OAuth2AccessTokenResponse.additionalParameters in OAuth2UserRequest.additionalParameters.

Also, take a look at #5641 which will provide you the capability to customize the UserInfo request by overriding DefaultOAuth2UserService.buildRequest(). Alternatively, instead of extending/overriding, you can provide a RestOperations via DefaultOAuth2UserService.setRestOperations() and modify the outgoing request however you like using a ClientHttpRequestInterceptor.

This should give you the flexibility you need.