AuthLocker

Privacy Policy

Effective 1 September 2026

In short. AuthLocker passes a verified identity from Google or GitHub to the application you are signing in to, and then forgets it. We never store the access token the provider issues, so we cannot read your mail, your repositories or your files. Profile data lives in our database for minutes, not months.

1. Who we are

AuthLocker is operated by Creative Robots Inc, a Delaware corporation with its registered office at 1007 N Orange St, 4th Floor #993, Wilmington, DE 19801, United States (“we”, “us”). This policy covers the service at authlocker.dev and its API. Questions and privacy requests go to privacy@authlocker.dev.

2. Two different relationships

It matters which one applies to you, because it decides who is accountable for your data.

  • Developers who register an OAuth client with us. We are the controller of the small amount of data that registration creates.
  • End users who sign in to somebody else's application through AuthLocker. Here we are a processor acting for that developer. They decide what happens to your profile once we hand it over; their privacy policy governs it, not ours. This policy describes only what happens while the data is passing through us.

3. What we collect

From people signing in

When you authorize a sign-in, the upstream provider returns a profile. We read exactly these fields and no others:

  • a stable user identifier issued by the provider
  • your email address and whether the provider has verified it
  • your given and family name, where the provider supplies them
  • your profile picture URL, where the provider supplies one
  • which provider you used

We request only the openid, email and profile scopes from Google, and read:user with user:email from GitHub. These are read-only and give no access to your content.

From developers

Client registration stores the application name you supply, its redirect URIs, an optional logo URL, and the credentials we issue. Registration and verification requests are rate limited using a keyed hash of the network address, never the address itself.

From email and phone verification

When a developer asks us to verify an address or number, we hold that value only for the life of the verification, alongside a hash of the one-time code. For SMS one-time codes we use Twilio Verify, which generates and checks the code on its own systems — the digits never reach our database.

4. What we never store

This is the design decision the whole service rests on, so it is worth stating plainly:

  • Provider access tokens and refresh tokens are discarded. We exchange the provider's authorization code, read the profile from the response, and drop the token. It is never written to storage, never returned to a developer, and never written to a log. There is no stored credential that could be used to reach your account at Google or GitHub.
  • We do not build profiles across applications. Each client receives a different, stable pseudonymous identifier for the same person, derived through a keyed hash. Two applications comparing notes cannot tell they are looking at the same user.
  • We do not use tracking cookies, analytics or advertising. The pages on this site set no cookies at all.
  • We never sell personal data, and we do not share it with anyone beyond the processors listed below.

5. How long we keep things

DataRetention
In-flight login request10 minutes, then deleted
Profile attached to an authorization codeValid 60 seconds; the record is deleted about 11 minutes later
Access token and its claims1 hour, then deleted
Email or phone verificationUntil it is used or expires, then deleted
Security and audit events30 days
Usage records for billingRetained, but they contain only truncated hashes — never an address or number
Registered client recordsUntil the developer deletes the client

Deletion of short-lived records is enforced both by a check at read time and by automatic expiry in the database.

6. How it is protected

  • Every profile held at rest is encrypted with AES-256-GCM under a key derived per record, bound to that record so a ciphertext cannot be moved to another one.
  • One-time codes, client secrets and access tokens are stored as hashes or encrypted values, never as readable text, and secrets are compared in constant time.
  • All traffic is served over TLS. Credentials are never accepted in a URL query string, because query strings end up in server logs and browser history.
  • Identity tokens are signed with ES256 and can be verified against our public keys at /oauth/jwks.

7. Who else processes the data

We use a small number of infrastructure providers:

ProcessorPurpose
VercelApplication hosting and delivery
MongoDB AtlasPrimary database
UpstashRate limiting and spend counters
Amazon Web Services (SES)Sending verification emails
TwilioSending and checking SMS verification codes
Google, GitHubIdentity providers, when you choose to sign in with one of them

These providers operate in the United States and the European Union. Where personal data is transferred out of the EEA or the UK, the transfer relies on the European Commission's Standard Contractual Clauses.

Where the GDPR applies and we act as controller, we rely on performance of a contract to operate the service for developers, and on legitimate interests to keep it secure and to prevent abuse — in particular fraudulent SMS traffic, which is a direct financial attack on the service. Where we act as processor, the developer whose application you are signing in to determines the legal basis.

9. Your rights

Depending on where you live, you may have the right to access, correct, export or erase your personal data, to object to or restrict its processing, and to complain to a supervisory authority.

If you signed in to an application through AuthLocker, that application holds your profile and is the right place to start — we will have deleted our copy within minutes. For anything we still hold, write to privacy@authlocker.dev and we will respond within 30 days. We do not charge for this.

10. Children

AuthLocker is a tool for software developers and is not directed at children. We do not knowingly collect personal data from anyone under 16. If you believe a child has provided us data, contact us and we will delete it.

11. Changes

We will post any revision on this page with a new effective date. Where a change materially reduces protection for personal data, we will notify registered developers by email before it takes effect.

12. Contact

Creative Robots Inc — privacy@authlocker.dev. See also our Terms of Use.