Openbanking Brazil: shall not allow `refresh tokens` rotation feature.

[casfe03]

Description

Hi team, good night, how are you? There was a new update of the Openbanking Brazil SPEC and in this new spec item 17 was included: 17. shall not allow refresh tokens rotation feature. (https://github.com/OpenBanking-Brasil/specs-seguranca/blame/504e498c670001e98dd694c275b4855f2bc86387/open-banking-brasil-financial-api-1_ID3.md#L233)

The entire discussion on the subject can be found on the Forum: https://bitbucket.org/openid/fapi/issues/456/

Attached is also the log of the new OpenID compliance test, the specific test is the fapi1-advanced-final-refresh-token 1KkvpgqdHWbyski 4.1.43 that failed

Basically what is expected is that with the disablement of the refresh_token rotation feature is that when a new access_token is requested for every unique consent or grant the same refresh_token is sent in the body

Basically for every unique consent or grant as it’s is known, there should be a unique refresh token issued. Every time that refresh token is used a new access token for that grant should be issued and the refresh token kept the same.

Different grants would have different refresh tokens.

Discussion

No response

Motivation

Support the new FAPI-BRazil compliance tests

Details

Basically for every unique consent or grant as it’s is known, there should be a unique refresh token issued. Every time that refresh token is used a new access token for that grant should be issued and the refresh token kept the same.

Different grants would have different refresh tokens.

[tnorimat]

Hello @casfe03,
I have recognized that the recent Open Banking Brazil FAPI 1.0 Security Profile ID3 added one requirement that you've pointed out, and keycloak has not yet satisfied this requirement.

IMO, there are two ways to satisfy the added requirement:

1. adding a new client setting to control whether a refresh token is issued or not.
2. using client policies that strip the refreshed new refresh token from the token refresh response.

If we take the option 2, we need to enhance the current client policies. I have sent the PR for it. In this PR, I simulated the option 2 and make sure that it works well by running the arquillian integration test.

@mposolda could you please tell me your opinion about which way is appropriate or other good way exists?

[casfe03]

Thank you @tnorimat

[evertongodoi]

@tnorimat , Do you have more information about this issue ? Because it's very important to FAPI-BRazil compliance tests.
We appreciate your attention.

[tnorimat]

Hello @evertongodoi ,
I've already sent the PR that can suppress refresh token rotation.

[evertongodoi]

Hello @tnorimat , thanks to returned, we'll waiting this implementation the PR that you informed.

[tnorimat]

@evertongodoi @casfe03 I think this issue can be resolved by keycloak/keycloak#12551.
SuppressRefreshTokenRotationExecutor can be used.

[casfe03]

Thank you @tnorimat :)

[evertongodoi]

Thanks @tnorimat !

[evertongodoi]

@tnorimat in the keycloak interface, where I can to enable the SuppressRefreshTokenRotationExecutor ?

[tnorimat]

@evertongodoi
It can be used to add a profile of client policies:

            {
                "name": "ob-br-fapi-1-advanced-id3",
                "description": "Additional client profile, which enforce clients to conform Open Banking Brasil FAPI 1.0 ID3",
                "executors": [
                    {
                        "executor" : "suppress-refresh-token-rotation",
                        "configuration" : {}
                    }
                ]
            }

and applies it to a client by a policy of client policies like:

        {
            "name" : "ob-br-fapi1-advanced",
            "description" : "The policy for Open Banking Brasil FAPI security profile",
            "enabled" : true,
            "conditions" : [ {
                "condition" : "client-roles",
                "configuration" : {
                    "roles" : [ "ob-br-fapi1-advanced-client-role" ]
                }
            } ],
            "profiles" : [ "fapi-1-advanced", "ob-br-fapi-1-advanced", "ob-br-fapi-1-advanced-id3" ]
        },

Please note that Keycloak 20 or later will include the PR.

[evertongodoi]

@tnorimat thanks to your response!

But when I add a profile of client policies, the Keycloak return the error bellow.

[org.keycloak.services.clientpolicy.ClientPoliciesUtil] (executor-thread-727) no executor provider found. providerId = suppress-refresh-token-rotation

[org.keycloak.services.clientpolicy.DefaultClientPolicyManager] (executor-thread-727) VALIDATE SERIALIZE PROFILES FAILED :: error = proposed client profile contains the executor, which does not have valid provider, or has invalid configuration., error detail = NA

[tnorimat]

@evertongodoi could you build the latest keycloak main branch and use it? The PR was included in the branch after the commit whose id is 148c7695ff5b32f46f05a5f341ca5456da144987.

[cmswopenfinance]

Hi,
We are currently using Keycloak v20.0.1 along with the client 'ob-br-fapi-1-advanced-id3', which incorporates the 'suppress-refresh-token-rotation' executor. The purpose of this executor is to suppress the rotation of the refresh token. However, we are facing issues during production testing of Open Finance Brazil, specifically in the refresh token verification step. The test involves performing a token exchange to obtain both the access token and the refresh token from the token endpoint. Subsequently, a new request is made at the same token endpoint (using grant_type: refresh_token). However, we have observed that Keycloak is returning a different refresh token than the one received during the token exchange step. This raises the questions:

• Was the current implementation designed to operate this way due to the refresh token being formatted as a JWT?
• Would it be possible to correct this behavior so that the returned refresh token value is the same as the one obtained during the token exchange?

Refresh token response samples:

• Refresh Token Value - First time
  { "alg": "HS256", "typ": "JWT", "kid": "04dcdd70-63b9-4a4d-becb-bcdccf564623" }. { "exp": 1692035094, "iat": 1692033294, "jti": "4b55ea01-7796-42aa-9a9d-b7d759043213", "iss": "https://ofb-auth.conformance.com/auth/realms/test", "aud": "https://ofb-auth.conformance.com/auth/realms/test", "sub": "c2669692-5e5c-46a8-b5d0-b37b8fbd438e", "typ": "Refresh", "azp": "de302d3f-525c-446a-bfc8-740a081f9c02", "nonce": "WnVfVhZLru", "session_state": "8b389e6c-d32e-4c17-a7a3-dc467ea64c88", "scope": "payments consent:urn:ofb:payment:b9d53881-2f5e-4da5-8037-f0b9871c3859 openid", "sid": "8b389e6c-d32e-4c17-a7a3-dc467ea64c88" }

• Refresh Token Value - Second time
  { "alg": "HS256", "typ": "JWT", "kid": "04dcdd70-63b9-4a4d-becb-bcdccf564623" }. { "exp": 1692035097, "iat": 1692033297, "jti": "e2aa3ccf-3946-44b5-92bf-b5c0e177fc7c", "iss": "https://ofb-auth.conformance.com/auth/realms/test", "aud": "https://ofb-auth.conformance.com/auth/realms/test", "sub": "c2669692-5e5c-46a8-b5d0-b37b8fbd438e", "typ": "Refresh", "azp": "de302d3f-525c-446a-bfc8-740a081f9c02", "nonce": "WnVfVhZLru", "session_state": "8b389e6c-d32e-4c17-a7a3-dc467ea64c88", "scope": "payments consent:urn:ofb:payment:b9d53881-2f5e-4da5-8037-f0b9871c3859 openid", "sid": "8b389e6c-d32e-4c17-a7a3-dc467ea64c88" }

Thank you for your assistance and insights regarding this matter.

Best regards,
Felipe Assumpção

[tnorimat]

@cmswopenfinance Hello.
May be the same issue of #422 .
Does Open Finance Brazil use RFC 8693 OAuth 2.0 Token Exchange for getting tokens?