Co-Auth: Documentation
WebsiteDocumentaionGithub
  • 🏠Welcome to Co-Auth Documentation
  • Getting Started
    • Co-Auth Modules & Release Status
      • Time Based OTP
      • Reconfirm
    • Architecture
      • Components Flow
      • Integration Overview
        • Integration with Co-Auth
      • Tech Stack
    • Requirements & Prerequisites
    • Installation
      • Setup as a Test / Dev environment
        • Test Setup on Red Hat OpenShift
        • Test Setup on Kubernetes
        • Cloud Provider
        • Development Setup
      • Setup on Production
  • using COAUTH
    • 🕐Key Concepts
  • API
    • 🕐Overview
    • 🕐API Documentation
  • Advanced Topics
    • Customization
      • Database
      • 🕐Caching
      • Good to Have
  • contribute to CoAuth
    • Contribute
    • Setup a Build Environment
  • Usecases
    • 🙂Articles
    • Implementation Use Case
      • 🕐2nd Factor for Authentication
      • 🕐Securing Internal Pages
      • 🕐Transaction verification
      • 🕐Safeguard from MTM, Keystroke attacks
      • 🕐QR are not just for Login
  • administration
    • 🕐Coming Soon
  • Group 1
    • Behind the Scenes
      • Sponsors
      • Adopters
      • Core Contributors
Powered by GitBook
On this page

Was this helpful?

Welcome to Co-Auth Documentation

A brief introduction on Co-Auth and the philosophy behind it

Authentication can protects you by allowing only those authorized to access. But not during the session which lasts for 15-30 mins on most applications.

Moreover, If the applications are intranet based, then for the life time of logged-in session

Our Philosophy

Why we think Co-Auth should be part of your software ecosystem

Is SSO, SAML, Oauth, OpenID enough?

While these protect you with authentication, post authentication they don't affirm on certain sensitive actions. And thus everyone, instead ends up building their own x factor verification / authorization like OTP, Security questions, TOTP, etc.

Pretending, we don't share our passwords? What about screens / logged-in session?

While this is a policy, its unfortunate that we knowingly/unknowingly allow access to authenticated systems to people around us (even riskier with work from home/ anywhere). Even worst with SSO you are always logged in.

Your authorization factors should be Separate Systems?

If your core application hosting passwords were compromised. This layer separation provides added protection, by keeping it separate

Don't re-implement

If you have more than one application that authorization, why build again, when you can reuse from a centrally hosted application.

Leave it to the experts

Best practices are important. Not just a functioning module. Choose a solution which would be widely adopted built by community. (once Co-Auth is in production mode)

Bad user experience
Pluggable / Configurable

Switch the auth module if needed without having to rewrite the whole logic. e.x. Why not allow to access codes over mobile app instead of SMS / Email / a TOTP during an international travel?

Simple, modern but also secure Auth

Co-Auth modules can also be used for simple login authentication like QR Login or Whatsapp Login

NextCo-Auth Modules & Release Status

Last updated 1 year ago

Was this helpful?

Choosing a authorization modules for multiple applications for your end users is the ideal way. However, Co-Auth allows you both options.

🏠
😄