• Core
  • Databases

Databases

Supported Databases

  • Postgres

    Sample connection string: postgres://username:password@localhost:5432/postgres

  • Yugabyte

    Sample connection string: postgres://username:password@localhost:5432/postgres

  • CockroachDB

    Sample connection string: postgres://username:password@localhost:5432/postgres

  • MySQL

    Sample connection string: username:password@tcp(localhost:port)/database_name

  • PlanetScale

    Sample connection string: username:password@tcp(localhost:port)/database_name

  • MariaDB

    Sample connection string: username:password@tcp(localhost:port)/database_name

  • SQLite

    Sample connection string: test.db

  • SQLServer

    Sample connection string: sqlserver://gorm:LoremIpsum86@localhost:9930?database=gorm"

  • MongoDB

    Sample connection string: mongodb://localhost:27017

  • ArangoDB

    Sample connection string: https://root:password@localhost.arangodb.cloud:8529

  • CassandraDB

    Sample config

      DATABASE_TYPE=cassandradb
      DATABASE_HOST="db connection string"
      DATABASE_USERNAME="test"
      DATABASE_PASSWORD="*********"
      DATABASE_CERT="Base64 encoded cert string"
      DATABASE_CERT_KEY="Base64 encoded cert key"
      DATABASE_CA_CERT="Base64 encoded CA cert"

    Note for CassandraDB: If you are using cloud provider like DataStax, they don't allow creating keyspace. So please make sure you have keyspace named authorizer created from their GUI.

  • ScyllaDB

    Sample config

      DATABASE_TYPE=scylladb
      DATABASE_HOST="192.168.0.1,192.168.0.2,192.168.0.3"
      DATABASE_USERNAME="scylladb"
      DATABASE_PASSWORD="*********"

Note: New environment variable is introduced - DATABASE_NAME: as database name, is not part of connection URL in case of arangodb and mongodb.

  • DynamoDB

    Sample Config

    DATABASE_TYPE=dynamodb
    AWS_REGION=ap-south-1
    AWS_ACCESS_KEY_ID=YOUR_ACCESS_KEY
    AWS_SECRET_ACCESS_KEY=YOUR_SECRET

Tables / collections created and used by Authorizer

  • authorizer_users - store the basic user information
  • authorizer_verification_requests - store the email verification / forgot password verification requests
  • authorizer_sessions - store the user sessions generated

Data Store used for Authorization

With each user request, for which we want to make sure that user is making request with correct permissions, we need to validate HTTP Cookie / Authorization Header. JWT tokens send via request headers can still be manipulated, so in order authorize user we should not only validate JWT but validate them against the long living token stored on server. To improve the throughput/response time for each request we need to make sure that authorization doesn't take long time to resolve. Hence we need in-memory store.

Currently, Authorizer Supports two in-memory stores

  • Redis - persisted as long as a Redis server is on / user logs out.
  • In-memory - stores in the memory of the current machine. Not recommended for production as machine memory might be less. Also, data it saves data till the system stops / restarts.
Last updated on October 21, 2022