NIFI-15070 Fixed OAuth2AccessTokenProvider to properly handle permane…

[turcsanyip]

…nt access tokens that have no expiration time

Summary

NIFI-15070

Tracking

Please complete the following tracking steps prior to pull request creation.

Issue Tracking

• Apache NiFi Jira issue created

Pull Request Tracking

• Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
• Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

• Pull Request based on current revision of the main branch
• Pull Request refers to a feature branch with one commit containing changes

Verification

Please indicate the verification steps performed prior to pull request creation.

Build

• Build completed using ./mvnw clean install -P contrib-check
  • JDK 21
  • JDK 25

Licensing

• New dependencies are compatible with the Apache License 2.0 according to the License Policy
• New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

• Documentation formatting appears as expected in rendered files

[exceptionfactory]

Thanks for addressing this issue @turcsanyip.

On a quick review, I'm concerned about making the expiresIn field nullable, as it changes the expectations for the returned getExpiredIn().

Instead, returning an Optional<Duration> as a new method on AccessToken might be a more compatible way to implement the changes.

[turcsanyip]

@exceptionfactory Thanks for highlighting this issue. Actually, the changed behavior was not applied in JWTBearerOAuth2AccessTokenProvider which should be adjusted. However, I would not introduce alternative methods because the real problem is that the current getExpiredIn() and isExpired() methods do not handle a valid scenario (permanent tokens). In that case we would keep getExpiredIn() and isExpired() fully compatible but containing the bug.

Instead, I would suggest modifying the type to Long and adjusting all usages in the codebase. As this is a component interface and is not part of nifi-api, I don't think we must follow strict compatibility.

[exceptionfactory]

Thanks for the reply @turcsanyip. Although this is not part of the nifi-api, the signature change could have theoretical impact of components built to interact with the Controller Service interface. With that being said, changing from long to Long should have minimal impact, so I'm willing to go forward with the change and updating all references in the project repository

[turcsanyip]

Thanks @exceptionfactory. Updated the PR with the change in JWTBearerOAuth2AccessTokenProvider (tested with Salesforce and also with another provider that sets the expires_in field).

[turcsanyip]

@exceptionfactory Based on further testing, it looks Salesforce expires the session even if the access token has no expiration time. So maybe it would be a better approach to add a user configurable Expiration Time property to StandardOauth2AccessTokenProvider (as in case of JWTBearerOAuth2AccessTokenProvider) and use this value as default when no expiration time is provided.
Please give me some time to test it thoroughly and put the review on hold till then.
Thanks

[exceptionfactory]

@exceptionfactory Based on further testing, it looks Salesforce expires the session even if the access token has no expiration time. So maybe it would be a better approach to add a user configurable Expiration Time property to StandardOauth2AccessTokenProvider (as in case of JWTBearerOAuth2AccessTokenProvider) and use this value as default when no expiration time is provided. Please give me some time to test it thoroughly and put the review on hold till then. Thanks

Thanks for the update, I will hold off on further feedback until you have run through some additional tests. Perhaps introducing a strategy property, something like Expiration Handling with Access Token and Configured as possible values, where Configured requires an explicit Expiration Period property could work for this generic service. I'm open to considering options. It may also require something more specific for Salesforce, so that is another thing to keep in mind in terms of scoping potential changes.