The ability to disable the authState.performActionWithFreshTokens() call during the authenticate flow. For cases where the providers invalidate refreshTokens with each tokenRequest regardless of the refreshToken being used.
When working with a provider that rolls new refreshTokens anytime the token endpoints are hit, regardless of using a refreshToken, the Android implementation never gets the 2nd refreshToken created. IOS doesn't appear to have this issue and does not attempt a second token request for 'fresh' tokens during authentication.
The Android implementation of the authenticate method attempts two separate token requests. One started via the this.authService.performTokenRequest() and then again via authState.performActionWithFreshTokens() if an exception is not created during the first.
This results in a response that has the initial accessToken and refreshToken in the request's response in a access_token_response along with the 2nd token request's response added as a separate access_token. Example:
At this point, our first refreshToken is invalidated by the provider we're using and we don't have the 2nd refreshToken created during that 2nd request.
Code block in question: GenericOAuth2Plugin.java, line 438
As it's openid's AuthStateperformActionWithFreshTokens()'s callback that's preparing the new accessToken for the ResourceUrlAsyncTask (and the eventual adding of the response and token with OAuth2Utils.assignResponses()), an option to disable the call for authState.performActionWithFreshTokens() via config value (ex: freshTokenAttemptEnabledboolean added to OAuth2Options.java or something) could be the easiest approach. Where the default would be to do the 2nd token call where a false flag would simply not attempt it.
Alternatives for the prevention of the 2nd tokenRequest attempt are limited outside of the mentioned block. Another alternative would be to have openid include the refreshToken in the AuthState's AuthorizationService.TokenResponseCallback() (Followed by including it with the ResourceUrlAsyncTask for the assigning). And then update OAuth2Utils.assignResponses() to also include it:
public static void assignResponses(JSObject resp, String accessToken, String refreshToken, AuthorizationResponse authorizationResponse, TokenResponse accessTokenResponse) {
// #154
if (authorizationResponse != null) {
resp.put("authorization_response", authorizationResponse.jsonSerialize());
}
if (accessTokenResponse != null) {
resp.put("access_token_response", accessTokenResponse.jsonSerialize());
}
if (accessToken != null) {
resp.put("access_token", accessToken);
}
if (refreshToken != null) {
resp.put("refreshToken ", refreshToken);
}
This way, the consumer can decide to make use of either result. The ones inside of the original access_token_response or the appended tokens.
This does not seem viable.
Additional Context
This doesn't appear to be an issue with IOS. ByteowlsCapacitorOauth2.swift and the authenticate flow does not appear to have a case for attempting a request with 'fresh' tokens after the initial accessTokenJsObject or accessTokenResponse is created.
Flow type: Authentication Platform: Android Provider: Duende generic-oauth2 version: 5.0.0
Describe the Feature
The ability to disable the
authState.performActionWithFreshTokens()
call during the authenticate flow. For cases where the providers invalidate refreshTokens with each tokenRequest regardless of the refreshToken being used.When working with a provider that rolls new
refreshTokens
anytime the token endpoints are hit, regardless of using arefreshToken
, the Android implementation never gets the 2ndrefreshToken
created. IOS doesn't appear to have this issue and does not attempt a second token request for 'fresh' tokens during authentication.The Android implementation of the
authenticate
method attempts two separate token requests. One started via thethis.authService.performTokenRequest()
and then again viaauthState.performActionWithFreshTokens()
if anexception
is not created during the first.This results in a response that has the initial
accessToken
andrefreshToken
in the request's response in aaccess_token_response
along with the 2nd token request's response added as a separateaccess_token
. Example:At this point, our first refreshToken is invalidated by the provider we're using and we don't have the 2nd
refreshToken
created during that 2nd request.Code block in question: GenericOAuth2Plugin.java, line 438
Platform(s) Support Requested
Describe Preferred Solution
As it's openid's
AuthState
performActionWithFreshTokens()
's callback that's preparing the new accessToken for theResourceUrlAsyncTask
(and the eventual adding of the response and token withOAuth2Utils.assignResponses()
), an option to disable the call forauthState.performActionWithFreshTokens()
via config value (ex:freshTokenAttemptEnabled
boolean
added toOAuth2Options.java
or something) could be the easiest approach. Where the default would be to do the 2nd token call where a false flag would simply not attempt it.Example config and usage:
Example change:
and an overload of
resolveAuthorizationResponse()
:Describe Alternatives
Alternatives for the prevention of the 2nd
tokenRequest
attempt are limited outside of the mentioned block. Another alternative would be to have openid include therefreshToken
in the AuthState'sAuthorizationService.TokenResponseCallback()
(Followed by including it with theResourceUrlAsyncTask
for the assigning). And then updateOAuth2Utils.assignResponses()
to also include it:This way, the consumer can decide to make use of either result. The ones inside of the original
access_token_response
or the appended tokens.This does not seem viable.
Additional Context
This doesn't appear to be an issue with IOS. ByteowlsCapacitorOauth2.swift and the authenticate flow does not appear to have a case for attempting a request with 'fresh' tokens after the initial
accessTokenJsObject
oraccessTokenResponse
is created.