What is Better Auth?

Better Auth is a modern, open-source authentication and authorization framework designed for the TypeScript ecosystem. It provides a comprehensive set of features out of the box, including support for email/password authentication, social sign-on (OAuth), two-factor authentication (2FA), multi-tenancy, and more. Better Auth is framework-agnostic, meaning it can be integrated into various TypeScript-based frameworks such as Next.js, SvelteKit, Astro, and TanStack Start .

The primary goal of Better Auth is to simplify the implementation of authentication systems by offering a robust, extensible, and type-safe solution. It allows developers to focus on building their applications without reinventing the wheel when it comes to user authentication and authorization.

Major Use Cases of Better Auth

1. Secure User Authentication: Implement secure login mechanisms using email/password, social logins (Google, GitHub, Apple, Discord), and more.
2. Two-Factor Authentication (2FA): Enhance security by adding an additional layer of authentication, such as SMS or authenticator apps.
3. Multi-Tenant Applications: Manage organizations, teams, and access control for applications that serve multiple clients or user groups.
4. Session Management: Handle user sessions with features like session expiration, revocation, and multi-session support.
5. Custom Authentication Flows: Extend the authentication system with custom plugins to meet specific application requirements.
6. Integration with Modern Frameworks: Seamlessly integrate with popular TypeScript frameworks, providing a consistent authentication experience across different platforms.

How Better Auth Works – Architecture Overview

Better Auth operates as a backend authentication service that integrates with your application through a simple API. Here’s an overview of its architecture:

Core Components:

• Authentication Providers: Support for various authentication methods, including email/password, OAuth providers (Google, GitHub, etc.), and custom plugins.
• Session Management: Handles user sessions, including creation, expiration, and revocation.
• Database Integration: Utilizes databases like PostgreSQL, MySQL, or SQLite to store user data and session information.
• Plugin System: Allows for the extension of authentication functionalities through custom plugins.
• Rate Limiting: Built-in rate limiter to prevent abuse and ensure fair usage.
• Security Features: Includes features like 2FA, secure password hashing, and protection against common vulnerabilities.

Data Flow:

1. User Initiates Authentication: The user attempts to log in through the application interface.
2. Authentication Request: The application sends an authentication request to the Better Auth service.
3. Credential Verification: Better Auth verifies the provided credentials against the configured authentication providers.
4. Session Creation: Upon successful authentication, Better Auth creates a session and returns a session token to the application.
5. Access Granted: The application uses the session token to grant the user access to protected resources.
6. Session Management: Better Auth manages the session lifecycle, including expiration and revocation.

Basic Workflow of Better Auth

1. Installation: Install the Better Auth package using npm or yarn. npm install better-auth
2. Configuration: Create an auth.ts file and configure Better Auth with your desired authentication methods and database connection. import { betterAuth } from "better-auth"; export const auth = betterAuth({ database: new Pool({ connectionString: DATABASE_URL, }), emailAndPassword: { enabled: true, }, plugins: [ organization(), twoFactor(), ], });
3. Session Management: Use the provided API to manage user sessions, including login, logout, and session validation. const session = await auth.login({ email, password });
4. Access Control: Implement access control mechanisms to restrict access to certain resources based on user roles or permissions.
5. Extend Functionality: Utilize the plugin system to add custom authentication features as needed.

Step-by-Step Getting Started Guide for Better Auth

1. Install Better Auth

Install the Better Auth package in your project:

npm install better-auth

2. Set Up Database

Configure your database connection. Better Auth supports PostgreSQL, MySQL, and SQLite. For example, using PostgreSQL:

import { Pool } from "pg";

const db = new Pool({
  connectionString: process.env.DATABASE_URL,
});

3. Configure Authentication

Create an auth.ts file and configure Better Auth with your desired authentication methods:

import { betterAuth } from "better-auth";

export const auth = betterAuth({
  database: db,
  emailAndPassword: {
    enabled: true,
  },
  socialProviders: {
    google: {
      clientId: process.env.GOOGLE_CLIENT_ID,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET,
    },
  },
});

4. Implement Authentication Flows

Use the provided API to implement authentication flows in your application:

const session = await auth.login({ email, password });

5. Manage Sessions

Handle session management, including creation, validation, and expiration:

const user = await auth.getSession(sessionToken);

6. Extend Functionality with Plugins

Add custom functionality using the plugin system:

import { twoFactor } from "better-auth/plugins";

auth.use(twoFactor());

7. Deploy and Monitor

Deploy your application and monitor authentication activities using the provided tools and dashboards.

The post Mastering Authentication with Better Auth appeared first on scmGalaxy.

Authentication Types in Gerrit explained!

Type of user authentication employed by Gerrit. The supported values are:

By default, OpenID

OpenID
The default setting. Gerrit uses any valid OpenID provider chosen by the end-user. For more information see openid.net.
OpenID_SSO
Supports OpenID from a single provider. There is no registration link, and the “Sign In” link sends the user directly to the provider’s SSO entry point.
HTTP
Gerrit relies upon data presented in the HTTP request. This includes HTTP basic authentication, or some types of commercial single-sign-on solutions. With this setting enabled the authentication must take place in the web server or servlet container, and not from within Gerrit.
HTTP_LDAP
Exactly like HTTP (above), but additionally Gerrit pre-populates a user’s full name and email address based on information obtained from the user’s account object in LDAP. The user’s group membership is also pulled from LDAP, making any LDAP groups that a user is a member of available as groups in Gerrit.
CLIENT_SSL_CERT_LDAP
This authentication type is actually kind of SSO. Gerrit will configure Jetty’s SSL channel to request the client’s SSL certificate. For this authentication to work a Gerrit administrator has to import the root certificate of the trust chain used to issue the client’s certificate into the <review-site>/etc/keystore. After the authentication is done Gerrit will obtain basic user registration (name and email) from LDAP, and some group memberships. Therefore, the “_LDAP” suffix in the name of this authentication type. This authentication type can only be used under hosted daemon mode, and the httpd.listenUrl must use https:// as the protocol. Optionally, certificate revocation list file can be used at <review-site>/etc/crl.pem. For details, see httpd.sslCrl.
LDAP
Gerrit prompts the user to enter a username and a password, which it then verifies by performing a simple bind against the configured ldap.server. In this configuration the web server is not involved in the user authentication process.
The actual username used in the LDAP simple bind request is the account’s full DN, which is discovered by first querying the directory using either an anonymous request, or the configured ldap.username identity. Gerrit can also use kerberos if ldap.authentication is set to GSSAPI.
LDAP_BIND
Gerrit prompts the user to enter a username and a password, which it then verifies by performing a simple bind against the configured ldap.server. In this configuration the web server is not involved in the user authentication process.
Unlike LDAP above, the username used to perform the LDAP simple bind request is the exact string supplied in the dialog by the user. The configured ldap.username identity is not used to obtain account information.
OAUTH
OAuth is a protocol that lets external apps request authorization to private details in a user’s account without getting their password. This is preferred over Basic Authentication because tokens can be limited to specific types of data, and can be revoked by users at any time.
Site owners have to register their application before getting started. Note that provider specific plugins must be used with this authentication scheme.
DEVELOPMENT_BECOME_ANY_ACCOUNT
DO NOT USE. Only for use in a development environment.
When this is the configured authentication method a hyperlink titled Become appears in the top right corner of the page, taking the user to a form where they can enter the username of any existing user account, and immediately login as that account, without any authentication taking place. This form of authentication is only useful for the GWT hosted mode shell, where OpenID authentication redirects might be risky to the developer’s host computer, and HTTP authentication is not possible.

Reference
https://dev.vaadin.com/review/Documentation/config-gerrit.html#auth

The post Authentication Types in Gerrit explained! appeared first on scmGalaxy.