KNOX-3038 - The expires_in field in OAuthResource response returns the configured token TTL.

[smolnar82]

What changes were proposed in this pull request?

To honor the contract of the existing expiration time in the database for Knox Tokens, I removed the override in the new OAuthResource class. Thus, everything that depends on this field will be the same as in the case of our "regular" tokens (token eviction is the most important piece here).
To indicate the actual OAuth token lifetime, I changed the meaning of the expires_in field in the JSON response: that's the configured TTL in seconds.

How was this patch tested?

Updated JUnit tests and executed manual testing:

$ curl -ik -X POST -H "Content-Type: application/x-www-form-urlencoded" --data "grant_type=client_credentials" --data "client_id=$CLIENT_ID" --data-urlencode "client_secret=$CLIENT_SECRET" https://localhost:8443/gateway/tokenbased/oauth/v1/token
HTTP/1.1 200 OK
Date: Thu, 10 May 2024 23:46:18 GMT
Content-Type: application/json
Content-Length: 1098

{"access_token":"eyJqa...0ijh_g","refresh_token":"a36bafd4...9491-7e17e710a004","issued_token_type":"urn:ietf:params:oauth:token-type:access_token","token_type":"Bearer","expires_in":10368000}

The tokenabased topology was configured with knox.token.ttl = 10368000000. As you can see, the expires_in field in the response was populated as expected (converted the given TTL milliseconds to seconds).

[pzampino]

LGTM

[lmccay]

If I am reading this correctly, then returning the actual value in the response as lifetime_secs would be unexpected by OAuth flow consumers/clients. They will be looking for expires_in.

I think what we need to do is calculate both the existing expires_in which millis since epoch as well as this OAuth expires_in which is lifetime_secs and return one in the response and store the other in the token metadata for reaping and monitoring, etc.

[lmccay]

LGTM!

+1