# EAuth Terms of Service **Version:** 1.10 **In effect from:** 9 October 2026 **Provider:** Krauss Software, sole proprietorship of Samuel Krauss, 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 **Krauss Software** ("we", "us"), the sole proprietorship of Samuel Krauss, seated in Oberägeri, Canton of Zug, Switzerland, trading under the name Elchi Studios. Krauss Software is not entered in the commercial register. Krauss Software is the counterparty to this agreement and Samuel Krauss, as its owner, is personally liable; 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. --- ## 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: | Limit | Default | |---|---| | Token requests | 120 per minute per application, adjustable in the console up to 600 | | Authorization requests | 60 per minute per IP address | | Registered applications | 25 per account | | Registered redirect URIs | 20 per 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. The account is deleted 30 days after you ask, and until then you can sign in, export your data and change your mind. With it goes everything that is only the account's: the applications it owns and their end users, its pictures, its sign-in history, every EMX organisation in which you are the only person, with its mailboxes, and the enquiries and support messages sent to us from its address. An EMX organisation in which others work stays theirs; your sign-in there ends. How to delete, product by product or all at once, is described at legal.elchi.dev. 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 | Data | Why | Retention | |---|---|---| | Email address | Identifies an end user, delivers sign-in | Until deletion | | Password hash | Authentication | Until deletion | | Display name | Shown in your application | Until deletion | | TOTP secret, recovery code digests | Second factor | Until disabled | | Session and refresh token digests | Keeping a user signed in | Until expiry or revocation | | Country code (two letters) | Showing a user their own sessions | 12 months | | Timestamps of sign-in attempts | Detecting abuse | 12 months | 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 stored and processed on our servers in Switzerland and the European Economic Area. Switzerland benefits from a European Commission adequacy decision, and the states of the European Economic Area are adequate under Annex 1 of the Swiss Data Protection Ordinance. One sub-processor is outside both. The mails EAuth sends (address confirmations, password resets, invitations) go out through Resend, Inc., a company in the United States. Resend sends them from its European Union region, but stores the recipient's address, the subject and the text of each mail in the United States. For data subject to the GDPR, that transfer rests on Resend's certification under the EU-U.S. Data Privacy Framework (Art. 45 GDPR), with the standard contractual clauses in Resend's data processing agreement in addition (Art. 46(2)(c) GDPR). For data from Switzerland, it rests on those standard contractual clauses as adapted for Swiss law (Art. 16(2)(d) revDSG). We transfer end user data to no other country outside Switzerland and the European Economic Area. 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 | Version | In effect from | Change | |---|---|---| | 1.10 | 9 October 2026 | This table is corrected: version 1.8 was never published and never applied, and the changes written for it took effect with 1.9. Clause 13.1 says what deleting an account deletes, including EMX organisations in which the account holder is the only person and the enquiries sent from its address. Every version is published at legal.elchi.dev. | | 1.9 | 6 October 2026 | Clause 1.4, the age requirement for registering an application, removed. Annex B.14 names the one transfer outside Switzerland and the European Economic Area, which already took place: mails sent through Resend, Inc., which stores them in the United States, and the safeguards that transfer rests on. The provider is named by its business name, Krauss Software, the sole proprietorship of Samuel Krauss (clause 1.1). With this version the changes written for 1.8 took effect: the sub-processors of the operation across several data centres are listed at docs.elchi.dev/subprocessors, added on the day of the move without notice since no one outside Elchi Studios was affected (8.6); the status page at status.elchi.dev is live (4.3, 4.9); Annex C.4 describes the replication and the checks in place, and no longer mentions push-based liveness reporting, which is not in place. | | 1.8 | Never in effect | Written on 3 October 2026 and never published, so it never applied: version 1.7 applied until 1.9 replaced it on 6 October 2026. It said that end user data was not transferred to any other jurisdiction, which was not correct, since the mails EAuth sends are stored by Resend, Inc. in the United States. It is published, marked as never in effect, so the history has no gap. | | 1.7 | 3 October 2026 | auth.elchi.dev redirects to eauth.me from the day of the move rather than after ninety days, since every application registered with EAuth belonged to Elchi Studios and no one else was affected (clause 2.4). | | 1.6 | 3 October 2026 | The service moves to eauth.me with the issuer `https://eauth.me`; auth.elchi.dev stays in service until 1 January 2027 (clause 2.4). Token requests adjustable up to 600 per minute, and counted per IP address for applications without a secret (6.2, 6.3). Annex C describes the email links, the form checks, sign-out and the sign-in limits that are now in place, and no longer mentions analytics, which EAuth does not have. The status page at status.elchi.dev is not live yet; until it is, outage notes appear in the journal (4.3, 4.9). | | 1.5 | 4 September 2026 | Clauses 3.4 and 3.5 tie the free commitment to the devs.elchi.dev listing and state that a paid service lives elsewhere with its own terms. | | 1.4 | 4 September 2026 | Clause 3.3 replaced. The reservation of a right to introduce paid plans contradicted the public claim that the service is permanently free, so the reservation was dropped rather than the claim. | | 1.3 | 3 September 2026 | The provider is stated accurately as an unregistered sole proprietorship. Corrects 1.2, which named a registered business before registration had taken place. | | 1.2 | 3 September 2026 | Superseded within a day. Named a registered business prematurely. | | 1.1 | 2 September 2026 | Added clauses 4.5 to 4.9: third-party failures, the distinction between availability and data protection liability, and what happens to sessions during an outage. | | 1.0 | 2 September 2026 | First published version. | Every version remains available at legal.elchi.dev/en/eauth-terms/versions so you can see what applied on any given date.