Sign-in methods
Password, magic links, email codes, and social sign-in — all issuing the same session.
Five ways in, one outcome. Whichever a user chooses, they end at the same session issuer and your code receives the same token payload.
What is available
curl "$AUTHORIC_URL/$APP_UID/auth/methods"Returns the methods enabled for this app, so a sign-in screen can render itself rather than hard-coding what it expects to exist.
Password
curl -X POST "$AUTHORIC_URL/$APP_UID/auth/login" \
-H "Content-Type: application/json" \
-d '{ "email": "user@example.com", "password": "StrongPass!234" }'Magic link
# 1. Send the email
curl -X POST "$AUTHORIC_URL/$APP_UID/auth/magic-link/request" \
-H "Content-Type: application/json" \
-d '{ "email": "user@example.com" }'
# 2. Exchange the token from the link
curl -X POST "$AUTHORIC_URL/$APP_UID/auth/magic-link/verify" \
-H "Content-Type: application/json" \
-d '{ "token": "..." }'Email code
Same two steps against /auth/otp/request and /auth/otp/verify, with a six-digit code
instead of a link. Codes are attempt-capped, so guessing fails closed.
Google and GitHub
# 1. Begin — returns authorizeUrl, the provider URL to send the user to
curl -X POST "$AUTHORIC_URL/$APP_UID/auth/oauth/google/start"
# 2. Exchange the hand-off code after the provider redirects back
curl -X POST "$AUTHORIC_URL/$APP_UID/auth/oauth/exchange" \
-H "Content-Type: application/json" \
-d '{ "code": "..." }'The provider redirects to a pre-registered callback that cannot carry your token, so trust is established with a single-use state value instead.
Linked identities
A user can hold several sign-in methods. They can list them, disable one, or unlink it:
| Method | Path |
|---|---|
GET | /{appUid}/auth/identities |
PATCH | /{appUid}/auth/identities/{identityUid} |
DELETE | /{appUid}/auth/identities/{identityUid} |
A user who signed up with Google has no password, and that is a supported state rather than a broken one. Do not assume every account has one.