ioMoVo supports the standard identity protocols, so in most cases your existing directory can be the source of truth for who gets in.
How sign in works
In a cloud deployment, ioMoVo runs its own identity layer and uses Azure AD B2C as the identity broker to federate out to your provider. In an air gapped deployment, identity is controlled by your environment instead.
Accounts and tenants are separate things
This is the part most worth understanding up front. A person can hold an ioMoVo account that is not tied to their corporate account. Having an account does not put someone inside your workspace.
To get access to your content, a user must be invited to join your tenant. Membership in your tenant is what grants access, not the existence of an account. So the question to ask when auditing access is not who has an ioMoVo login, it is who is a member of your tenant.
Session length
Access tokens last 30 minutes. That number matters when you are planning offboarding, because it sets the outside edge of how long an already signed in session can keep working after you disable someone upstream. See Removing a user's access for the full sequence.
Setting it up
Your ioMoVo contact will walk through the federation configuration with whoever owns your identity provider. Have these ready:
Which provider you are federating from
Which attribute you want to use to match users
Whether you are provisioning users automatically or inviting them
Which groups, if any, should map to ioMoVo roles
That last one saves the most time later. Agreeing the group to role mapping during setup avoids a manual permissions cleanup a few months in.