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.
The short answer is that these events are from when the user was created or first registered for an application.
When a user is first created, or registered for an application we create a login event because we generate a JWT and optionally a Refresh Token for the user.
In these cases, we do not have an IP address to record in the login event.
We have discussed adding the IP address from the API request, but this is likely a back end system or internal service and the IP address would not represent the location of the end user, and so would likely not be of great use.
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.
@bboure You may be interested in this new feature from the 1.17.0 release, which allows for a sliding window of refresh tokens:
Sliding Window Refresh Token Expiration. By default the expiration of a refresh token is calculated from the time it was originally issued. Beginning in this release you may optionally configure the refresh token expiration to be based upon a sliding window. A sliding window expiration means that the expiration is calculated from the last time the refresh token was used. This expiration policy means that if you are using refresh tokens to maintain a user session, the session can be maintained as long as the user remains active. This expiration policy must be enabled at the tenant level, and may optionally be overridden by the Application JWT configuration.