The drop-in button¶

For a site that does not speak OIDC, or one that wants sign-in to happen where the person already is rather than on a login page.

One tag¶

<script src="https://auth.omxus.com/button.js"
        data-omxus
        data-verify="/api/auth/omxus"
        data-label="Login"
        data-reload></script>

Style it with variables, or leave it:

:root{
  --omxus-size:132px;   /* round button only */
  --omxus-face:#0d8b88;
  --omxus-ring:#d4af37;
  --omxus-word:#fff;
}

Listen instead of reloading:

document.addEventListener('omxus:signin', (e) => { /* e.detail.session */ });
document.addEventListener('omxus:error',  (e) => { /* e.detail.error   */ });

The same events, without the omxus: prefix (signin, error), also bubble from the script tag itself.

What happens on a press¶

From worker/button.js in the auth repo, which is what auth.omxus.com serves:

1. On load it imports /engine/engine.bundle.mjs (served) and /sdk/omxus-credential.mjs (404 today) from auth.omxus.com, and makes a credential store for issuer https://auth.omxus.com.
2. On a press it calls the store's signIn(): a passkey if the device has one, otherwise a new passkey, otherwise a key sealed on this device. See Memory, not storage.
3. signIn() asks for a challenge and posts the signature to /auth/challenge and /auth/verify on your page's own origin (the store is made with no base path). Your site would need to forward those to auth.omxus.com; the provider does not send CORS headers for /auth/*.
4. It posts the result to data-verify and fires omxus:signin.

What your endpoint receives¶

{
  "issuer": "https://auth.omxus.com",
  "session": { "address": "0x…", "ok": true, "returnTo": "/", "tier": "passkey-seed" }
}

session is the answer from /auth/verify plus the address. The provider's session token goes into a cookie on the provider's origin; it is not in the body. So the body is only a claim: anyone can post any address to your endpoint. Do not create a session from it.

/oauth/introspect does not help here. It reads a form-encoded body, needs your client id and secret, and only answers for OIDC access tokens issued to your client; anything else comes back {"active": false}. To check an access token you do hold:

curl -s https://auth.omxus.com/oauth/introspect \
  -d "client_id=$CLIENT_ID" \
  -d "client_secret=$CLIENT_SECRET" \
  -d "token=$ACCESS_TOKEN"
# {"active":true,"scope":"openid profile","client_id":"…","token_type":"Bearer","sub":"…","exp":…,"iat":…}

Untested against a live token here; the request and answer shapes are from server/oidc-introspect.js and server/router.js. The answer has sub, not an address.

Where to put it¶