Alternatives to Firebase Authentication logo

Alternatives to Firebase Authentication

Auth0, MongoDB, Passport, Okta, and Firebase are the most popular alternatives and competitors to Firebase Authentication.
422
502
+ 1
52

What is Firebase Authentication and what are its top alternatives?

It provides backend services, easy-to-use SDKs, and ready-made UI libraries to authenticate users to your app. It supports authentication using passwords, phone numbers, popular federated identity providers like Google,
Firebase Authentication is a tool in the User Management and Authentication category of a tech stack.

Top Alternatives to Firebase Authentication

  • Auth0
    Auth0

    A set of unified APIs and tools that instantly enables Single Sign On and user management to all your applications. ...

  • MongoDB
    MongoDB

    MongoDB stores data in JSON-like documents that can vary in structure, offering a dynamic, flexible schema. MongoDB was also designed for high availability and scalability, with built-in replication and auto-sharding. ...

  • Passport
    Passport

    It is authentication middleware for Node.js. Extremely flexible and modular, It can be unobtrusively dropped in to any Express-based web application. A comprehensive set of strategies support authentication using a username and password, Facebook, Twitter, and more. ...

  • Okta
    Okta

    Connect all your apps in days, not months, with instant access to thousands of pre-built integrations - even add apps to the network yourself. Integrations are easy to set up, constantly monitored, proactively repaired and handle authentication and provisioning. ...

  • Firebase
    Firebase

    Firebase is a cloud service designed to power real-time, collaborative applications. Simply add the Firebase library to your application to gain access to a shared data structure; any changes you make to that data are automatically synchronized with the Firebase cloud and with other clients within milliseconds. ...

  • JSON Web Token
    JSON Web Token

    JSON Web Token is an open standard that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. ...

  • Amazon Cognito
    Amazon Cognito

    You can create unique identities for your users through a number of public login providers (Amazon, Facebook, and Google) and also support unauthenticated guests. You can save app data locally on users’ devices allowing your applications to work even when the devices are offline. ...

  • Keycloak
    Keycloak

    It is an Open Source Identity and Access Management For Modern Applications and Services. It adds authentication to applications and secure services with minimum fuss. No need to deal with storing users or authenticating users. It's all available out of the box. ...

Firebase Authentication alternatives & related posts

Auth0 logo

Auth0

1.1K
1.8K
213
Token-based Single Sign On for your Apps and APIs with social, databases and enterprise identities
1.1K
1.8K
+ 1
213
PROS OF AUTH0
  • 67
    JSON web token
  • 31
    Integration with 20+ Social Providers
  • 20
    It's a universal solution
  • 20
    SDKs
  • 14
    Amazing Documentation
  • 11
    Heroku Add-on
  • 8
    Enterprise support
  • 7
    Great Sample Repos
  • 7
    Extend platform with "rules"
  • 4
    Azure Add-on
  • 3
    Easy integration, non-intrusive identity provider
  • 3
    Passwordless
  • 2
    It can integrate seamlessly with firebase
  • 2
    Ruby
  • 2
    Great documentation, samples, UX and Angular support
  • 2
    Polished
  • 2
    On-premise deployment
  • 1
    SAML Support
  • 1
    Will sign BAA for HIPAA-compliance
  • 1
    OpenID Connect (OIDC) Support
  • 1
    Active Directory support
  • 1
    MFA
  • 1
    SOC2
  • 1
    Great support
  • 1
    Springboot
  • 0
    A';P[];Æ`/
CONS OF AUTH0
  • 14
    Pricing too high (Developer Pro)
  • 7
    Poor support
  • 4
    Status page not reflect actual status
  • 3
    Rapidly changing API

related Auth0 posts

Stephen Gheysens
Senior Solutions Engineer at Twilio · | 14 upvotes · 615.9K views

Hi Otensia! I'd definitely recommend using the skills you've already got and building with JavaScript is a smart way to go these days. Most platform services have JavaScript/Node SDKs or NPM packages, many serverless platforms support Node in case you need to write any backend logic, and JavaScript is incredibly popular - meaning it will be easy to hire for, should you ever need to.

My advice would be "don't reinvent the wheel". If you already have a skill set that will work well to solve the problem at hand, and you don't need it for any other projects, don't spend the time jumping into a new language. If you're looking for an excuse to learn something new, it would be better to invest that time in learning a new platform/tool that compliments your knowledge of JavaScript. For this project, I might recommend using Netlify, Vercel, or Google Firebase to quickly and easily deploy your web app. If you need to add user authentication, there are great examples out there for Firebase Authentication, Auth0, or even Magic (a newcomer on the Auth scene, but very user friendly). All of these services work very well with a JavaScript-based application.

See more

Hey all, We're currently weighing up the pros & cons of using Firebase Authentication vs something more OTB like Auth0 or Okta to manage end-user access management for a consumer digital content product. From what I understand so far, Something like Firebase Auth would require more dev effort but is likely to cost less overall, whereas OTB, you have a UI-based console which makes config by non-technical business users easier to manage. Does anyone else have any intuitions or experiences they could share on this, please? Thank you!

See more
MongoDB logo

MongoDB

72.3K
61.3K
4.1K
The database for giant ideas
72.3K
61.3K
+ 1
4.1K
PROS OF MONGODB
  • 828
    Document-oriented storage
  • 593
    No sql
  • 549
    Ease of use
  • 465
    Fast
  • 408
    High performance
  • 256
    Free
  • 215
    Open source
  • 180
    Flexible
  • 143
    Replication & high availability
  • 110
    Easy to maintain
  • 42
    Querying
  • 38
    Easy scalability
  • 37
    Auto-sharding
  • 36
    High availability
  • 31
    Map/reduce
  • 27
    Document database
  • 25
    Full index support
  • 25
    Easy setup
  • 16
    Reliable
  • 15
    Fast in-place updates
  • 14
    Agile programming, flexible, fast
  • 12
    No database migrations
  • 8
    Easy integration with Node.Js
  • 8
    Enterprise
  • 6
    Enterprise Support
  • 5
    Great NoSQL DB
  • 3
    Drivers support is good
  • 3
    Aggregation Framework
  • 3
    Support for many languages through different drivers
  • 2
    Awesome
  • 2
    Schemaless
  • 2
    Managed service
  • 2
    Fast
  • 2
    Easy to Scale
  • 1
    Consistent
  • 1
    Acid Compliant
CONS OF MONGODB
  • 6
    Very slowly for connected models that require joins
  • 3
    Not acid compliant
  • 1
    Proprietary query language

related MongoDB posts

Jeyabalaji Subramanian

Recently we were looking at a few robust and cost-effective ways of replicating the data that resides in our production MongoDB to a PostgreSQL database for data warehousing and business intelligence.

We set ourselves the following criteria for the optimal tool that would do this job: - The data replication must be near real-time, yet it should NOT impact the production database - The data replication must be horizontally scalable (based on the load), asynchronous & crash-resilient

Based on the above criteria, we selected the following tools to perform the end to end data replication:

We chose MongoDB Stitch for picking up the changes in the source database. It is the serverless platform from MongoDB. One of the services offered by MongoDB Stitch is Stitch Triggers. Using stitch triggers, you can execute a serverless function (in Node.js) in real time in response to changes in the database. When there are a lot of database changes, Stitch automatically "feeds forward" these changes through an asynchronous queue.

We chose Amazon SQS as the pipe / message backbone for communicating the changes from MongoDB to our own replication service. Interestingly enough, MongoDB stitch offers integration with AWS services.

In the Node.js function, we wrote minimal functionality to communicate the database changes (insert / update / delete / replace) to Amazon SQS.

Next we wrote a minimal micro-service in Python to listen to the message events on SQS, pickup the data payload & mirror the DB changes on to the target Data warehouse. We implemented source data to target data translation by modelling target table structures through SQLAlchemy . We deployed this micro-service as AWS Lambda with Zappa. With Zappa, deploying your services as event-driven & horizontally scalable Lambda service is dumb-easy.

In the end, we got to implement a highly scalable near realtime Change Data Replication service that "works" and deployed to production in a matter of few days!

See more
Robert Zuber

We use MongoDB as our primary #datastore. Mongo's approach to replica sets enables some fantastic patterns for operations like maintenance, backups, and #ETL.

As we pull #microservices from our #monolith, we are taking the opportunity to build them with their own datastores using PostgreSQL. We also use Redis to cache data we’d never store permanently, and to rate-limit our requests to partners’ APIs (like GitHub).

When we’re dealing with large blobs of immutable data (logs, artifacts, and test results), we store them in Amazon S3. We handle any side-effects of S3’s eventual consistency model within our own code. This ensures that we deal with user requests correctly while writes are in process.

See more
Passport logo

Passport

215
301
0
Simple, unobtrusive authentication for Node.js
215
301
+ 1
0
PROS OF PASSPORT
    Be the first to leave a pro
    CONS OF PASSPORT
      Be the first to leave a con

      related Passport posts

      Repost

      Overview: To put it simply, we plan to use the MERN stack to build our web application. MongoDB will be used as our primary database. We will use ExpressJS alongside Node.js to set up our API endpoints. Additionally, we plan to use React to build our SPA on the client side and use Redis on the server side as our primary caching solution. Initially, while working on the project, we plan to deploy our server and client both on Heroku . However, Heroku is very limited and we will need the benefits of an Infrastructure as a Service so we will use Amazon EC2 to later deploy our final version of the application.

      Serverside: nodemon will allow us to automatically restart a running instance of our node app when files changes take place. We decided to use MongoDB because it is a non relational database which uses the Document Object Model. This allows a lot of flexibility as compared to a RDMS like SQL which requires a very structural model of data that does not change too much. Another strength of MongoDB is its ease in scalability. We will use Mongoose along side MongoDB to model our application data. Additionally, we will host our MongoDB cluster remotely on MongoDB Atlas. Bcrypt will be used to encrypt user passwords that will be stored in the DB. This is to avoid the risks of storing plain text passwords. Moreover, we will use Cloudinary to store images uploaded by the user. We will also use the Twilio SendGrid API to enable automated emails sent by our application. To protect private API endpoints, we will use JSON Web Token and Passport. Also, PayPal will be used as a payment gateway to accept payments from users.

      Client Side: As mentioned earlier, we will use React to build our SPA. React uses a virtual DOM which is very efficient in rendering a page. Also React will allow us to reuse components. Furthermore, it is very popular and there is a large community that uses React so it can be helpful if we run into issues. We also plan to make a cross platform mobile application later and using React will allow us to reuse a lot of our code with React Native. Redux will be used to manage state. Redux works great with React and will help us manage a global state in the app and avoid the complications of each component having its own state. Additionally, we will use Bootstrap components and custom CSS to style our app.

      Other: Git will be used for version control. During the later stages of our project, we will use Google Analytics to collect useful data regarding user interactions. Moreover, Slack will be our primary communication tool. Also, we will use Visual Studio Code as our primary code editor because it is very light weight and has a wide variety of extensions that will boost productivity. Postman will be used to interact with and debug our API endpoints.

      See more

      Overview: To put it simply, we plan to use the MERN stack to build our web application. MongoDB will be used as our primary database. We will use ExpressJS alongside Node.js to set up our API endpoints. Additionally, we plan to use React to build our SPA on the client side and use Redis on the server side as our primary caching solution. Initially, while working on the project, we plan to deploy our server and client both on Heroku. However, Heroku is very limited and we will need the benefits of an Infrastructure as a Service so we will use Amazon EC2 to later deploy our final version of the application.

      Serverside: nodemon will allow us to automatically restart a running instance of our node app when files changes take place. We decided to use MongoDB because it is a non relational database which uses the Document Object Model. This allows a lot of flexibility as compared to a RDMS like SQL which requires a very structural model of data that does not change too much. Another strength of MongoDB is its ease in scalability. We will use Mongoose along side MongoDB to model our application data. Additionally, we will host our MongoDB cluster remotely on MongoDB Atlas. Bcrypt will be used to encrypt user passwords that will be stored in the DB. This is to avoid the risks of storing plain text passwords. Moreover, we will use Cloudinary to store images uploaded by the user. We will also use the Twilio SendGrid API to enable automated emails sent by our application. To protect private API endpoints, we will use JSON Web Token and Passport. Also, PayPal will be used as a payment gateway to accept payments from users.

      Client Side: As mentioned earlier, we will use React to build our SPA. React uses a virtual DOM which is very efficient in rendering a page. Also React will allow us to reuse components. Furthermore, it is very popular and there is a large community that uses React so it can be helpful if we run into issues. We also plan to make a cross platform mobile application later and using React will allow us to reuse a lot of our code with React Native. Redux will be used to manage state. Redux works great with React and will help us manage a global state in the app and avoid the complications of each component having its own state. Additionally, we will use Bootstrap components and custom CSS to style our app.

      Other: Git will be used for version control. During the later stages of our project, we will use Google Analytics to collect useful data regarding user interactions. Moreover, Slack will be our primary communication tool. Also, we will use Visual Studio Code as our primary code editor because it is very light weight and has a wide variety of extensions that will boost productivity. Postman will be used to interact with and debug our API endpoints.

      See more
      Okta logo

      Okta

      333
      711
      59
      Enterprise-grade identity management for all your apps, users & devices
      333
      711
      + 1
      59
      PROS OF OKTA
      • 12
        REST API
      • 9
        SAML
      • 5
        OIDC OpenID Connect
      • 5
        User Provisioning
      • 5
        Easy LDAP integration
      • 4
        API Access Management - oAuth2 as a service
      • 4
        Universal Directory
      • 4
        Protect B2E, B2B, B2C apps
      • 3
        SSO, MFA for cloud, on-prem, custom apps
      • 3
        Easy Active Directory integration
      • 3
        Tons of Identity Management features
      • 1
        SWA applications Integration
      • 1
        SOC2
      CONS OF OKTA
      • 4
        Pricing is too high
      • 1
        Okta verify (Multi-factor Authentication)

      related Okta posts

      Hey all, We're currently weighing up the pros & cons of using Firebase Authentication vs something more OTB like Auth0 or Okta to manage end-user access management for a consumer digital content product. From what I understand so far, Something like Firebase Auth would require more dev effort but is likely to cost less overall, whereas OTB, you have a UI-based console which makes config by non-technical business users easier to manage. Does anyone else have any intuitions or experiences they could share on this, please? Thank you!

      See more
      Firebase logo

      Firebase

      31.7K
      27.1K
      1.9K
      The Realtime App Platform
      31.7K
      27.1K
      + 1
      1.9K
      PROS OF FIREBASE
      • 367
        Realtime backend made easy
      • 268
        Fast and responsive
      • 239
        Easy setup
      • 212
        Real-time
      • 188
        JSON
      • 132
        Free
      • 126
        Backed by google
      • 82
        Angular adaptor
      • 67
        Reliable
      • 35
        Great customer support
      • 30
        Great documentation
      • 25
        Real-time synchronization
      • 21
        Mobile friendly
      • 18
        Rapid prototyping
      • 14
        Great security
      • 12
        Automatic scaling
      • 11
        Freakingly awesome
      • 8
        Chat
      • 8
        Angularfire is an amazing addition!
      • 8
        Super fast development
      • 6
        Ios adaptor
      • 6
        Firebase hosting
      • 6
        Awesome next-gen backend
      • 6
        Built in user auth/oauth
      • 4
        Speed of light
      • 4
        Very easy to use
      • 3
        Brilliant for startups
      • 3
        Great
      • 3
        It's made development super fast
      • 2
        Low battery consumption
      • 2
        Free hosting
      • 2
        Cloud functions
      • 2
        Push notification
      • 2
        JS Offline and Sync suport
      • 2
        Free authentication solution
      • 2
        The concurrent updates create a great experience
      • 2
        I can quickly create static web apps with no backend
      • 2
        Great all-round functionality
      • 1
        Easy Reactjs integration
      • 1
        Easy to use
      • 1
        Free SSL
      • 1
        CDN & cache out of the box
      • 1
        Faster workflow
      • 1
        Google's support
      • 1
        .net
      • 1
        Serverless
      • 1
        Good Free Limits
      • 1
        Large
      CONS OF FIREBASE
      • 31
        Can become expensive
      • 15
        No open source, you depend on external company
      • 15
        Scalability is not infinite
      • 9
        Not Flexible Enough
      • 6
        Cant filter queries
      • 3
        No Relational Data
      • 3
        Very unstable server
      • 2
        No offline sync
      • 2
        Too many errors

      related Firebase posts

      Stephen Gheysens
      Senior Solutions Engineer at Twilio · | 14 upvotes · 615.9K views

      Hi Otensia! I'd definitely recommend using the skills you've already got and building with JavaScript is a smart way to go these days. Most platform services have JavaScript/Node SDKs or NPM packages, many serverless platforms support Node in case you need to write any backend logic, and JavaScript is incredibly popular - meaning it will be easy to hire for, should you ever need to.

      My advice would be "don't reinvent the wheel". If you already have a skill set that will work well to solve the problem at hand, and you don't need it for any other projects, don't spend the time jumping into a new language. If you're looking for an excuse to learn something new, it would be better to invest that time in learning a new platform/tool that compliments your knowledge of JavaScript. For this project, I might recommend using Netlify, Vercel, or Google Firebase to quickly and easily deploy your web app. If you need to add user authentication, there are great examples out there for Firebase Authentication, Auth0, or even Magic (a newcomer on the Auth scene, but very user friendly). All of these services work very well with a JavaScript-based application.

      See more
      Tassanai Singprom

      This is my stack in Application & Data

      JavaScript PHP HTML5 jQuery Redis Amazon EC2 Ubuntu Sass Vue.js Firebase Laravel Lumen Amazon RDS GraphQL MariaDB

      My Utilities Tools

      Google Analytics Postman Elasticsearch

      My Devops Tools

      Git GitHub GitLab npm Visual Studio Code Kibana Sentry BrowserStack

      My Business Tools

      Slack

      See more
      JSON Web Token logo

      JSON Web Token

      879
      245
      0
      A JSON-based open standard for creating access tokens
      879
      245
      + 1
      0
      PROS OF JSON WEB TOKEN
        Be the first to leave a pro
        CONS OF JSON WEB TOKEN
          Be the first to leave a con

          related JSON Web Token posts

          Repost

          Overview: To put it simply, we plan to use the MERN stack to build our web application. MongoDB will be used as our primary database. We will use ExpressJS alongside Node.js to set up our API endpoints. Additionally, we plan to use React to build our SPA on the client side and use Redis on the server side as our primary caching solution. Initially, while working on the project, we plan to deploy our server and client both on Heroku . However, Heroku is very limited and we will need the benefits of an Infrastructure as a Service so we will use Amazon EC2 to later deploy our final version of the application.

          Serverside: nodemon will allow us to automatically restart a running instance of our node app when files changes take place. We decided to use MongoDB because it is a non relational database which uses the Document Object Model. This allows a lot of flexibility as compared to a RDMS like SQL which requires a very structural model of data that does not change too much. Another strength of MongoDB is its ease in scalability. We will use Mongoose along side MongoDB to model our application data. Additionally, we will host our MongoDB cluster remotely on MongoDB Atlas. Bcrypt will be used to encrypt user passwords that will be stored in the DB. This is to avoid the risks of storing plain text passwords. Moreover, we will use Cloudinary to store images uploaded by the user. We will also use the Twilio SendGrid API to enable automated emails sent by our application. To protect private API endpoints, we will use JSON Web Token and Passport. Also, PayPal will be used as a payment gateway to accept payments from users.

          Client Side: As mentioned earlier, we will use React to build our SPA. React uses a virtual DOM which is very efficient in rendering a page. Also React will allow us to reuse components. Furthermore, it is very popular and there is a large community that uses React so it can be helpful if we run into issues. We also plan to make a cross platform mobile application later and using React will allow us to reuse a lot of our code with React Native. Redux will be used to manage state. Redux works great with React and will help us manage a global state in the app and avoid the complications of each component having its own state. Additionally, we will use Bootstrap components and custom CSS to style our app.

          Other: Git will be used for version control. During the later stages of our project, we will use Google Analytics to collect useful data regarding user interactions. Moreover, Slack will be our primary communication tool. Also, we will use Visual Studio Code as our primary code editor because it is very light weight and has a wide variety of extensions that will boost productivity. Postman will be used to interact with and debug our API endpoints.

          See more

          Overview: To put it simply, we plan to use the MERN stack to build our web application. MongoDB will be used as our primary database. We will use ExpressJS alongside Node.js to set up our API endpoints. Additionally, we plan to use React to build our SPA on the client side and use Redis on the server side as our primary caching solution. Initially, while working on the project, we plan to deploy our server and client both on Heroku. However, Heroku is very limited and we will need the benefits of an Infrastructure as a Service so we will use Amazon EC2 to later deploy our final version of the application.

          Serverside: nodemon will allow us to automatically restart a running instance of our node app when files changes take place. We decided to use MongoDB because it is a non relational database which uses the Document Object Model. This allows a lot of flexibility as compared to a RDMS like SQL which requires a very structural model of data that does not change too much. Another strength of MongoDB is its ease in scalability. We will use Mongoose along side MongoDB to model our application data. Additionally, we will host our MongoDB cluster remotely on MongoDB Atlas. Bcrypt will be used to encrypt user passwords that will be stored in the DB. This is to avoid the risks of storing plain text passwords. Moreover, we will use Cloudinary to store images uploaded by the user. We will also use the Twilio SendGrid API to enable automated emails sent by our application. To protect private API endpoints, we will use JSON Web Token and Passport. Also, PayPal will be used as a payment gateway to accept payments from users.

          Client Side: As mentioned earlier, we will use React to build our SPA. React uses a virtual DOM which is very efficient in rendering a page. Also React will allow us to reuse components. Furthermore, it is very popular and there is a large community that uses React so it can be helpful if we run into issues. We also plan to make a cross platform mobile application later and using React will allow us to reuse a lot of our code with React Native. Redux will be used to manage state. Redux works great with React and will help us manage a global state in the app and avoid the complications of each component having its own state. Additionally, we will use Bootstrap components and custom CSS to style our app.

          Other: Git will be used for version control. During the later stages of our project, we will use Google Analytics to collect useful data regarding user interactions. Moreover, Slack will be our primary communication tool. Also, we will use Visual Studio Code as our primary code editor because it is very light weight and has a wide variety of extensions that will boost productivity. Postman will be used to interact with and debug our API endpoints.

          See more
          Amazon Cognito logo

          Amazon Cognito

          520
          781
          33
          Securely manage and synchronize app data for your users across their mobile devices
          520
          781
          + 1
          33
          PROS OF AMAZON COGNITO
          • 14
            Backed by Amazon
          • 7
            Manage Unique Identities
          • 3
            Work Offline
          • 3
            MFA
          • 2
            Store and Sync
          • 1
            It works
          • 1
            Integrate with Google, Amazon, Twitter, Facebook, SAML
          • 1
            SDKs and code samples
          • 1
            Free for first 50000 users
          CONS OF AMAZON COGNITO
          • 3
            Massive Pain to get working
          • 2
            Login-UI sparsely customizable (e.g. no translation)
          • 2
            Documentation often out of date
          • 1
            MFA: there is no "forget device" function
          • 1
            Hard to find expiration times for tokens/codes
          • 1
            Lacks many basic features
          • 1
            There is no "Logout" method in the API
          • 1
            No recovery codes for MFA
          • 1
            Difficult to customize (basic-pack is more than humble)
          • 1
            Only paid support
          • 1
            Docs are vast but mostly useless

          related Amazon Cognito posts

          I'm starting a new React Native project and trying to decide on an auth provider. Currently looking at Auth0 and Amazon Cognito. It will need to play nice with a Django Rest Framework backend.

          See more
          Keycloak logo

          Keycloak

          507
          970
          71
          An open source identity and access management solution
          507
          970
          + 1
          71
          PROS OF KEYCLOAK
          • 26
            It's a open source solution
          • 19
            Supports multiple identity provider
          • 12
            OpenID and SAML support
          • 7
            Easy customisation
          • 6
            JSON web token
          • 1
            Maintained by devs at Redhat
          CONS OF KEYCLOAK
          • 4
            Okta
          • 3
            Poor client side documentation
          • 3
            Lack of Code examples for client side

          related Keycloak posts

          Joshua Dean Küpper
          CEO at Scrayos UG (haftungsbeschränkt) · | 7 upvotes · 410.3K views

          As the access to our global REST-API "Charon" is bound to OAuth2, we use Keycloak inside Quarkus to authenticate and authorize users of our API. It is not possible to perform any un-authenticated requests against this API, so we wanted to make really sure that the authentication/authorization component is absolutely reliable and tested. We found those attributes within Keycloak, so we used it.

          See more
          Shared insights
          on
          OktaOktaKeycloakKeycloak

          I want some good advice on which one I should prefer. (Keycloak or Okta) Since Keycloak is open source, it will be our first preference, but do we face some limitations with this approach? And since our product is SAAS based and we support the following authentications at present. 1. AT DB level 2. 3rd part IDP providers 3. LDAP/AD...

          See more