SDKS-2563 - Making "refresh" and "refreshSync" methods Public

[george-bafaloukas-forgerock]

• Making "refresh" and "refreshSync" methods Public
• Updating tests

JIRA Ticket

Please, link jira ticket here.
SDKS-2563

[vahancouver]

Changes look good

[spetrov]

@george-bafaloukas-forgerock, the changes look good to me.
However, during testing, I realized that refreshing the access_token does not revoke the previous one. I thought AM would automatically invalidate it, but it only invalidates the refresh_token...
It looks to me it is up to the client to revoke the old access_token, and we currently don't do that, so I would like to discuss this with you and the team before merging and releasing this change...

Here are the relevant parts from RFC 6749:

• Section 1.5 Refresh Token

Refresh tokens are issued to the client by the authorization server and are
used to obtain a new access token when the current access token
becomes invalid or expires, or to obtain additional access tokens
with identical or narrower scope

• Section 6 Refreshing an Access Token

The authorization server MAY revoke the old
refresh token after issuing a new refresh token to the client.

[george-bafaloukas-forgerock]

I don't see a problem for this. Future planned changes can give more finer grained controlled to revoke the AccessToken. However, when you force refresh, the SDK will delete the Local "old" AccessToken and replace it with the new one. The "old" token will still be valid on the server and will expire soon. From a security perspective the AccessTokens should be short lived.