---
title: "Authsome"
tagline: "Auth engine"
language: "Go"
license: "Apache-2.0"
since: "2025"
canonical: "https://xraph.com/work/authsome"
---

# Authsome

Authentication for Go with every method as a plugin: password, social OAuth2, magic links, passkeys, TOTP and SMS second factors, API keys, SAML. Users, sessions, organizations, teams, RBAC and device tracking sit in the core; you compile in the methods you actually use. Ships with a dashboard.

## Install

```bash
go get github.com/xraph/authsome
```

## What it is

Authsome is a composable authentication and identity engine for Go. Core identity is built in; every authentication method is a plugin, so you compile in what you use.

## Core identity

- Users: registration, profiles, email verification and password reset.
- Sessions: configurable lifetimes, refresh token rotation, and binding to IP and device.
- Organisations and teams: multi-tenant, with memberships, invitations and hierarchy.
- Role-based access control: roles, permissions, role hierarchies and middleware enforcement.
- API keys: scoped, with expiry and automatic header or bearer detection.
- Device tracking: register, trust and manage user devices.
- Webhooks and security events for every lifecycle action.

## Methods, as plugins

Password with bcrypt or argon2 and a configurable policy covering length, complexity, history and expiration. Social OAuth2 across Google, GitHub and 30-plus providers. Magic links. Passkeys and WebAuthn for FIDO2 hardware and platform authenticators. TOTP and SMS second factors. Machine-to-machine API keys. Enterprise SSO over SAML.

The plugin split matters more than it sounds. An application that never needs SAML does not carry SAML code, SAML configuration or SAML attack surface. Adding it later is a dependency and a registration rather than a fork.

## Security and governance

Account lockout with configurable thresholds, per-endpoint rate limiting, password history and expiration, and session binding to IP and device fingerprint. Every authentication action produces a security event, which is what makes an incident reconstructable afterwards.

## Where it came from

Frank was the first attempt, as a standalone multi-tenant auth server. It worked, and it taught me that most teams do not want to operate another service for authentication. They want it inside the process they already run. Authsome is that lesson applied, with Guardian's plugin structure from 2021 underneath it.

---

*Unpublished draft. Not peer reviewed and not submitted to a venue.*


## Anatomy

- **Identity core**: Users, organisations and sessions, independent of how you signed in.
- **Methods**: Password, OAuth, passkeys and SSO as plugins over the same core.
- **Governance**: Policy, lockout and audit as first-class concerns.
- **Tenancy**: Organisation scope propagated with the session.

## Constraints and trade-offs

- (decision) The method is a plugin; identity is not. Adding SSO must not fork the user model.
- (constraint) Every session carries tenant scope. Authorisation without it is a bug, not a configuration.