EAuth Terms of Service

Version: 1.8
In effect from: 3 October 2026
Provider: Samuel Krauss, sole proprietor, Oberägeri ZG, Switzerland, trading as Elchi Studios
Contact: legal@elchi.dev
Applies to: eauth.me, panel.elchi.dev, docs.elchi.dev and the SDKs
published under the EAuth name, and auth.elchi.dev, which redirects to eauth.me
under clause 2.4

1. Who these terms are between

1.1 These terms govern your use of EAuth, an authentication service operated by
Samuel Krauss ("we", "us"), a sole proprietor seated in Oberägeri, Canton
of Zug, Switzerland, trading under the name Elchi Studios. The business is not
entered in the commercial register. Samuel Krauss personally is the
counterparty to this agreement; Elchi Studios is the name under which the
service is presented.

1.2 "You" means the natural or legal person registering an application. If you
register on behalf of a company, you confirm you are authorised to bind it.

1.3 "End user" means a person who signs in through your application using
EAuth. End users are your users, not ours. We process their data on your
instructions under the Data Processing Agreement in Annex B.

1.4 You must be at least 16 years old to register an application, or have the
consent of a parent or guardian.

2. The service

2.1 EAuth provides OAuth 2.1 and OpenID Connect authentication: a hosted
sign-in page, an authorization server and token issuance at eauth.me, and the
management console at panel.elchi.dev. The issuer identifier is
https://eauth.me.

2.2 We implement the OpenID Connect Core specification and the OAuth 2.0
security practices set out in RFC 9700. Where the service deviates from a
specification, the documentation at docs.elchi.dev says so.

2.3 We may change, add or remove features. Where a change would break existing
integrations, we will give at least 90 days' notice by email to the address on
your account and in the changelog, except where a shorter period is necessary
to address a security problem.

2.4 Until 3 October 2026 the service was provided at auth.elchi.dev, under the
issuer identifier https://auth.elchi.dev. Since that day, every request to
auth.elchi.dev is answered with a permanent redirect to the same path at
eauth.me. Changing the issuer breaks integrations that name it, which would
call for the notice in clause 2.3. None was needed: on that day every
application registered with EAuth belonged to Elchi Studios, and no one
outside Elchi Studios had an account, so no integration of anyone else was
affected.

3. Cost, and what "free" means

3.1 EAuth is provided free of charge. There is no paid tier, and we do not
sell your data or your end users' data. We do not serve advertising.

3.2 Free does not mean unconditional. Section 6 sets out usage limits that
exist to keep the service available for everyone, not to create an upgrade
path.

3.3 We do not reserve a right to start charging for what is described here.
There is no paid tier, no usage threshold that becomes an invoice, and no
feature withheld to create one. This is stated as a term rather than as
marketing, because a promise made only on a website is worth what a website is
worth.

3.4 These terms cover the services listed at devs.elchi.dev. Being listed
there requires being free permanently, so the commitment in 3.3 and the
listing are the same fact stated twice.

3.5 A service with a paid tier is not listed at devs.elchi.dev and is not
governed by this document. It has its own page and its own terms, which you
will see before registering for it. It is administered through the same
console, because that is where credentials belong regardless of price, and
being in the console implies nothing about what a service costs.

4. Availability

4.1 We give no availability guarantee. There is no service level
agreement, no uptime commitment, and no compensation for downtime.

4.2 This is a deliberate consequence of clause 3.1. A free service cannot
responsibly promise availability it is not paid to underwrite, and we would
rather say so plainly than publish a figure we cannot stand behind.

4.3 We publish our actual measured availability at status.elchi.dev, which is
live since 3 October 2026, when the service moved to our operation across
several data centres. A figure appears there once a full month has been
measured. It is a record of what happened, not a promise about what will
happen.

4.4 If your application cannot tolerate authentication being unavailable, you
should run EAuth on your own infrastructure. Section 11 covers this.

Failures caused by third parties

4.5 We use third parties, including hosting providers, to operate the
service. An outage originating with one of them is still an outage of EAuth.
We do not disclaim it, because clause 4.1 already means there is no
availability commitment to disclaim, whatever the cause.

4.6 This exclusion applies to availability only. It does not extend to the
security of your end users' personal data. Where a third party we engaged
causes a personal data breach, we remain liable to you for it under Annex B.8
and Art. 28(4) GDPR. We chose that provider; you did not. A clause purporting
to shift that liability to them would be void, and we do not attempt one.

What actually happens when EAuth is unavailable

4.7 We state this precisely so you can plan, rather than leaving you to
discover it during an incident.

• Existing sessions continue. Access tokens are signed, and your
  application verifies them against a cached copy of our public keys. They keep
  working until they expire, by default 15 minutes, without contacting us.
• Refresh stops. Once an access token expires, the refresh call fails and
  the end user is signed out.
• New sign-ins fail. Nobody can start a session.

4.8 Two things follow. First, cache the JWKS response rather than fetching it
per request; your users then keep working through a short outage. Second, if
minutes of lockout are unacceptable to you, tell us and we will raise your
access token lifetime, or run the service yourself under Section 11.

4.9 We publish a post-incident note for any outage longer than 30 minutes,
including the cause, in our journal at elchi.dev/en/journal and at
status.elchi.dev. We do this whether or not the cause was ours.

5. Your responsibilities

5.1 You are responsible for the security of your client secrets. A leaked
secret can be rotated in the console; we cannot recover one, because we store
only a digest.

5.2 You must register redirect URIs exactly. We reject wildcards and matching
is exact, which prevents a class of account takeover attacks but means a typo
produces a rejected sign-in rather than a silent redirect.

5.3 You must validate the state parameter and, where you use OpenID Connect,
the nonce claim. You must verify the iss parameter we return on every
authorization response. These checks live in your application; we cannot
perform them for you.

5.4 You must tell your end users, in your own privacy policy, that
authentication is handled by Elchi Studios and what data is involved. Annex A
lists what we process.

5.5 You must not use EAuth as the sole authentication for systems where a
failure would cause danger to life, physical harm, or comparable
irreversible loss.

6. Acceptable use and limits

6.1 You must not:

• use the service to authenticate access to unlawful material, or to material
  that sexualises minors, incites violence, or facilitates fraud;
• attempt to authenticate end users who have not agreed to use your
  application;
• present the hosted sign-in page in a way that misrepresents who operates it,
  or remove the "Secured by Elchi Studios using EAuth" mark;
• resell EAuth as your own authentication product without a separate written
  agreement;
• probe, load-test or attempt to circumvent the service's security controls
  without written permission. Responsible security research is welcome under
  Section 12.

6.2 Default limits, which the console shows for your application:

6.3 These are defaults, not caps on your success. If you outgrow them, ask.
Raising a limit for a legitimate application costs us a configuration change.
For an application without a client secret, token requests are also counted
per IP address, so requests sent in its name by others do not use up its
allowance.

6.4 We may suspend an application that materially exceeds its limits, is used
for the conduct in 6.1, or is generating traffic that degrades the service for
others. Where the situation permits, we contact you first. Where it does not,
we suspend and then contact you within one working day.

7. Your data, and leaving

7.1 You own your data and your end users' data. We claim no rights over it.

7.2 The console provides a full export of your applications, organisations,
end users and their metadata in JSON, at any time, without asking us.

7.3 Password hashes are included in that export in their original form, so you
can migrate to another provider without forcing your end users to reset their
passwords. We consider being able to leave a feature, not a risk.

7.4 If you delete an application, we delete its data within 30 days, except
where we are legally required to retain records. Audit log entries relating to
security incidents may be retained for up to 12 months.

7.5 If you stop using the service, we may delete an account that has had no
successful authentication for 24 months, after two email notices at least 30
days apart.

8. Our obligations regarding end user data

8.1 For end user personal data, you are the controller and we are the
processor. Annex B is our Data Processing Agreement and forms part of these
terms.

8.2 We process end user data only to provide the service, and on your
documented instructions.

8.3 We notify you of a personal data breach affecting your end users without
undue delay and in any case within 72 hours of becoming aware of it.

8.4 We do not use end user data to train models, to build profiles, or for any
purpose other than operating the service.

8.5 Sub-processors are listed at docs.elchi.dev/subprocessors. We give 30
days' notice before adding one, and you may terminate if you object.

8.6 The sub-processors that run our operation across several data centres
were added on 3 October 2026, the day the service moved there, without the
notice in clause 8.5. None was needed: on that day every application
registered with EAuth belonged to Elchi Studios, and no one outside Elchi
Studios had an account, so no one else's end users were affected.

9. Security

9.1 Measures we implement are described in Annex C. They include: passwords
hashed with Argon2id, refresh tokens and recovery codes stored only as digests,
signing keys encrypted at rest, mandatory PKCE, exact redirect URI matching,
and TLS for all traffic.

9.2 We have not undergone an independent security audit. We say this plainly
because the alternative is letting you assume otherwise. When an audit is
completed, the result will be published at docs.elchi.dev regardless of
outcome.

9.3 You must report a suspected compromise of your application to
security@elchi.dev without undue delay.

10. Liability

10.1 Nothing in these terms excludes liability for death or personal injury
caused by negligence, for fraud, or for anything else that cannot be excluded
under Swiss law.

10.2 Subject to 10.1, and because the service is provided free of charge, our
total liability to you for all claims arising from these terms is limited to
CHF 500.

10.3 We are not liable for indirect or consequential loss, including lost
profit, lost business, or the cost of migrating to another provider.

10.4 The service is provided "as is". We do not warrant that it will be
uninterrupted, error-free, or fit for a particular purpose.

10.5 You indemnify us against claims brought by your end users that arise from
your use of the service, except where the claim results from our breach of
these terms.

11. Self-hosting

11.1 EAuth can be run on your own infrastructure. Doing so is permitted and
encouraged for any deployment where availability or data residency matters
more than convenience.

11.2 Self-hosted deployments are governed by the licence accompanying the
software, not by these terms. We provide no support obligation for them.

11.3 You may not present a self-hosted deployment as being operated by Elchi
Studios.

12. Security research

12.1 We welcome reports of security problems. Send them to security@elchi.dev.

12.2 We will not pursue legal action against you for research conducted in good
faith that: stays within your own account and test data, does not access or
modify other users' data, does not degrade the service, and gives us 90 days
before public disclosure.

12.3 We have no bug bounty programme. We will credit you publicly if you want
that.

13. Termination

13.1 You may stop using the service and delete your account at any time.

13.2 We may terminate your account for a material breach of Section 6, giving
30 days' notice and an opportunity to correct the problem, except where the
breach is serious enough that immediate suspension is necessary.

13.3 On termination you have 30 days to export your data.

14. Changes to these terms

14.1 We will give 30 days' notice of a material change, by email and in the
changelog.

14.2 Continuing to use the service after a change takes effect means you
accept it. If you do not, you may terminate and export your data.

14.3 Every version of these terms remains published, with its date, so you can
see what applied when.

15. Governing law

15.1 Swiss law applies. The place of jurisdiction is Zug, Switzerland.

15.2 Nothing here removes the protection of mandatory consumer law in your
country of residence, where that applies.

Annex A: What we process

We do not process: IP addresses in persisted form, device fingerprints,
behavioural data, location beyond country, or anything derived from an end
user's activity in your application.

Annex B: Data Processing Agreement

This Annex is the agreement required by Art. 28 GDPR and the equivalent
provisions of the Swiss Federal Act on Data Protection (revDSG). It forms part
of the Terms of Service and needs no separate signature.

B.1 Subject matter and duration

We process end user personal data solely to operate EAuth for you, for as long
as your account exists, plus the retention periods in Annex A.

B.2 Nature and purpose

Authentication and authorisation: verifying an end user's identity, issuing
tokens, maintaining sessions, enforcing a second factor, and recording the
events needed to detect abuse.

B.3 Categories of data subjects

Natural persons who sign in to your application through EAuth, and natural
persons you invite to an organisation.

B.4 Categories of personal data

As listed in Annex A. We process no special categories of data under Art. 9
GDPR, and the service must not be configured to collect any.

B.5 Controller instructions

We process personal data only on your documented instructions. These Terms,
together with your configuration in the console, constitute those
instructions. If we believe an instruction breaches data protection law, we
will tell you and may suspend that processing until it is resolved.

B.6 Confidentiality

Everyone we authorise to process end user data is bound by a written
confidentiality obligation that survives the end of their engagement.

B.7 Security

We implement the measures in Annex C. We may change a measure, but not in a
way that lowers the overall level of protection.

B.8 Sub-processors

You give general authorisation for the sub-processors listed at
docs.elchi.dev/subprocessors. We give 30 days' notice before adding one. If
you object on reasonable data protection grounds within that period and we
cannot accommodate you, you may terminate without penalty and export your data.

Every sub-processor is bound by obligations no weaker than this Annex. We
remain fully liable to you for their performance.

B.9 Assisting you with data subject rights

If an end user contacts us directly with a request under Art. 15 to 22 GDPR,
we will not answer it ourselves. We forward it to you without undue delay,
because you are the controller and only you know the context.

The console provides the tools to answer such a request yourself: a full
export per end user, correction of stored fields, and deletion. Where those
tools are not sufficient, we assist you at no charge.

B.10 Assisting you with obligations under Art. 32 to 36

We assist you, taking into account the nature of processing and the
information available to us, with security of processing, breach notification,
data protection impact assessments, and prior consultation.

B.11 Personal data breach

We notify you without undue delay and in any case within 72 hours of becoming
aware of a personal data breach affecting your end users. The notice describes
the nature of the breach, the categories and approximate number of data
subjects and records, the likely consequences, and the measures taken.

We notify you even where we are not certain the breach affects you, because
that determination is yours to make.

B.12 Deletion or return

On termination, you have 30 days to export. After that we delete end user
data, including from backups within a further 60 days as backup rotation
allows, except where retention is legally required.

B.13 Audit

You may request the information necessary to demonstrate compliance with this
Annex once per calendar year, or after a breach affecting your data. Where a
recognised certification or audit report exists, providing it satisfies this
obligation. On-site audits require 30 days' notice, must not disrupt the
service, and are at your cost.

B.14 International transfers

End user data is processed in Switzerland and the European Economic Area only.
Switzerland benefits from a European Commission adequacy decision. We do not
transfer end user data to any other jurisdiction. If that ever changes, we
will give notice under Section 14 before it takes effect.

Annex C: Technical and organisational measures

These are the measures actually implemented, not a generic list. Each is
verifiable against the source.

C.1 Pseudonymisation and encryption

• Passwords hashed with Argon2id at 64 MiB memory, 3 iterations, 2 lanes, with
  a 16-byte random salt per password. Parameters are embedded in each stored
  hash, so raising the cost later does not invalidate existing accounts.
• Refresh tokens, authorization codes, API keys, organisation invitations and
  two-factor recovery codes are stored only as SHA-256 digests. None of them
  can be recovered from the database, by anyone, including us.
• Links sent to confirm an email address or to reset a password, and console
  invitation links, are 256 random bits stored only as SHA-256 digests. Each
  works once: a reset link for one hour, a confirmation link for a day, an
  invitation for seven days.
• Token signing keys and stored third-party credentials are encrypted with
  AES-256-GCM. The master key is held in the process environment and never in
  the database, so a database dump yields ciphertext only.
• All traffic uses TLS 1.3. The entire .dev top-level domain is on the HSTS
  preload list, so plain HTTP is refused by the browser before a request is
  made.
• Raw IP addresses are never written to request logs. Rate limits keep an
  address, an IPv6 address by its /64, only for the length of their window.

C.2 Confidentiality

• Role-based access control on every administrative route, with permissions
  declared as data and checked per project.
• Two-factor authentication is mandatory for every role that can change
  content or credentials.
• Administrative sessions are validated against the database on every request,
  so revoking access takes effect immediately rather than when a token expires.
• Administrative session cookies are httpOnly, Secure and SameSite=Strict, so
  no credential is reachable by script.
• Cross-site request forgery tokens bound to the session by HMAC on every
  state-changing form, including the consent screen and the account page, and
  a check that the form was sent from the same origin.
• Signing out through the sign-in service requires an ID token issued to the
  application for the signed-in person, or the person's own confirmation.

C.3 Integrity

• PKCE with S256 is required on every authorization request. There is no code
  path that issues a token without it.
• Redirect URIs match exactly, in constant time. Wildcards, fragments and
  plain HTTP outside loopback are refused at registration.
• Authorization codes are valid for 60 seconds, are single use, and are bound
  to the client, redirect URI and PKCE challenge. A replay revokes every grant
  issued to that client for that user.
• Refresh tokens rotate on every use. Presenting a rotated token revokes the
  entire chain, which is the standard detection for a stolen token.
• The implicit grant and the password grant are not implemented, so no
  configuration can enable them.
• ID token claims are filtered by granted scope.
• Every authorization response carries the iss parameter (RFC 9207), which lets
  a client detect a mix-up attack.

C.4 Availability and resilience

• Automatic database migrations with checksum verification. A modified
  migration aborts startup rather than running against an unexpected schema.
• Health endpoints checking each dependency separately.
• Every database write is committed on three servers, at three providers in
  two countries, before it is confirmed. Two application servers and two edge
  proxies, each pair at two providers in two countries, stand in for each
  other.
• Each service is checked continuously from the cluster, which alerts us when
  a check fails.
• Graceful shutdown that drains in-flight requests.
• Rate limiting with a sliding window. Authentication endpoints fail closed, so
  an outage of the limiter cannot remove brute-force protection.
• Every attempt at a password or a second-factor code is counted per IP
  address and per account before it is checked. A browser that has completed a
  sign-in to an account keeps a separate allowance, so repeated failures
  elsewhere cannot lock the account holder out.

C.5 Verification and evaluation

• Every credential change is written to an append-only audit log with the
  operator's identity.
• Structured request logging that records neither full IP addresses nor query
  strings.
• Automated tests covering the security rules, including nine redirect URI
  variants that have produced account takeovers at other providers.

C.6 Organisational measures

• Secrets are supplied through the service environment, readable by root only,
  and never committed to source control.
• Least privilege: the application runs as an unprivileged user with a
  restricted system call filter and a read-only file system apart from its
  data directory.
• No independent security audit has been performed. When one is, the result
  will be published regardless of outcome.

Annex D: Version history

Every version remains available at eauth.me/legal so you can see what applied
on any given date.