What is SAML vs OIDC vs SCIM?
SAML and OpenID Connect are both single sign-on protocols: they let an identity provider tell an application who a user is. SAML uses signed XML assertions and suits established enterprise setups; OIDC uses signed JSON tokens and suits modern web and mobile apps. SCIM is different: it creates, updates and deactivates the accounts themselves.
How Personal Academy handles it
Personal Academy offers SAML and OIDC sign-in and SCIM 2.0 user provisioning on every paid plan; no identity provider has been tested end to end with it yet.
A worked example
Suppose a 300-person retailer is setting up a learning platform. Its IT lead uses OIDC for sign-in because the company identity provider makes it a few fields of setup, and turns on SCIM so new store managers get accounts automatically and leavers lose access the day HR closes their record. SAML stays available for a partner organisation whose own identity system only speaks SAML.
These three standards are often listed together on security questionnaires, but they solve two different problems. Sign-in asks: is this really the person they claim to be? Provisioning asks: should this person have an account here at all, and with what details?
SAML 2.0 and OpenID Connect both answer the sign-in question. In each, the application redirects the user to an identity provider, the provider authenticates them, and a signed statement comes back. With SAML, that statement is an XML assertion posted through the browser. With OIDC, it is a JSON Web Token obtained through an authorisation code exchange. Both rely on public key signatures and on careful checks of issuer, audience and expiry.
The choice between them is usually practical. Many established enterprise identity systems were configured around SAML, and some partners can only offer SAML. Newer cloud identity providers make OIDC quick to set up, and it fits mobile and single-page applications better. Many products accept both so the customer can choose.
SCIM answers the provisioning question. The identity provider calls the application SCIM API to create a user when someone joins, update their details when they change role, and deactivate them when they leave. Without SCIM, accounts are created on first sign-in or by hand, and leavers may keep dormant accounts that still count for licences or hold personal data.
A complete setup therefore pairs one sign-in protocol with SCIM. When comparing vendors, check which plan includes each, whether SCIM covers groups as well as users, and whether the vendor has tested the setup with your identity provider.