An external identity source will authenticate anybody it recognises. That is rarely the same set of people you want inside your application, so external users pass through an approval layer.
How it works
On first sign-in an external user is recorded, and whether they may proceed depends on the access mode configured against the source they came through. Their name and address are cached locally so your application can show them without calling the provider on every page.
This works identically for every external source — Azure AD, SAML, Google and all the social providers — so there is one thing to understand rather than eight.
Blocking individual users
External users are subject to the same controls as everybody else — see Blocked User Accounts and Blocked IP Addresses.
Practical advice
- Decide what a brand-new external user gets before you switch a source on. An account with no groups and no permissions is a far safer default than one that inherits something broad.
- Review who has arrived periodically, particularly after enabling a public provider.
- Where the population must be provably restricted — students, one organisation's staff — combine the login source with a gating verification type. See User Verification.
- Removing somebody from your application does not remove them from the provider. If they still have a working Google account they can still reach your login page; block the account here.
Worked Examples
- Public sign-up: new users land in a "Pending" group with read-only access until approved.
- Client portal: new users must pass an organisation verification before seeing anything.
- Leaver process: block the account in ActiveManage as well as disabling it at the identity provider.