Hosted pages on your domain
Sign in, sign up, reset, invites, consent and an account page, with your branding, on microauth.dev or your own subdomain.
User authentication and AI access
Sign in for your app, and safe access for AI clients
MicroAuth gives your app hosted sign in on your own domain, OAuth 2.1 and OpenID Connect, roles and permissions, and MCP authorization, so people can connect AI assistants to your tools with only the access they approve. Built for FastAPI, on open standards.
Selling an API instead? Keys, rate limits and billing are here too.
from fastapi import Depends, FastAPI
from microauth_fastapi import User, UserAuth
app = FastAPI()
auth = UserAuth(app) # adds /auth/login, /auth/callback and /auth/logout
@app.get("/dashboard")
async def dashboard(user: User = Depends(auth.login_required)):
return {"hello": user.name}
@app.post("/posts")
async def create_post(user: User = Depends(auth.require(permissions="posts:write"))):
...Sessions live in an encrypted, HttpOnly cookie, so browser JavaScript never holds a token.
from fastapi import Depends, FastAPI
from microauth_fastapi import TokenAuth, TokenClaims
app = FastAPI()
api = TokenAuth(app) # reads MICROAUTH_ISSUER and MICROAUTH_RESOURCE
@app.get("/posts")
async def posts(token: TokenClaims = Depends(api.require("posts:read"))):
return {"user": token.sub, "app": token.client_id}Access tokens are checked locally against your service's signing keys. A token made for another API is refused.
from fastapi import FastAPI
from mcp.server.mcpserver import MCPServer
from microauth_fastapi import McpAuth, current_identity
mcp = MCPServer("Invoices", log_level="WARNING")
auth = McpAuth(scopes=["invoices:read"])
@mcp.tool()
@auth.tool("invoices:write")
def create_invoice(customer: str, amount_cents: int) -> dict:
return {"owner": current_identity().sub, "customer": customer, "amount_cents": amount_cents}
app = FastAPI()
auth.mount(app, mcp) # serves /mcp next to your other routesEach tool declares the scopes it needs. A client missing one gets a 403 that names them, so it can ask the person once.
How it works
Everything sign in needs, without running it yourself
Create a sign in service in the dashboard, register your app, and add the SDK. MicroAuth runs the pages, the accounts and the OAuth server.
Hosted sign in
Sign in pages on your own domain
Sign in, sign up, password resets, invites, passkeys and two step verification, with your logo and colors. They are live at yourapp.microauth.dev right away, and can move to a domain of yours like auth.example.com.
People also get an account page for their profile and photo, sessions, connected providers and the apps they allowed.
Open standards
OAuth 2.1 and OpenID Connect
Every app uses the code flow with PKCE. Access tokens are short lived JWTs for one API, refresh tokens change on every use, and ID tokens tell your app who signed in and how.
Web apps, single page apps and native apps all work, with any OpenID Connect library. With FastAPI, the SDK does it in a few lines.
GET /.well-known/openid-configuration
{
"issuer": "https://auth.example.com",
"authorization_endpoint": "https://auth.example.com/oauth/authorize",
"token_endpoint": "https://auth.example.com/oauth/token",
"jwks_uri": "https://auth.example.com/oauth/jwks",
"code_challenge_methods_supported": ["S256"],
"scopes_supported": ["openid", "profile", "email",
"offline_access", "roles", "posts:read", "posts:write"]
}
Access control
Roles, permissions and your users
Define permissions such as posts:write and group them into roles. Your app reads them from the session, and they become the OAuth scopes of your APIs and MCP servers.
The users page lets you search, change roles, see sessions and connected apps, suspend someone, sign them out everywhere, send a password reset or invite new people.
AI access with MCP
Let AI clients act for your users, within limits they approve
MicroAuth is the authorization server for your MCP server, following the MCP authorization spec. You keep your tools and your data. MicroAuth handles sign in, consent and tokens.
The client finds you
Your MCP server answers with its metadata, which names your sign in service and the scopes to ask for.
The person approves
They sign in on your pages and see the app, where it sends them back and each permission it wants.
A token for one server
The client gets a short lived token that only your MCP server accepts, with only what the person holds and allowed.
Every tool call checked
The SDK checks the token and the scopes each tool needs. Your code still decides which records the person can touch.
People stay in control
Consent that asks only for what's new
When a tool needs more, the client asks again for just the new permissions, which join the existing grant.
Connected apps on the account page
People see every app they allowed and disconnect any of them. You can block an app for everyone.
Clients identify themselves
AI clients use Client ID Metadata Documents, and older ones can register themselves. Each one is labeled on the consent screen.
Keys for clients without OAuth
A client that can't do OAuth can use an API key the person creates, limited to the permissions they choose.
Terminal
$ curl -X POST https://app.example.com/mcp
401WWW-Authenticate: Bearer resource_metadata="https://app.example.com/.well-known/oauth-protected-resource/mcp", scope="invoices:read"
# a token holding invoices:read calls list_invoices
200{"result":{"content":[...]}}
# the same token calls create_invoice
403WWW-Authenticate: Bearer error="insufficient_scope", scope="invoices:read invoices:write"
Features
What your sign in service includes
OAuth 2.1 and OpenID Connect
Discovery, PKCE for every app, pushed authorization requests, rotating refresh tokens, userinfo, revocation, introspection and sign out.
Roles and permissions
Permissions you name, roles that bundle them, and default roles for new users. Changes reach your app within one token lifetime.
User management
Search users, change roles, suspend, sign out everywhere, send a reset, remove two step verification, delete or invite.
External sign in
Google, GitHub, any OpenID Connect provider or a generic OAuth 2.0 one, with your own client credentials and safe account linking.
MCP authorization
Protected resource metadata, consent, step up, connected apps and per tool scopes for the MCP servers your users connect AI clients to.
API keys for your users
People create keys for scripts and CI with the permissions they choose. Your API checks them with standard token introspection.
Passkeys and two step
Passkeys, authenticator apps and recovery codes on your sign in pages, with security emails under your app's name.
A FastAPI SDK
UserAuth for web apps, TokenAuth for APIs and McpAuth for MCP servers, in one package.
APIs
Sell your API, or protect an internal one
The same workspace runs API services: keys, rate limits and usage billing that your API checks itself. Your traffic never goes through MicroAuth.
Sell an API
Developers sign up on a portal with your name on it, create keys and pay you through your own Stripe account.
- A branded developer portal
- Keys checked from a local copy, with no proxy
- Rate limits, quotas and prepaid credit
- Monthly plans and usage billing, with no revenue share
Protect an internal API
For an API your own teams or partners call. You invite who gets in and issue their keys, and nobody pays.
- Invite only, with billing switched off
- Keys you issue, with an optional expiry
- Rate limits and usage per team
- The same SDK and HTTP endpoints
from fastapi import FastAPI, Security
from microauth_fastapi import MicroAuth, Customer
app = FastAPI()
auth = MicroAuth(app) # reads MICROAUTH_SECRET_KEY
@app.get("/forecast")
async def forecast(customer: Customer = Security(auth)):
return {"hello": customer.id}Keys, rate limits, quotas and billing on every route that asks for a customer. If MicroAuth is unreachable, known keys keep working from the cached copy.
- GET
/sdk/v1/snapshotCache customers, keys and limits locally - GET
/sdk/v1/keys/verifyLook up a key created seconds ago - POST
/sdk/v1/usageReport usage in idempotent batches
These three endpoints are the whole integration, in Node, Go, Rails or anything else. Read the HTTP guide
Questions
What developers ask us
Do I have to use FastAPI?
No. Sign in is standard OpenID Connect, so any OpenID Connect library works, in any language. Access tokens are JWTs your API can check with the published signing keys, and API keys can be checked with standard token introspection. FastAPI gets an SDK that does all of it in a few lines.
Do requests to my app go through MicroAuth?
Sign in does: the sign in pages and the OAuth endpoints run on MicroAuth. After that, your app, APIs and MCP servers check tokens themselves with your service's signing keys, so their requests never pass through us. For API services, the SDK checks keys from a cached copy and only sends usage counts.
Where do browser sessions live?
The sign in pages keep their own session on your sign in domain, which gives single sign on across your apps. Each app runs the code flow on its server, and the FastAPI SDK keeps its session in an encrypted, HttpOnly cookie. No token is ever handed to browser JavaScript.
Which AI clients can connect to my MCP server?
Clients that follow the MCP authorization spec. They identify themselves with a Client ID Metadata Document, or register themselves when they are older. Apps people connect are turned on per service, on the plans that include them. Read how it works.
Can my users sign in with Google or GitHub?
Yes, with your own client credentials from Google or GitHub. You can also add any OpenID Connect provider, or a generic OAuth 2.0 one. The pricing page shows which plans include each.
Does my API traffic go through MicroAuth when I sell an API?
No. MicroAuth isn't a gateway or a proxy. The SDK inside your API caches customer limits and reports usage counts in batches. Request bodies, headers, query parameters and responses never leave your servers.