[
https://issues.apache.org/jira/browse/FINERACT-1033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17465508#comment-17465508
]
Petri Tuomola commented on FINERACT-1033:
-----------------------------------------
Spring Security 5.6 separates the authentication server from the resource
server. Going forward, Fineract will act as the resource server and any 3rd
party authentication server can be used to issue tokens. As Fineract will no
longer be issuing access tokens, the described issue will no longer happen.
> Fineract OAuth Token Change Bug
> -------------------------------
>
> Key: FINERACT-1033
> URL: https://issues.apache.org/jira/browse/FINERACT-1033
> Project: Apache Fineract
> Issue Type: Bug
> Components: Security
> Reporter: Saransh Sharma
> Priority: Major
>
> Fineract OAuth previously sent UUID values limited to 0-9, a-f, and dash for
> tokens. It recently changed to using a base-64 encoded value for tokens. This
> seems to work fine in many cases.
> Previous token example:
> "access_token": "a6c25cb8-7e73-446e-a49b-e9e54c3f26ee"
> Current token example:
> "access_token": "2VaGUd8Y25fCC1gBpGLZnfoC52s="
> However, if the base-64 encoded value contains a + (plus sign) authentication
> fails. Fineract generates and sends the value to the community app with the +
> in the token value. The community app returns the token value with the +
> included. Fineract looks up the value in the database but replaces the + with
> a space before doing so.
> In the example attached, Fineract provides an access token of
> 4JdlsEQzpa3gsM7CbH5mFxTy+FU=
> The community app uses the full token value with the + to request access.
> Fineract responds denying access with this message: Invalid access token:
> 4JdlsEQzpa3gsM7CbH5mFxTy FU=
>
> Please review the attached file for detailed information and logs.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
