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?

  1. Getting Started

Architecture

A detailed architecture of components

PreviousReconfirmNextComponents Flow

Last updated 1 year ago

Was this helpful?

Component
Responsibility

API Gateway

Routing to all Co-Auth resources takes place throught this gateway. Injecting application details by calling auth guard service

Auth Guard

A microservice acting as filter called for API keys validation. it is also responsible for providing app details to down stream services

Module Registry

This microservice is responsible to act as first level initiator, if a user for an application is registered for the type of requested auth. It also holds the status of completion

module-*

These are microservices segregated based on the type of auth method they handle

postgres

The relational database to maintain the application data. By design no database level relations are maintained which further allows microservices to run their own database in future

Infinispan

Used to store in memory on cluster data, so that pods can share the data and avoid making DB calls, as they scale up and down

web-plugin

Vuejs based web plugin that can be embedded by thrid party applications within a iframe. Used in self-onboarding and verification sections.

Management UI

A Mock UI concept based on Vuejs to idea the features in the administration panel.

Kafka / AMQ

  1. Log all transactions and activities to Kafka which can be used to send notifications to users of actions (coming soon)

Kafka sinks / consumers

For complex applications we will have Quarkus serverless implementation of consumers and for others we have the Kamelets sinks which provide out of the box integration