Why One Sign-in Across My Sites

Nobody enjoys making a new account. One account that works across sites is the kind of sign-in I would want to use myself.

That is the short idea behind IDUnify. It is one account for the sites I run. This note explains why, how it works in plain words, and the lines it must never cross.

The problem with many accounts

Every new site asks for an email, a password and a verification mail. People reuse the same weak password, or forget it, or give up at the form. I build sites for communities and small teams. A sign-up form is the first thing a new person meets, so it should be as light as it can be.

What one account means

With IDUnify, a person signs in once with Google or an email address. The sign-in runs in its own window on the account domain, not on the site you came from. Each site you choose to sign in to receives a small set of facts: an account ID, an email, an email-verified flag and a name. A photo comes only with Google sign-in. Sites get this only when you choose to sign in there.

For the reader, that means one thing to remember and one place that checks it. You do not hand your password to every site. You sign in once, and the sites you pick get only the short list above.

The account itself is stored and checked by Firebase Authentication. For email accounts, passwords are stored as a hash that nobody can read. Pages use HTTPS, and sign-in tokens expire after one hour and renew on their own. These are the points I would check before trusting a sign-in myself, so I wrote them down in plain view.

Try it

This toy is a simulation with three fictional services and one fictional account. Open one service, sign in once, then open the other two. Nothing leaves the page.

The lines it keeps

A shared account can go wrong if it quietly becomes a way to watch people. So the rules come first.

• No ads and no data selling.
• The account does not tell one site which other sites you use.
• It does not see or store what you do on a site.

That keeps the account small on purpose. It proves who you are, passes on the short list of facts, and stays out of the way.

One front door

One account is a single front door, so it has to be a strong one. That is why I did not write my own password system. I use Firebase Authentication for the account and keep my own code to the parts that connect the sites. A proven service guards the door, and I focus on making the sign-in clear and short.

How it fits the rest of my work

The same account also opens a shared AI service. It keeps usage counts, not the text of questions and answers. If you want a sign-in like this for a product of your own, the platforms and SDKs service describes how I work, and the IDUnify section of the demo page shows it.

If you need this

Start with the smallest version: one identity provider, one sign-in window, and a short list of what each site may receive. Write the privacy lines before the code. I am happy to talk it through.

Talk about your project