Let users sign in with Google or GitHub. Get a consistent identity through one API, without handling provider tokens.
Your users’ familiar accounts. Your application’s own sessions.
{
"subject": "usr_demo_google",
"provider": "google",
"name": "Jane Smith",
"username": null,
"email": "jane@example.com",
"emailVerified": true,
"avatarUrl": "https://…"
}An AnyOAuth token. Profile access only.
Interactive preview. No sign-in request is sent.
Two providers. One integration.
GoogleGitHubKeep the familiar sign-in experience. Leave provider-specific callbacks and profile formats to AnyOAuth.
A consistent response for the fields you need. Stable subjects keep identities separate within each project.
google subjectgithub subjectprofile.subjectOur token retrieves one profile. It expires in 15 minutes, can be revoked, and cannot access provider APIs.
aop_••••••••••••••You own the user record, session, and permissions. Get the identity, then continue with your application’s logic.
Google and GitHub adapters use the same code exchange and profile endpoint. Enable the providers your application needs.
OpenID Connect
Sign users in with their Google account. Receive validated identity claims and preserve their email verification status.
openidprofileemailOAuth identity flow
Sign users in with their GitHub account. Get their profile and primary email without requesting repository access.
read:useruser:emailAvailability depends on the service’s configured provider applications. Profile fields vary by provider.
A small API that fits into your backend. No provider-specific token handling in your application.
Send the user to AnyOAuth with state, a PKCE challenge, and your registered callback.
Validate the returned state. Your backend exchanges the code for an AnyOAuth token.
Fetch the identity, find or create your user, and issue your application’s session.
// Exchange the single-use callback code
POST /v1/token
{
"grant_type": "authorization_code",
"client_id": "YOUR_CLIENT_ID",
"client_secret": "YOUR_SERVER_SECRET",
"code": "CALLBACK_CODE",
"redirect_uri": "YOUR_CALLBACK",
"code_verifier": "ORIGINAL_VERIFIER"
}
// Use the returned AnyOAuth token
GET /v1/profile
Authorization: Bearer aop_…Your application gets the profile it needs. Provider credentials stay inside the server-side sign-in flow.
Explore the security modelBrowser-bound state, PKCE, exact callbacks, and single-use codes.
Profile tokens expire after 15 minutes and are stored only as hashes.
Separate subjects per project. Matching emails never automatically merge accounts.
Clear answers before you add another piece to your authentication stack.
No. Your backend gets an AnyOAuth token that can only fetch the signed-in user’s profile. Provider tokens are not returned or stored.
Your app owns its sessions and permissions. Fetch the profile, find or create your user by the stable subject, and issue your own session cookie.
Subject, provider, provider subject, name, username, email, email verification status, and avatar. Fields that a provider does not supply are returned as null.
AnyOAuth profile tokens expire after 15 minutes. There is no refresh token. You can revoke a token early, or delete the associated user in your dashboard.
No. AnyOAuth is sign-in only. It requests identity scopes and does not provide access to repositories, messages, calendars, or other provider APIs.
Create a project. Register your callback. Get the profile.
