Avonao ID is the one account that signs people in to the Avonao platforms and to every app that offers Sign in with Avonao ID. This page sets out how that works, what we protect and how, where your data lives and what we commit to. Each statement links to the document that binds it.
Operated by Avonao, Inc., DelawareLegal documents are published as drafts, pending legal review.
Create your account in a minute with a passkey, then connect the platforms you use.
Every sign-in follows the same path. The person is checked at the front service, the request is handled in the region that holds their data, and the token is signed with a key that is published for anyone to verify.
The person signs in with a passkey, an emailed link or code, or Google, Microsoft or GitHub. There are no passwords. Session tokens, link tokens and codes are stored only as SHA-256 hashes.
The region is read from the request itself, from the session cookie or the token prefix. The front service forwards the request to that region's own service with a signed hop header, and the regional service refuses a request without a valid one.
The person sees the consent screen of the app and allows only the scopes they choose. The app receives a private pairwise ID, the person gets a data receipt, and the sign-in goes to their own security log in their region.
The ID token is signed with the active ES256 key. Authorization codes last 60 seconds and ID tokens 5 minutes. The private keys are stored encrypted, under a key that is not in the database.
A signed token is a precise, narrow statement. Read both columns before you rely on one, and before you ask someone else to.
One issuer, https://id.avonao.com, signs for all seven regions with ES256 (P-256) keys. Their public halves are published openly; the private halves are stored encrypted in the home database.
Every request is tied to a person or an app before anything is read or changed. This is how sign-in, consent, regions and outbound requests are handled today.
No passwords are stored. Passkeys keep only the public key. Session tokens, link tokens and codes, authorization codes, access tokens, recovery codes and app client secrets are stored as SHA-256 hashes. Secrets the service must read, such as authenticator secrets and webhook signing secrets, are encrypted with AES-256-GCM.
Passkeys, an emailed link or code valid for 10 minutes with at most 5 code attempts, social sign-in, and authenticator apps with recovery codes. The session cookie is __Host- prefixed, HttpOnly, Secure and SameSite=Lax, ends after 14 days without use and after 90 days at most. Sensitive changes ask for a fresh confirmation within 10 minutes.
The service is designed to hold as little as it can: no passwords, hashes instead of tokens, a private ID for every app, and only the scopes a person allowed.
Tokens, links, codes and client secrets are stored as SHA-256 hashes, so a copy of the database does not contain a working one. There is no password to store.
A third-party app gets a pairwise ID of its own for each person, never the account id, so two apps cannot match their users. Avonao's own platforms receive the account id.
Status is measured from our servers, not written by hand. We make no uptime promise during early access, and a token an app already holds can be checked offline until it expires.
What we commit to when something goes wrong, and how to tell us about a weakness before anyone else finds it.
If a breach affects personal data we process on behalf of a business, we notify the business without undue delay and where possible within 48 hours, with what is known: the nature of the breach, the people and records concerned, the likely consequences and the measures taken. Where we are the controller, we notify the competent authority within 72 hours of becoming aware unless the breach is unlikely to put people at risk, and we tell the people concerned without undue delay when the risk is high.
What exists today, what is available on request and what we do not claim. If a row matters to your review, the linked document is the binding text.
| Item | State | Detail |
|---|---|---|
| Data Processing Agreement | In place | An annex to the Business Terms for the cases where we process personal data on a business's behalf: enterprise connections and workforce sign-in. A person's own Avonao ID is ours as controller. Published as draft 0.1. |
Every document that governs Avonao ID. They are published as drafts, pending legal review. We tell members by email at least 30 days before important changes to the Terms take effect, and businesses at least 30 days before a sub-processor is added or replaced.
| Document | What it covers | Version |
|---|---|---|
| Terms of Service | The agreement with members: the account, sign-in, apps and consent, the network, Verified when enabled, deletion with a restore window and liability. | Draft 0.1 |
Running a vendor review? Tell us what you need. We answer questionnaires in writing, and Enterprise buyers can talk to us about the architecture.
We make available what shows how we meet Article 28 GDPR. Send your questionnaire to privacy@avonao.com.
Email privacy@avonao.com →EnterpriseFor an Enterprise evaluation: enterprise sign-in with SAML or OIDC, SCIM, contract terms and the procurement paperwork.
The token names its key id. Your backend fetches the published key set, checks the signature, issuer, audience, expiry and nonce, and needs no call to us for each token.
Verification is independent. Trust is narrowed to a short, named list.
| You trust | Why | If it fails |
|---|---|---|
| The key set you verify against is ours | A signature proves who holds a key, not whose key it is. You fetch the set over HTTPS from the issuer you configured. | A substituted key set would make forged tokens look valid. Pin the issuer and, for the strongest position, the key ids. |
| Our signing keys are used only by the sign-in service | The service signs what its code decides to sign. The keys are encrypted at rest, with no hardware security module today. | A leaked key-encryption key or a misused key could sign tokens for sign-ins that never happened. A compromised key can be removed from the published set at once. |
| We check sign-in methods honestly | Passkeys, codes and links are checked by our code. For Google, Microsoft and GitHub we rely on the address they report as verified. | A compromised Avonao ID service could sign a false sign-in, and a compromised provider could report a false address. |
| Our clock | The issued-at and expiry times are our server time at signing. | A skewed clock gives wrong times. Allow a small clock skew when you check them. |
| Address | Content |
|---|---|
https://id.avonao.com/.well-known/jwks.json | The JWK set: public keys only, cacheable for five minutes |
https://id.avonao.com/.well-known/openid-configuration | OpenID discovery: issuer, endpoints and supported algorithms, cacheable for one hour |
https://id.avonao.com/.well-known/oauth-authorization-server | The same metadata in OAuth authorization server form (RFC 8414) |
Checkable
curl -sSL https://id.avonao.com/.well-known/jwks.json
// kid = first 22 characters of the base64url SHA-256 of the key's crv, kty, x and y members as JSON
const json = JSON.stringify({ crv: k.crv, kty: k.kty, x: k.x, y: k.y });
const digest = new Uint8Array(await crypto.subtle.digest("SHA-256", new TextEncoder().encode(json)));
const kid = btoa(String.fromCharCode(...digest))
.replace(/\+/g, "-").replace(/\//g, "_").replace(/=+$/, "").slice(0, 22);For the strongest position, fetch the key set once, store each kid with its x and y values in your own repository, and verify against that copy. Refresh it when a new kid appears. See /.well-known/openid-configuration
An app gets only the scopes the person allowed and a private ID of its own, and the person can remove its access at any time. Business roles (owner, admin, developer) follow least privilege, and an invitation can only be accepted by the invited, confirmed email address.
A person's data lives in one regional database, reached only by that region's service. A cookie or token from another region is refused, and nothing is read from or written to another region as a fallback. Businesses are separated logically by business id; a dedicated database per business is built but not switched on.
Webhooks are sent to https addresses on a public host name, signed with HMAC-SHA256 and a timestamp, with a 5-second timeout, and redirects are never followed. A wallet verifier callback must be https on a domain the business has verified. Enterprise sign-in checks the identity provider's signature, issuer, audience, expiry and nonce.
Sign-in, code entry, the token endpoint, business creation, invitations, domain verification, reports and follows are all rate limited; the email link allows 5 requests per address and 20 per IP address in 10 minutes. Counters are stored as keyed hashes, so neither address nor IP is kept in clear. A bot check protects sign-up and business creation when configured.
Stated limits: a hostname that resolves to a private address is stopped by Cloudflare's own egress rules, not by us, so the allow-list of verified domains is the main control. Webhooks, enterprise connections (SAML and OIDC) and SCIM are Beta, provided as they are. Browser requests that change data must come from the same origin.
Each time an app receives a person's details, the person gets a data receipt. They can see what each app can see and remove its access under Your apps.
An app receives only the scopes allowed on the consent screen. A platform reports only whether a subscription is none, free or paid. Verified, when switched on, keeps the outcome and trust level, never document images.
A person's personal data, sessions and sign-in history are stored only in the region they choose at sign-up. Business records (apps, domains, keys) and a pseudonymous sign-in index are kept in the home region, US West. Requests reach Cloudflare's network at the visitor's nearest location and are then handled in, or forwarded to, the person's region.
| Region | Code | Service placement (AWS region) | Storage |
|---|---|---|---|
| US East | enam | us-east-1 | Location hint |
| US West | wnam | Home service | Location hint |
| Europe Central | weur-1 | eu-central-1 | EU jurisdiction (enforced) |
| Europe West | weur-2 | eu-west-1 | EU jurisdiction (enforced) |
| Europe North | neur | eu-north-1 | EU jurisdiction (enforced) |
| Asia-Pacific | apac | ap-southeast-1 | Location hint |
| Oceania | oc | ap-southeast-2 | Location hint |
A region says where a person's data is stored. A request for a person in one region never reads or writes another region's database, and a region that cannot be reached fails the request with an error instead.
Traffic uses HTTPS. Databases are encrypted at rest by our infrastructure provider, Cloudflare. Secrets the service must read are also encrypted in the application with AES-256-GCM, under a key that is held as a platform secret and never stored in the database.
Deleting an account closes it at once and ends its sessions and app connections. For 28 days the person can sign in and cancel the deletion; then the account, emails, sign-in methods, sessions, consent records and data receipts are purged, and security log entries are anonymised. Platforms and business apps are told so they can delete their copies. Deletion is refused while a paid subscription runs. A person can download their data as a JSON file at any time.
Avonao ID is free for people and companies. During early access there is no service level agreement unless one is agreed in writing. Support is by email: business-support@avonao.com for businesses and enterprise-support@avonao.com for enterprise connections and contracts.
| Plan | Support and service level |
|---|---|
| Free, Pro, Team and Scale | business-support@avonao.com. No uptime commitment or service credits during early access. |
| Enterprise | enterprise-support@avonao.com. Any service level is agreed in writing in the contract. |
| Beta features | Webhooks, enterprise connections and SCIM are provided as they are and are not covered by any service level. |
| Situation | What it means | What we commit to |
|---|---|---|
| Service outage | A check on the status page fails: sign-in discovery, the signing keys or the plans and configuration do not answer. | Shown as Not responding on the status page within about 30 seconds. |
| Personal data breach | A security incident leads to the loss, alteration or unauthorised disclosure of, or access to, personal data. | A business is told without undue delay, where possible within 48 hours. Authorities within 72 hours where required. |
| Beta feature change | A Beta feature, such as webhooks or an enterprise connection, changes or ends. | At least 14 days' notice before ending a Beta feature a business uses. |
A plan limit never switches off sign-in: over the monthly active user limit, owners are warned and sign-ins carry on. Over the app or seat limit, new ones are refused and existing ones stay.
A token an app already holds is checked offline against the published keys. ID tokens last 5 minutes, so signing in again needs the service.
A failing check shows on the status page. For a security incident we contain it first: exposed secrets are rotated, the sessions of affected accounts are ended and an affected route can be switched off. Affected people are told by email from no-reply@id.avonao.com, with a support address.
Report through the form, with your contact details or anonymously, or by email to security@avonao.com. The report page sets out the scope and safe harbor.
| Step | Target |
|---|---|
| Acknowledge your report | Within 3 business days |
| Initial assessment and severity | Within 10 business days |
| Updates while the issue is open | At least every 14 days |
| Fix for critical and high severity | We aim for 30 days |
| Fix for lower severity | We aim for 90 days |
Targets, not guarantees. We ask for 90 days before public disclosure. There is no monetary bug bounty; we credit researchers by name on request.
| International transfers | In place | Where data leaves the EEA, the UK or Switzerland we rely on the EU-US Data Privacy Framework where the provider is certified, and otherwise the EU Standard Contractual Clauses with the UK addendum. |
| Article 27 representative | In place | NUICORN, Chausseestraße 86, 10115 Berlin, Germany, is our representative and data protection officer for the European Union. It is named in the Privacy Policy. |
| Sub-processor changes | In place | At least 30 days' notice by email to the owners or in the console, with the right to object on data protection grounds and, if we cannot resolve it, to end the affected service. |
| Privacy rights requests | In place | Download, correct and delete in the dashboard. Other requests go to support@avonao.com and are answered without undue delay and within one month. |
| Security pack | In place | A security whitepaper and a pre-filled security questionnaire for Avonao ID, to read online or download. |
| Security questionnaire | On request | On request we make available the information that shows how we meet Article 28 GDPR: the DPA, the security measures in its Annex 2 and the sub-processor list. |
| Customer audit | On request | Once a year with 30 days' notice, by the business or an independent auditor bound by confidentiality, at the business's cost, or at any time after a breach. We may answer first with documentation. |
| Sub-processor certifications | On request | Where a provider's certifications or public compliance documents exist and we may share them, we can meet an audit request with those first. |
| Bug bounty | Not offered | No monetary rewards. Researchers are credited on request. |
| SOC 2 and ISO 27001 | Not claimed | Avonao ID holds no SOC 2 report or ISO 27001 certificate and does not claim one. |
| HIPAA | Not claimed | Avonao ID is not a HIPAA service. We have not been assessed under HIPAA and do not sign business associate agreements. Do not put protected health information into it. |
| FedRAMP | Not claimed | Avonao ID has no FedRAMP authorisation and does not claim one. |
| What personal data we process, why, who receives it, where it is stored, how long it is kept, cookies and how to exercise your rights. |
| Draft 0.1 |
| Acceptable Use Policy | Numbered rules for what may not be done with the service, which statements of reasons can cite. | Draft 0.1 |
| Verified consent | What a person agrees to when they choose the Verified identity check, which data is processed and what is kept. | Draft 0.1 |
| Business Terms | For businesses that use Avonao ID in their apps: roles, domains, going live, data duties, listing, moderation, Beta features, support and liability. | Draft 0.1 |
| Data Processing Agreement | Processor terms for enterprise connections and workforce use: instructions, security measures, sub-processors, breach notice, audits and deletion. | Draft 0.1 |
| Sub-processors | Each provider that processes personal data for Avonao ID, what it does, where, and how changes are announced. | Draft 0.1 |
| Notice and action | How to report a business, how a report is reviewed, the possible outcomes, statements of reasons and how to contest a decision. | Draft 0.1 |
| Ranking rules | The published rules that decide how businesses are ordered in the Avonao Business Circle directory. | Draft 0.1 |
| Analytics rules | The hard rules for measurement on our sites: consent first, never on sign-in pages, no identifiers in events, no ads. | Draft 0.1 |
| Imprint | Who publishes Avonao ID, where the company is registered and how to reach it. | Draft 0.1 |