If you have your own login form, you'll either be using the Login API or the OAuth Password grant. You will use one or the other, not both, each option will provide you roughly the same functionality. Totally up to you, the Login API is our own creation, the Password grant is defined by the OAuth RFC.
Collect email and password
Call the Login API or the Token endpoint using the Password grant
Collect the JSON response which will contain an access token (JWT)
That response is essentially defined by OAuth2 / OIDC as the token response. If you want to customize it, the best solution is to use a lambda to encode additional details in the access_token (JWT) and then at the client decode that value to extract the necessary claims.
As mentioned in this github comment, we don't support continually renewing refresh tokens, as that essentially means that users remain logged in forever.
We do not currently issue a new refresh token during the refresh_token grant. If the refresh token you sent is valid you'll get a new access_token back. Once your refresh token expires, you'll need to request a new one by requiring the user to authenticate again.
If we were to issue a new - or "refreshed" (updated expiration) each time you used the refresh token to gain a new access token using the refresh_token grant - that would effectively provide a sliding window session. This would allow for a perpetual use token which we do not support.
Totally understand your UX concerns. There's a tension between ease of use and security that only you can balance.
I don't know the application or data you're working with, so I can't make firm recommendations. However, you can set the refresh token to have a long lifetime like 180 days. That is a setting in the tenant screen or tenant.jwtConfiguration.refreshTokenTimeToLiveInMinutes in the API. And then have the user log in after the refresh token has expired.
Please feel free to file an issue in the GitHub repo explaining the use case for perpetual use tokens. We can't commit to any implementation but we love to hear what customers want, and GitHub is what our engineering team uses to feed the development backlog.