Registrations in FusionAuth are the link between Users and Applications.
A User can have zero or more registrations. Each registration can have zero or more roles associated with it.
The registrations API documents the allowed attributes of a User registration.
If a User exists in a tenant and attempts to authenticate against an Application, but are not registered, the authentication will succeed but they will not be authorized.
Core Concepts Relationships
Below is a visual reminder of the relationships between FusionAuth’s primary core concepts.
With advanced registration forms, you can customize the attributes of a registration. By default, registrations have the following attributes:
The username of the User for this registration only.
A list of locales that give, in order, the User’s preferred languages. These are important for email templates and other localizable text. See Locales.
The User’s preferred timezone for this registration.
The roles that the User has for this registration.
Registrations and Self-Service Registration
When you enable self-service registration for an application and a user who does not have a registration for that application successfully logs in to that application, the user will automatically be registered for that application, and have a registration added.
Let’s walk through a scenario. Suppose you have three applications:
- Hooli Jobs
- Pied Piper Video Chat, which has self-service registration enabled
- Pied Piper Email Service, which does not have self-service registration enabled
email@example.com has a valid account, and has a registration for the Hooli Jobs.
When Richard tries to log into Pied Piper Video Chat, he is able to log in. He is automatically registered for this application, since self service registration is turned on for it. Therefore the
applicationId claim is present in the token and any default roles are associated with his account.
When Richard tries to log into Pied Piper Email Service, he is able to log in, since he has a valid account in the tenant. But Richard is not registered for the application. Therefore no roles are associated with him and the
applicationId claim is not present.
You can read more about authentication vs authorization and registrations.