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.

Regarding the SPA and proper authentication flow, there are some more things to consider. First, if your SPA is served from the domain that is different from your backend's domain (eg. using Vercel to host SPA frontend) then you'll have issues with cookies between different domains. Another thing is security, specifically CSRF. You'll possibly have to implement some CSRF tokens to handle this. There is a lot of information regarding these topics on the Internet but still it doesn't seem to be very easy to implement. The first link I've found on the topic: https://ideneal.medium.com/securing-authentication-in-a-spa-using-jwt-token-the-coolest-way-ab883bc372b6.
Would be great if FusionAuth docs can also describe these issues (different domains, CSRF).

Because of that it is worth considering if some other flow isn't better - AuthorizationCode + PKCE that doesn't touch the backend at all (no cookies, no CSRF issues, but you have to be careful with XSS). I've implemented a proof of concept React application that uses https://github.com/IdentityModel/oidc-client-js and slightly modified react-oidc (that is a react wrapper to oidce-client-js), and it seems to work nicely with FA for me.

Fair enough.

While I'm always interested in learning more about how FusionAuth fits into system architectures, we don't document many proxy configurations, as they tend to be pretty scenario specific. There are also a lot of different proxies out there, often with good documentation!

But sure, anything you figure out we'd love to have you add to the fusionauth-contrib project as a PR to share with the community.

Thanks!

That is an encoded (signed) JWT being sent in response to the user info request that the FusionAuth OIDC identity provider is making.

This is technically allowed in the OIDC spec, but we do not currently support this response type.

Per spec, the endpoint should support a JSON response which is the default unless the client requests a signed or encrypted response body.

I would look at how your client is registered and see if it is asking for a JWT userinfo response at that time, and change it to be a normal JSON response. You could also file an issue detailing your needs for FusionAuth to support this user info response type.

If that isn't an option, you could also look at using a SAML Identity Provider if the remote identity source supports that.

You would have to add a hook in your IdP to make an API call to delete the user in FusionAuth. However, because the SoR will no longer have this user, the use will not be able to log in via FusionAuth either unless their password is reset.

We have discussed adding support for SCIM which may provide some of these types of features assuming other IdPs also support this standard. This is on the roadmap: https://github.com/FusionAuth/fusionauth-issues/issues/106

@gjermund welcome to the FusionAuth community!

Interesting problem. You might be able to model this with Groups and Applications. I'm not quite sure how it relates to multi tenant; tenants are really about separating user accounts and configuration so that users in one tenant won't be aware at all of user accounts in other tenants, even if they have the same email address.

One thing to note is that roles are never assigned in FusionAuth if a user isn't registered to an application. Let's assume you have two orgs (org1, org2) and two facilities (fac1, fac2).

So, let's say you have an application AppA (you can have more, you'd just need to replicate all the roles for each application, so I'd script their creation using the API).

AppA roles: org1admin org1manager org1member org2admin org2manager org2member fac1manager fac1member fac1auditor fac2manager fac2member fac2auditor

Now, let's assume there are two users. Alice and Bob. Alice is a a admin in org1 and a member in org 2, as well as an auditor in fac1. Bob is just a member in org2. Both are registered for AppA (remember, roles are dependent on applications and a user being registered for an application!)

If I created a group for each role:

org1adminGroup org1managerGroup org1memberGroup org2adminGroup org2managerGroup org2memberGroup fac1managerGroup fac1memberGroup fac1auditorGroup fac2managerGroup fac2memberGroup fac2auditorGroup

I can add users to one or more groups and they will pick up the roles. The roles will be available in both the JWT generated on login and the user object retrieved by the User API.

So I'd add Bob to the org2memberGroup only. If Bob isn't registered for AppA, he doesn't pick up any roles, no matter what groups he is in.

And I'd add Alice to the following groups:

org1adminGroup org2memberGroup fac1auditorGroup

Nope. While you can modify attributes of the user object and the changes will be persisted, you can't modify the registrations of that user.

@maximiliano-riffo , welcome to the FusionAuth community!

I don't understand what you are trying to do. Are you trying to verify a user's email without sending them an email? I'm not sure I understand how that would work.

If you want to build your own verification system, you can do that.

Create an attribute user.data.verifiedBySMS on user creation and set it to false. Send the user an SMS using any SMS provider. Include the code and a link to a page in your app. When the user enters the code in the app, update user.data.verifiedBySMS to true. Build your application UI to test the value of user.data.verifiedBySMS. You could also put it in a JWT.

Maybe I misunderstand your question, though.

@johnmiller

Welcome to the FusionAuth community!

Please open a feature request in the github issues repository explaining how you'd like the feature to work in details. Feel free to reference this forum post.

You can of course, also increase the expiration time of the password setup email, detailed here: https://fusionauth.io/docs/v1/tech/core-concepts/tenants/#advanced

The best solution is to migrate first name and last name from your previous provider.

I don’t know of any other options. Apple is stingy with those details about the user.

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.

This functionality doesn't exist in the FusionAuth admin screens, please feel free to file an issue with a detailed use case if you feel it should.

For registrations, you can look at the date the application registration was created using the User Search API. You'll probably want to use a date range.

For logins, you can review and search all login records by going to "System -> Login Records". However, one could build something with more granularity using the FusionAuth APIs.

This API documents how to pull down the log in data for a given date range. This doesn't include the full user object, but does include the user id. From there you could use the user api to pull down the entire user object.

Also, please note that login records may be deleted after a certain period of time, based on your system settings. This deletion is controlled in the admin UI, under "Settings -> System -> Advanced -> Login record settings" and would impact your ability to query login data in the past if enabled.

Hiya,

Unless you want to use the premium features of FusionAuth, this usage would be allowed under the FusionAuth license and you could use the community edition to host it for free.

Here's a license FAQ that hopefully makes things more clear.

Hi @harunkilic ,

Welcome to the FusionAuth community! I am glad you like the software.

You can't create group fields. What you can do is assign roles to a group. If a user is in that group and registered for an application with those roles, they will assume the roles. For example:

User A is in Group B. Group B has roles 1, 2, and 3. Role 1 is in Application Z. Role 2 and 3 are in Application X.

If user A is registered for application X and is in Group B, they will have roles 2 and 3. They won't have role 1 because that is associated with application Z, which they are not registered for.

You can't build your own entities, though that is on our roadmap. Follow this issue to be updated on when that feature is implemented. Full transparency, it will likely be a feature limited to our paid editions; learn more about our paid editions here.

Whether groups make sense depends on a lot of things.

Some questions to consider:

Are you limiting application access by group? Are you going to be using the API to do so, or do you want to have the information in the JWTs and available after authentication? Does each company have an application? Are you going to use the hosted login pages or build your own?

I can't give extensive architectural advice, but maybe if you talk a bit more about your use case the choice will be clearer.

Yes we support this. These docs should help you through this process.

https://fusionauth.io/docs/v1/tech/identity-providers/apple/#building-your-own-integration

https://fusionauth.io/docs/v1/tech/apis/identity-providers/apple/#complete-the-apple-login

From the latter doc:

Using this API you can pass that id token returned from Apple to FusionAuth and we will complete the login workflow and reconcile the user to FusionAuth.

Reconciliation means that the user is created in FusionAuth if needed, a JWT is generated, and a login session is created as well. They will essentially look like any other FusionAuth user.

@trevorr said in Is it possible to create a user without a password?:

Would changing this be a reasonable feature request?

Sure, seems reasonable to me.

I'm not quite sure of the ramifications because the identity providers are assigned at the application level and users are a tenant scoped entity, but I suppose you could just say that any user marked with a 'nolocalpassword' attribute would not be able to ever log in locally. They'd always have to be authenticated by a third party system. I haven't thought through all the ramifications but think this would be a fine feature request. Please file away 🙂 : https://github.com/fusionauth/fusionauth-issues/issues

Note that the random password example in that other thread might fail sporadically because there's no guarantee that a base-64 string will contain a "special character".

Maybe I misunderstand you here, but that's a matter of the password rules and the random string generation, correct? You could set up random long strings and make sure they included non alphanumeric characters. Should be a library for that (here's one for java). Or you could relax your password rules to allow for only alphanumeric characters (this may or not make sense, depending on what kind of users you have logging into the tenant).

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.

This exception is caused by the fact that your objects in elastic now have two different schemas (one with the number, one with the string). You need to manually fix that; one way to proceed might be to access elastic directly and remove that one user.

Then you'll need to reindex; here's more on that: https://fusionauth.io/docs/v1/tech/core-concepts/users/#reindex

That is correct. If one user logs in 1,000 times on Feb 9, 2021, it is one active user for that report. The login count report would show 1,000 (assuming no other users logged in) but the DAU report would display 1.