Curity Identity Server

Organizations across the private and public sectors are under pressure to deliver better digital experiences and new services while enabling secure, convenient access for employees, contractors, partners, B2B customers, and consumers. Meeting these needs requires flexible authentication methods and assurance levels, risk-adaptive “step-up” authentication and authorization, policy-based access control, comprehensive identity/attribute management for workforces, consumer self-service identity capabilities, and identity federation for partners and B2B relationships. Provisioning and de-provisioning must be timely to reduce data-loss risk at employment end, while attribute assignment is central to enforcing policies. In regulated consumer industries such as banking, retail, and insurance, online registration, profile editing, and consent management are essential.

Some organizations prefer fully customizable IAM/CIAM, open-source approaches, or component-based builds; others only need limited identity “wrapping” around a single application. Dev-centric C/IAM solutions address these needs by enabling modular deployment around existing infrastructure, often on-premises or in IaaS, commonly with Docker/Kubernetes support, but they require skilled developers.

Curity AB, a privately held IT security firm in Stockholm, offers the Curity Identity Server (launched in 2015) with an API-first focus on authentication, token services, and user management. The product runs on Linux, supports container platforms, and provides Basic, Standard (single company), and Enterprise (covers affiliates/subsidiaries) licensing. It supports a broad set of authentication methods (including social login, GSMA Mobile Connect, select European national eIDs, and Swedish BankID), plus OAuth, OpenID Connect, and SAML for federation/SSO. A built-in risk engine evaluates factors like IP, time, device type, and user history, with extensibility via SDK for advanced risk and intelligence feeds. Its token service supports extensive OAuth/OIDC-related standards and exposes standard-compliant APIs, while user management integrates with LDAP, RDBMS, SCIM, and existing portals and data stores (SQL/no-SQL). Strengths include standards support and modularity; challenges include limited native mobile capabilities, lack of FIDO, and a relatively basic risk factor set.

• Curity AB is a privately held IT security firm headquartered in Stockholm, Sweden.
• Curity launched its identity server in 2015 with an API-first strategy.
• Curity Identity Server can be deployed on-premises or hosted in IaaS environments.
• The licensing model has three options: Basic, Standard, and Enterprise.
• The product is composed of three modules: Authentication, Token Service, and User Management.
• Curity Identity Server runs on Linux and works with Docker and Kubernetes.
• FIDO is not supported by the solution.
• The risk engine can evaluate factors including IP address, IP blacklists, date/time, device type, user attributes, and user history.
• Curity is OIDC certified and the token service functions as an OAuth2 Server and OpenID Connect Provider.
• User provisioning is supported via LDAP, RDBMS, or SCIM.

• “Dev-centric C/IAMs allow customers to build a modular solution around existing infrastructure or services, without having to buy more features and functionality than needed.”
• “Trends in workforce authentication are increasingly away from passwords and toward strong and/or multi-factor authentication (MFA).”
• “For partners and contractors, identity federation is a must.”
• “For all kinds of users, risk-adaptive authentication, the ability to ‘step-up’, is a necessity depending on the type of access or transaction.”
• “For identity and access management, the ability to provision and de-provision users in a timely manner is critical, not only for business enablement but also to diminish the possibility of data loss when employment ends.”
• “Attribute assignment and management is a key to proper policy-based access control operations.”
• “Curity allows customer admins to write policies which can force step-up authentication as required by business policies.”
• “All operations within the authentication risk engine are accessible through the APIs.”
• “The Token Services are all addressable via documented, standard-compliant APIs.”
• “Administrators can define and script name and attribute transformation for user data normalization between different domains.”