Frequently Asked Questions

An identity server enables an organization to provide secure access to data for its users. A centralized identity server is an essential piece of a common security platform for all applications and APIs. It is especially useful to support different login methods and flows, a variety of databases and repositories, and when developing a mix of clients and technologies in the front-end and back-end, for APIs and microservices. With a centralized identity server you can manage of all that in one place.

The most straightforward way is to use our pre-built Docker images from Azure Container Registry. With a single command the server is then downloaded and started. The "Basic Setup Wizard" in the admin UI will guide you through an initial configuration, and you can fetch your trial key directly from the developer portal. Within minutes you'll be ready to authenticate users and create OAuth access tokens!

Whilst an API management platform is useful for managing the lifecycle of an API, the Curity Identity Server offers API-driven identity and access management. This is essential to effectively secure APIs and digital services, making it a great complement to your API platform. The Curity Identity Server provides prebuilt integrations to the most common API management solutions on the market and empowers API gateways and developer portals to be used at their full potential. Including the Curity server in your API platform allows you to address shortcomings and introduce new capabilities, e.g., scope explosion, claims-based authorization, privacy-preserving access tokens, consent management, adaptive authentication and much more.

For sure. Sign up on developer.curity.io using only your name and email. Click on Licenses to create your personal 15-days free trial.

The Curity Identity Server often replaces old, legacy solutions that were not built for API-driven, DevOps-oriented deployments or automated processes. Many identity solutions were designed in the early 2000s and not capable of addressing the challenges of the 2020s. Curity's technology it built for OAuth-based environments and configuration-as-code. Everything in the Curity Identity Server can be automated with a standard-based admin API that is transaction-based, version-controlled with audit trails, supports rollbacks across an entire cluster, and complimented by a fully scriptable CLI, Helm charts and Cloudformation templates available on GitHub.

Definitely. When utilizing the same technology and architecture for internal or external use cases (but not necessarily using the same instance), it's easy to build common services and APIs, that all share the same source of truth. A license of the Curity Identity Server always includes unlimited number of users and has a straightforward model. There is no need to worry about costs growing out of control and having to make non-optimal design decisions based on commercial limitations.

Yes, it's straightforward to migrate existing OAuth clients into Curity's OAuth server. Curity's OAuth implementation is extensive by default but you can also customize all token issuance flows in JavaScript to fit your specific needs and legacy. The Curity Identity Server comes with the capabilities needed to switch your identity platform, even while keeping existing users logged in.

One of the key architectural principles behind the Curity Identity Server is separation of concerns (i.e., the "UNIX philosophy" of having programs do one thing and do it well). Authenticating users (in the Authentication Service) and issuing tokens (in the Token Service) are separate problems and should therefore be treated separately. The Curity Identity Server supports any number of authentication services and token services in the same cluster, enabling multi-tenancy and the ability to create cloud services at a massive scale.

The Curity Identity Server comes as one product that's easy to manage. It's made up of the three distinct services: Authentication, Token and User Management. You can have as many instances of the services as you like, with different end points for different type of services or purposes, enabling large-scale scenarios and use cases in a single deployment.

Identity and access management (IAM) is part of cyber and information security strategies. It covers the policies, processes and supporting technologies to ensure that the right entities gain access to the right resources at the right time.

The difference between identity management and access management is that identity management deals with authenticating user accounts and authorizing access while access management deals with permissions and privileges.

The Neo-Security Architecture is a modular and open-standard-based security architecture. It aims to secure, protect and assert legitimate access to APIs and services as well as to applications both on web and on mobile. Read more about the Neo-Security architecture on this article.

Decentralized identity is a form of identity management that allows users to have full control of their online identity without involving a centralized authority. This is done through the use of a digital wallet that contains verified information about the holder from certified issuers such as the government.

In the decentralized identity framework, the user has a digital wallet which contains credentials that prove their idenitity. These credentials are provided by the government, employer, university or other authorized entities. The user can then present these credentials to organizations upon request, who can then verify them.

Verifiable credentials are digital credentials that can be used to prove the identity of a user. Verifiable credentials hold, similar to an ID token, attested claims about a user, the so-called - subject claims - together with some metadata such as issuance time. ID tokens are always JWTs whereas credentials can be presented using different formats including but not limited to JWTs. Examples of verifiable credentials include driving license, passport, ID, birth ceritifcate etc.

The Curity Identity Server can issue verifiable credentials using OpenID for Verifiable Credential Issuance. The credentials issued by the Curity Identity Server are currently always encoded as JWTs and bound to the user's Decentralized Identifier (DID). Find more information on this article.

Either actually. The Curity Identity Server is provided as a Docker image, Linux or macOS application, and can easily be deployed on AWS, Azure, GCP or your own servers. A Curity cluster can span across cloud platforms, enabling a multi-cloud or cloud-agnostic strategy to meet the highest availability requirements while avoiding vendor lock-in. Read more about deployment here. Curity never accesses your customers' PII. Maintaining full control of your users' identities and security enables you to comply with internal business requirements as well as regulations such as GDPR and PSD2.

The Curity product comes with an SDK that allows you to build your own extensions. All plugins and customizations are "first-class citizens", making them available in all admin interfaces (the GUI, CLI, REST API and XML-files), exactly like the built-in ones. You can find a wide range of examples and starting points on our GitHub page.

If you just want to try it out or for dev purposes your laptop is enough. In production a relational database is required and we recommend two instances for high availability.

Yes. The Curity Identity Server supports multiple ways of making configuration changes. To make changes to a running system a CI/CD pipeline you can either use our CLI or a REST interface, or simply deploying the full configuration as parameterized XML per environemnt. Together with the web UI the four interfaces offer the same functionality.

Yes. You can setup multiple administrators. You can then place them in groups for easy management of permissions. A group of administrators, e.g. devs, might only have access to the DevOps dashboard to manage clients.

Yes. You can export parts or the whole configuration and them import into another system. During import you choose if you want to completely replace your configuration or if you want to merge your current with the new one. It's also possible to parameterize the configuration and let each environment fill in the specific parameters for that environment.

Yes that can be done by either using the standardized Dynamic Client Registration (DCR) or by using an existing client.

There is a status endpoint that gives you quick insights into the operations of a server, this is typically used by systems like Kubernetes to monitor the pod. For more detailed insights the product produces metrics where the operators can see the current status and overall statistics. There is also an advanced alarm system available. Not only can alarms be sent to any system. like mail or Slack, but you can also see which part of the system is affected by the issue.

No. Opertions wise it is like any application. It typically runs in a Docker environment, send logs to your centralized log management. There is also a DevOps dashboard available where you can do simple tasks like creating clients and also be able to see alarms and what part of the system is affected by the alarm.

The Curity Identity Server is designed for 100% uptime. During upgrade the two versions run side-by-side and after the traffic is shifted to the new version, the old one is shut down.

The Community Edition is a free version of the Curity Identity Server, including all the essential core features available in the standard product. It comes with community support on Stack Overflow.

Anyone looking for a competent OAuth and OpenID Connect server and ready-made authentication solution. With current needs and requirements that are on a smaller scale.

After sign-up, you can fetch your license and download it directly on the Developer Portal. You can also pull it directly from Docker Hub, and get the license directly in the admin UI during setup.

After you have signed up, look at our Getting Started section, which includes a series of learning resources guiding you through the installation and configuration process.

Yes, it’s free. Not just for now, but for as long as you need it.

We have developed an extensive offering training courses, webinars, and demo videos, as well as expert insights on identity management, authentication, API security, and much more.

Start by having a look in our resource library or the reference documentation. The resource center includes a range of tutorials, code examples, and video walk-throughs covering most aspects of the Curity Identity Server. The answer to many user questions can be found there. If you don’t find a solution there, you can ask a question on Stack Overflow, tagging it with curity.

Community support is available on Stack Overflow. Just tag your question with curity, and someone in the community will find it and answer your question.

The difference is in the functionality and type of support. Community Edition provides a wide range of features that will allow you to authenticate users and provide secure access to your APIs. However, you get access to all the tools, features, and Curity team support in the paid versions. You can view a comparison of the various plans here.

Yes. If you wish to upgrade to one of our paid plans, contact our sales team, and they will be happy to help guide you to the plan best suited for your organization.

No, everything stays the same, including all configuration and integrations made. You only need to replace the Community edition license key.

If you find a security issue or vulnerability in the product, send an email to security@curity.io, the security response team will promptly reply. Do not report them on Stack Overflow or any other public channel. If you think you’ve found a bug, please send an email to ce-bug-report@curity.io.

If you have an idea or need some additional functionality, send your request to ce-features@curity.io. We appreciate your inputs and will consider them for a future version of the product.

The Hypermedia Authentication API (HAAPI) is part of the product and is enabled by default for all paid editions of the Curity Identity Server.

The Hypermedia Authentication API (HAAPI) is enabled by default in the Curity Identity Server, for all paid editions.

Yes, the Hypermedia Authentication API (HAAPI) is OAuth compliant.

The Hypermedia Authentication API provides high security through client attestation and sender-constrained tokens. If you decide to provide authentication in your applications using HAAPI, then you can drop the usual solutions used because of browser vulnerabilities (as now no browser is used in the flow).

Credentials can be entered in the app if it is a first-party application. Then the same entity owns both the application and credentials, so this is not against recommendations. For third-party apps that use HAAPI, you should only use authentication methods that do not require entering credentials in the app (e.g., use an e-mail link).

Everything that can be rendered server side can also be used via the Hypermedia Authentication API (HAAPI).

Yes, HAAPI works on all modern mobile devices. It also provides a fallback method for devices that do not support client attestation (e.g., phones with Android version less than 8.0.)

On mobile, user authentication and login can be done without leaving the app or involving a browser. Client attestation ensures it’s secure, and the API only communicates with a genuine client (app).

You can use all types of authentication. If the authentication requires the user to leave the API flow, e.g., federation, the step on how to proceed will be presented. Once done, the HAAPI flow will continue.

The Hypermedia Authentication API (HAAPI) is part of the product and is enabled by default for all paid editions of the Curity Identity Server.

In addition to mobile, you can also use the Hypermedia Authentication API (HAAPI) for Single Page Applications to create a smooth authentication experience.

Yes. The configuration specifies which security levels should be used. Rooted devices are one of these settings. In production, it is strongly recommended not to allow rooted devices.

The Curity Identity Server supports many authentication methods, including simple username+password, social login, and passwordless authentication, to name a few. You can style these different methods in your own look-and-feel. Using Curity's SDK you can easily build your own authentication method, and the new method will be configured and used exactly like the built-in ones. Find more information about ways to authenticate here.

Yes, the Curity Identity Server supports WebAuthn out-of-the-box. The authenticator can be configured and used with, for example, Apple TouchID, YubiKey, or other devices supporting WebAuthn.

Yes, you just have to simply configure the ready-made Authentication Service in the Curity Identity Server.

Yes, the Curity Identity Server can federate to external identities as well as using internal identities. It is also possible to configure account linking where an extrenal identity is linked to an internal identity.

The Curity Identity Server ships with a powerful tool for populating tokens with claims. Claims provide a fine-grained way to perform authorization decisions and limit the amount of scopes in the system. They can be further used to integrate with Entitlement Management Systems, like OPA to provide even more control over authorization.

Tokens play a central role in establishing trust and ensuring the API has enough information to make the right access decision, every time. The Token Service is the profile of the Curity Identity Server that is responsible for issuing security tokens. To fully leverage OAuth and OpenID Connect for distributed authorization, a flexible Token Service is a necessity.

SCIM is a standardized REST-based protocol for cross-domain user management, making it easier and faster to centralize user management. SCIM enables developers to integrate and use CRUD capabilities for user management quickly and seamlessly across many different types of data sources without using several different protocols.

Curity’s User Management Service provides support for any database. The User Management Service has been implemented and verified for many data sources, find out more here.