The short answer is however often you want, but at least once per device.
You basically can set up your refresh token policy to have your refresh tokens live for a very long time (as long as you are comfortable with the security risk; make sure to secure the refresh token carefully). That is controlled in in the application configuration: https://fusionauth.io/docs/v1/tech/core-concepts/applications/#jwt
Then, every time an access token expires, you can mint a new one with the refresh token. Here are the APIs you'd be interested in calling:
Yes, if self service registration is enabled (which is set on an application by application basis) and a user who is already logged in to FusionAuth tries to register for such an application, FusionAuth will automatically register them for the app. It also checks that all required profile information is filled out, which is why adding the required field displays the registration form.
You have a few options to do this. Unfortunately the login page, while very customizable in terms of look and feel via themes, is less customizable in terms of functionality and adding fields. Here are some options:
don't use our hosted login pages, instead build your own login pages (and all the other stuff like reset password, etc) using the Login API. You get total control of the login experience, at the cost of more custom code.
check for consent when the application is loaded, after authentication. You could store a consent variable on the user object (in the data field) or use our consent model. Basically, after the user authenticates, take them to an interstitial page unless they have given consent. Put that logic in the application page they first land on.
Another option would be to use advanced registration forms for self registration and create a consent that would be required at sign up. Naturally, this doesn't help if you aren't using self service registration.
This is a common issue, as there are a couple of prerequisite settings that you need to configure in order to get refresh tokens. When you are trying to get a refresh token and not seeing it, you should double check the following items:
you are passing a value of offline_access whenever a scope parameter is present.
you have configured the application to generate refresh tokens
if you are using OAuth, in the UI, it is in the OAuth tab; the field is Generate Refresh Tokens
if you are using the Login API, it is in the Security tab under Login API Settings; the field is Generate Refresh Tokens.
you are passing the client_id to the refresh grant request. This is required unless you are passing the Authorization header (which has the client_id in it).
the user is registered to the application for which you are issuing a refresh token.
If using the API, you should receive a 203 on Login once you attempt login with the correct password. Your application should check the status code and send the user to the appropriate place to change their password.
If using the hosted login pages, you should end up on the /password/change page after logging in.
When the user arrives at the Forgot Password we capture all of the OAuth2 state, including PKCE parameters. When the user completes this flow, we replay all of this state, so the login will complete using PKCE.
If you want the Forgot Password flow to complete without this step, you can either handle Forgot Password in your SPA, or when you redirect them to the FusionAuth Forgot Password page /password/forgot - do not provide client_id on the request. If client_id is not provided, we will assume this is not within the OAuth2 workflow and we will not attempt to log the user in at the end of the flow. In this case, the user will end up on /password/complete.
This is possible. Doing so allows you to weave passwordless into the normal OAuth flow so you can use standard OAuth libraries but not have your user enter a password.
Start the passwordless login on the server side (using the API).
Get the passwordless code.
Send this url to the client: [FusionAuthURL]/oauth2/passwordless/[passwordlesscode]?redirect_uri=[redirect URI]&response_type=code&client_id=[client_id].
Have the client request this url.
It'll be just as if the user had authenticated via the /oauth2/authorize endpoint and the user had entered their credentials. You'll get back an authorization code which can then be exchanged for an access token/JWT.