
European Identity and Access Management
FoxIDs is an Identity Services that easily allows you to implement Identity and Access Management (IAM) on your websites and APIs against a variety of industry standards (OAuth 2.0, OpenID Connect and SAML 2.0) and services like Microsoft, Google and Facebook, etc.
Use FoxIDs cloud or Host it yourself anywhere using Docker or Kubernetes (K8s).




















The European alternative to
Digital Sovereignty
As a company based in Denmark, we strictly adhere to the regulations imposed by GDPR. FoxIDs is 100% Made in Europa and fully GDPR compliant. Your data is hosted exclusively in EU, so you always retain full control.
Connect and Orchestrate your Identity and Access

Separation
Each environment is a separate configuration with a unique user database. You can use the same configuration names across environments.
Unique identity
Each environment has its own certificate and each environment acts as an Identity Provider (IdP). The environments automatically handle certificate rotation or you can upload your own certificate.
Divide with environments
Split your identity configuration into different environments, such as separating external connections or customers. You can then provide a user database per customer and optionally connect environments.
Customizable login dialog
Customize the login dialog to suit your needs. There is built-in multiple language support, where the text and translations can be adjusted per environment.
OpenID Connect, SAML 2.0 and SSO
Create external connections with OpenID Connect and SAML 2.0 authentication methods. Configure social and corporate logins.
Existing user database
Authenticate users in your existing user database, linked with a simple API.
Multi-factor authentication
Require multi-factor authentication – MFA/2FA at different levels. Require MFA in the applications login request and check it after successful authentication.
Test authentication methods
Each authentication method can be easily tested with one click and a test link is generated that can be copied.
Users
The user database in an environment can contain an infinite number of users. Each user can have one or more of the three user identifiers; email, phone number and username.
Two-factor
Two-factor authentication with SMS, email and authenticator app.
Internal and external users
Support for both internal users in the environment and optionally external users. Both user types can be provisioned. The external users can be created or redeemed (e.g. by email) during login and the user can be asked to enter a name, for example.
Claims
All user data is processed as claims. Add information to users as claims. Authorize users with role claims or a more complex claim structure.
Transform claims
Change revived claims and add claims in claim transformations at different levels. Add/replace/remove/concatenate claims stored on a user, received claims or claims defined in a claim transformation step.
Claim tasks
Use claim tasks to query internal and external users, return an error or start a new authentication flow based on claims.
OpenID Connect or SAML 2.0
Add your application with OpenID Connect (OIDC) or SAML 2.0. Adapt the configuration to suit your application. Support for both login, SSO, logout and single-logout.
Authentication methods
The allowed authentication methods are configured for an application. A subset can be selected in the login call from the application. The user can select an authentication method of more then one is active.
OAuth 2.0 - API
Add you API with OAuth 2.0 and define scope to restrict access. You application and API can be configured as one application and a general API can be configured separately.
SAML 2.0 / OpenID Connect bridge
Configure you application with OpenID Connect and add an external SAML 2.0 Identity Provider (IdP) as an authentication method. Then you have a bridge between the two standards.
Token exchange
Exchange tokens from JWT to JWT or from SAML 2.0 tokens to JWT. Use tokens with least privileges an only valid for one API. Perform token exchange to call another API and thereby restrict who can call an API.One hour free support!
Request free online support with an expert. We get you started and can setup applications and authentication methods in FoxIDs together.
Why did we develop FoxIDs?
An identity service should include all necessary features to make secure applications and APIs and yet be affordable.
The source code for the full feature set should be available.
The identity service should support both cloud and on-premises deployment and be available on FoxIDs cloud
with close to full feature set in all plans at a low cost.
Features and functions
A look at what's possible with FoxIDs
One single Identity Provider
You can benefit from having FoxIDs as one single identity provider when building applications. Development becomes simpler and more secure by using the same identity provider and security standards across all applications. Single sign-on is easier to achieve and APIs can be called securely from all applications.
FoxIDs will then handle user authentication with username+password and optionally MFA or transfer user ID's from users authenticated in an external identity provider such as Microsoft Entra ID (Azure AD), AD FS, IdentityServer, Google or Facebook or others supporting OpenID Connect or SAML 2.0.
The application can choose how the user should log in by setting a authentication method as a parameter in the URL.
OpenID Connect and SAML 2.0 applications
It is a common scenario to have OpenID Connect and SAML 2.0 applications in a enterprise architecture. You can connect both OpenID Connect and SAML 2.0 applications to FoxIDs and configure shared or separate login experiences.
Both single sign-on (SSO) and single logout is supported across different types of applications. And if a SAML 2.0 application needs to call an OAuth 2.0 secured API the SAML 2.0 token can be exchanged to an access token for the API.
Token Exchange
Tokens should be issued with lease privileges. If an application needs to call multiple APIs or API groups it is a good and secure approach to issue a separate access token for each API or API group. Use zero trust (never trust, always verify), validate that each API request is authenticated and authorized in context of the calling client and the end-user.
Initially a limited access token is issued which is granted access (with audience and scope) to be exchanged with token exchange to different API / API group access tokens with specific audiences and scopes.
The initial access token can be issued on user authentication in an OpenID Connect application or with client credentials grant in an OAuth 2.0 application.
And thereafter be exchanged to other access tokens.
It is recommended to pass the user's identity securely between APIs. With token exchange in an API, it is possible to issue an access token to another API and thereby calling the next API in the context of the end-user.
SAML 2.0 to OpenID Connect bridge
You can use FoxIDs as a SAML 2.0 to OpenID Connect bridge. Where FoxIDs handles the SAML 2.0 traffic to the external Identity Provider (IdP) and your application connects to FoxIDs with OpenID Connect. You basically only need care about OpenID Connect, the SAML 2.0 connection is handled by FoxIDs.
SAML 2.0 is tricky and an old standard with its shortcomings, and therefore it is often a better choice to use OpenID Connect in your application.
NemLog-in or Context Handler to OpenID Connect bridge
You can connect FoxIDs to NemLog-in (Danish IdP) or Context Handler (Danish identity broker, Fælleskommunal Adgangsstyring) without worrying about the complexity. FoxIDs handles everything related to the OIOSAML3 / SAML 2.0 connection and translate to OpenID Connect. The Danish privilege claim with a base64-decoded XML value can also be transfers to a claim with a readable JSON value.
Your application and possible API is then to connect to FoxIDs with OpenID Connect and OAuth 2.0, and the developer doesn't have to worry much about NemLog-in or Context Handler and all the requirements.