In IAM evaluations the same acronyms come back in every document, used with slightly different meanings by every vendor. Here each one gets a neutral definition of the standard and, where it makes sense, a line on what LoginMaster supports today — including the entries still on the roadmap.
The set of processes and technologies that manage digital identities and access to applications: authentication, authorization, account lifecycle and access traceability. It is the layer that answers two questions — who is this person and what can they access.
With LoginMaster: LoginMaster is an enterprise IAM platform: it covers workforce, CIAM, B2B multi-tenant identity and non-human identities inside the same tenant.
IAM applied to end-customer identities rather than employee ones. Priorities shift: self-service registration, social login, a branded sign-in experience, high volumes and privacy consent management.
With LoginMaster: Registration, onboarding, social login and self-service accounts are covered by the CIAM module, with personal data staying inside the customer tenant.
The mechanism that lets a user authenticate once and reach multiple applications without re-entering credentials. It reduces the number of passwords to manage and concentrates security policy and access revocation in a single place.
With LoginMaster: SSO with Google Workspace and Microsoft Entra ID via OAuth 2.0 and OpenID Connect. SAML 2.0 federation toward other identity providers is on the roadmap.
A delegated authorization standard: it lets an application obtain limited access to a resource on a user's behalf, without ever seeing their password. It is not an authentication protocol — it says what an application may do, not who the user is.
With LoginMaster: It is the protocol behind application integration and federation toward corporate identity providers.
An identity layer built on top of OAuth 2.0: it adds the ID token, which carries a verifiable statement of who the authenticated user is. It is the reference standard for authenticating modern web, mobile and API applications.
With LoginMaster: Applications connect to LoginMaster via OpenID Connect and verify the signature of the received token with a project-dedicated key.
An XML-based federation standard, older than OIDC and still widespread in integrations with long-established corporate identity providers such as Active Directory Federation Services. It carries identity assertions inside signed XML documents.
With LoginMaster: Native SAML 2.0 support is on the platform roadmap: today federation runs over OAuth 2.0 and OpenID Connect.
A compact, signed format for carrying claims between two parties. The signature guarantees the content has not been altered, but the payload is only encoded, not encrypted: it is not the place to put secrets.
With LoginMaster: Tokens issued by LoginMaster are signed twice — by the Tenant and by the Cloud — so authenticity is verifiable on two independent cryptographic levels.
Authentication that requires more than one proof of identity, combining something you know (a password), something you have (a device) and something you are (biometrics). 2FA is the special case with exactly two factors.
With LoginMaster: 2FA is TOTP-based, compatible with Google Authenticator and similar apps, and configurable per project: disabled, optional or mandatory.
The algorithm that generates temporary codes from a shared secret and the current time, defined by RFC 6238. It is the mechanism behind the six-digit codes in authenticator apps.
Passwordless credentials based on a cryptographic key pair: the private key stays on the user's device and is unlocked with biometrics or a PIN. There are no shared secrets to intercept, which makes them phishing-resistant by design.
With LoginMaster: Native FIDO2/WebAuthn passkey support is on the roadmap: today the passwordless experience comes from federated SSO and a zero-knowledge credential model.
The standard that automates synchronization of users and groups between different systems, typically between an identity provider and connected applications. It exists so that onboarding and offboarding do not stay manual operations.
With LoginMaster: Native SCIM 2.0 support is on the platform roadmap: today the same outcome is achieved with REST APIs, TypeScript/.NET SDKs and webhooks.
Managing an identity from the moment it enters the organization (joiner), through role changes (mover), to full access revocation on exit (leaver). The third step is the most critical: forgotten accounts are one of the most common attack surfaces.
With LoginMaster: Provisioning, role changes and deprovisioning are automated via REST APIs, SDKs and webhooks, with immediate revocation of access, API keys and sessions.
A security model that grants no implicit trust based on network position: every access request is verified, privileges are reduced to the minimum necessary, and a breach is assumed to have possibly already happened.
With LoginMaster: It translates into conditional access, per-project configurable 2FA, cryptographic isolation between tenants and no administrator able to override a user's credentials.
The policies that decide whether and how to grant access based on the context of the request, rather than applying the same rule every time. It is the mechanism that makes MFA adaptive instead of uniform.
With LoginMaster: Policies are set per project: 2FA can be required for all users, for specific roles only, or left optional.
The architecture by which a single platform serves multiple organizations while keeping their data and configuration separate. What matters is how the separation happens: an application rule can be bypassed by a bug, a cryptographic key cannot.
With LoginMaster: Each tenant has its own key pair and each project a dedicated key, with unique certificates and salts: compromising one tenant does not touch the others.
The model in which users' personal data resides exclusively on the customer tenant, while the vendor cloud operates only on encrypted, pseudonymized data and never holds readable emails, names or credentials.
With LoginMaster: It is the architecture the platform is built on: vendor access to user data is impossible by design, not forbidden by policy.
Argon2 is the password hashing function that won the Password Hashing Competition, designed to be memory-hard and therefore resistant to attacks using dedicated hardware. Split-salt distributes the salt across two separate systems, so neither one alone is enough to attempt an offline attack.
With LoginMaster: Credentials are protected with Argon2 and the salt is split between Tenant and Cloud.
Identities that do not belong to a person: service accounts, IoT devices, AI agents, automated integrations. In most organizations they outnumber human ones, yet they are still governed with tools designed for employees.
With LoginMaster: Devices and agents get dedicated identities with least-privilege credentials, individually revocable and traced in the audit logs.
The European Union's General Data Protection Regulation. For IAM the points that weigh most are data minimization, protection by design, and the ability to demonstrate who accessed what and when.
With LoginMaster: Compliance is a property of the architecture: personal data never leaves the customer tenant and the cloud handles only encrypted, pseudonymized data.
The European directive that raises cybersecurity requirements for essential and important sectors, from healthcare to energy to public administration. On the identity front it requires strong authentication, risk management and access traceability.
With LoginMaster: Per-project configurable 2FA, multi-layer encryption, cryptographic isolation between tenants and dual-signature tokens cover the identity requirements.
The international standard for information security management systems. The controls most relevant to IAM concern access management, cryptography and communications security.
With LoginMaster: The architecture is aligned with those controls and access logs are audit-ready. The detailed mapping is on the compliance page.
The principle that data is subject to the laws of the country where it resides and is processed. In IAM it becomes concrete when you ask which jurisdiction can compel the vendor to hand over your users' identities.
With LoginMaster: The platform is designed and built in Italy, with hosting and data exclusively in Europe, and personal data never leaves the customer tenant.
For article-length deep dives — OAuth versus OIDC versus SAML, 2FA compared with MFA, NIS2 and access management — see the blog. To try the standards hands-on, the free tools include an XML/SAML formatter.
Knowing what SCIM means does not tell you whether you need it. That answer depends on how many applications you have integrated and which directory you already use: it is the conversation every serious evaluation starts from.
Step-by-step procedures, request examples and explicit comparisons between the available options.
A complete implementation guide: identity broker, app registration, OIDC and SAML 2.0 federation to Entra ID and Google Workspace, claim mapping, revocation and testing.
Tenant model, tenant resolution, per-customer SSO federation, white-label, cryptographic isolation and onboarding: the decisions that determine what your next enterprise customer will cost you.