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:

https://fusionauth.io/docs/v1/tech/apis/jwt/

With advanced threat detection you can block access to applications via IP ranges (it's touched on briefly here: https://youtu.be/pjGxOXamVfk?t=1209 ).

Advanced threat detection requires an enterprise license. Currently you can't lock a certain user to an IP range, though.

Please feel free to file a feature request with details of this use case if you'd like to see this implemented.

Yes. That’s how it currently works.

We have on the roadmap a more flexible identity system but don't have a current timeline for implementation. Here's the tracking issue: https://github.com/FusionAuth/fusionauth-issues/issues/1

@alessandrojcm,

Sounds good. I have logged a bug report; we should have this one squashed soon!

Thanks,
Josh

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. use javascript and customize the theme. Add a consent checkbox to the login form, and set a cookie once the user consented so you don't record the consent multiple times. Make a call via javascript to an API (which you'd have to write) to record when the consent was given.

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.

Yes, you can disable one or more applications.

This operation can be reversed, and while an application is disabled, login requests to fail with a 400 error for all users.

Navigate to "Applications -> Deactivate (gray button)" to disable/deactivate an application.

To re-enable it from the admin UI, you'll need to 'view inactive', which is the button next to the green '+' sign on the list applications page.

Each user is unique within a tenant by email address. If a user in the same tenant wants to login with Facebook, Google, or LinkedIn, it will be the same User object.

We don’t currently support IdP initiated login.

This has come up a few times, we’ll likely end up adding it, but for now it is not possible. We have an open feature for this in GitHub.

Please feel free to upvote it or otherwise communicate your desire for this work to be done.

Yes. See the login_hint parameter here: https://fusionauth.io/docs/v1/tech/oauth/endpoints/#authorize

You can increase the timeout of the login request to a connector. If you sign in to the admin UI and navigate to "Settings" and then "Connectors", you can modify either of these settings:

"Connect timeout" "Read timeout"

The default value for these is 2 seconds.

There is more documentation on this topic here: https://fusionauth.io/docs/v1/tech/connectors/generic-connector/

You can also change them via the API, if that's more in line with your current workflow. That's documented here: https://fusionauth.io/docs/v1/tech/apis/connectors/generic/#update-the-generic-connector

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.

Hmmm. Since you haven't made any changes and aren't seeing any other errors, can you try to reindex?

Navigate to system and then re-index in the administrative user interface?

That should solve the issue.

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.

We handle all of this and you can use the native UIs for each of these when on mobile. This is all handled automatically by Facebook, Google, Apple and others.

More about external login providers.

@dan Thank you for your support. Fixing the signature just saved me another couple of hours (also coming from https://fusionauth.io/blog/2020/07/14/django-and-oauth/) ^^

@dan I was trying to use the standard register interface from fusion. If I check that I want to use "username" for example, the registration form removes the email option. To circumvent and get both email and username I had to create my own register form.

No. A lot of our clients use Google analytics (or other similar page analytics tools) to gather those type of metrics.