Published on 20 January 2026 under the IndieWeb category.

Artemis, the calm web reader I maintain, offers three methods of authentication: IndieAuth, email and password, and passkeys. IndieAuth is offered as a sign-in method because I want Artemis to allow people to use their domain names as their identities. Email and password authentication is offered because it is familiar. Passkeys are offered as a convenient way to sign in (in theory, at least; passkey authentication is not always intuitive).

Here is how the Artemis sign in page looks:

ALT

The Artemis login page showing three buttons: Log in with a Password, Log in with a Passkey, Log in with Your Domain.

In this blog post, I am going to talk about considerations for designing a service that offers both IndieAuth and email / password authentication.

I will specifically focus on the actions a user should be able to take to update their sign in information if they are signed in with only an email / password, only a domain name, or signed in with an account that has both a verified email / password and a domain name. The information in this post should help prevent a user from getting into a state where they cannot sign into their account because they do not have at least one verified authentication method set.

I will briefly touch on passkeys at the end of the post, but they are not the main topic I am going to address.

Domain names = User Profile URLs

Before I continue, please note that “domain name” in this post refers to a User Profile URL per the IndieAuth specification. I say “domain name” because many people use their own domain names (i.e. example.com) to sign into a service via IndieAuth, but, for the purposes of authentication, a User Profile URL is used, not a domain name This is an important definition and distinction to know. Per this definition https://example.com/ and https://example.com/username should be considered two separate accounts. There is nothing that says that the same domain name can’t be used for multiple accounts, provided different URL paths are used.

Furthermore, and importantly, profile URLs must be canonicalised per 3.4 URL Canonicalization in the specification. One thing that tripped me up at first was that I didn’t realise that if a specified profile URL did not have a path, / should be set as the path. This caused a problem where people who created accounts before I implemented the / default path for a profile URL without a path ended up with domain names that were technically invalid and have to be resolved manually.

My use of “domain name” in this post thus refers to a User Profile URL that has been canonicalized per the specification.

Account data structure

Artemis assumes the following premises as the foundation for its combined IndieAuth and email-based login system:

1. An account MAY have an email address and a password that they can use to sign in.
2. An account MAY have a domain name that they can use to sign in.
3. An account MUST have either a verified email address or a domain name they can use to sign in.
4. An account MUST only have one email address and domain name at a time.
5. An email MUST only be used for one account.
6. A domain name (again, User Profile URL) MUST only be used for one account (i.e. https://example.com cannot be registered with two accounts).

The third premise is essential to ensure users cannot get their account into a state where there is no means by which they can log in. I have emboldened “verified” because I don’t want users to detach a domain name from their account without having an email that they have verified they can access.

Given these premises, a user with only email / password login set up should be able to, at any time:

1. Know that they are signed in with an email address.
2. Change their email address.
3. Add a domain name.

A user with only IndieAuth-based login set up should be able to, at any time:

1. Know that they are signed in with a domain name.
2. Add an email address.
3. Change their domain name (I need to work on implementing this).

A user with both email / password and IndieAuth-based login should be able to, at any time:

1. Know that they are signed in with an account that has both an email / password and a domain name.
2. Change their email address.
3. Remove their email address (this means that your form field to change a user’s registered email should not have a required input if a user has a domain name set up with their account).
4. Remove their domain name, but only if they have a verified email address.
5. Change their domain name (I need to work on implementing this).

The “know that..” statements above were relevant when designing the Artemis account settings page. If a user is signed in with an email, I show a message that says they are signed in with email; if a user is signed in with a domain name, I show a message that says they are signed in with a domain name; if a user account has both a domain name and an email, I show that both are set.

While Artemis only shows a user’s identity name – email or domain name – in the account settings, a web service may want to display an identity in a navigation bar. In this case the service could choose what to display (i.e. domain name, name) – whatever is relevant to the service.

Improving the UX of domain name entry

Artemis uses the code in Aaron Parecki’s "Improving the HTML type="url" Field" blog post to automatically add a URL scheme when a user types a domain name in a URL field. The code automatically changes example.com to http://example.com. This is a client side UX enhancement; sever-side validation is still necessary.

Passkeys

Artemis allows an account to have zero, one, or multiple associated passkeys. At the moment, a user can only register to Artemis with a domain name or an email / password. Passkey registration is not supported (although this could technically be implemented). Because of these implementation details, a user can never get in a state where removing a passkey means that they do not have another method of authentication. I don’t plan to support passkey registration at the moment.

Conclusion

Supporting both IndieAuth-based login and email / password login means that people who have domain names (again, “User Profile URLs” per the IndieAuth specification) can log in with their domains, while people who do not have a domain name or whose sites do not support IndieAuth can sign in with an email / password.

There are complexities that come up specifically when you support IndieAuth and another authentication method, like email. I hope the lists above are useful if you are designing a service that supports IndieAuth and email / password authentication. The lists above should guide you toward building a service where users can update their accounts without getting them into a state where an account has no login method, or no verified login method.

If I have missed anything, please let me know so I can update this post!

Addendum: Retrieving an email address after IndieAuth authentication

If a user creates an account with a domain name, or updates their account to only allow domain-based sign in, Artemis will not have an email address to which it can send essential service-related communications. For instance, one day Artemis may send emails to users who have been inactive for several months to see if they still want to use their accounts or deactivate them.

With that said, IndieAuth client can request the profile scope in the initial authorization request per 5.3.4 Profile Information. This may include an email address for a user.

After a user has authenticated with their domain, Artemis could ask if they want to add the email sent in the profile payload to their account. The email would be displayed to the user so they can review it before deciding whether to add or not add the email to their Artemis account.

If the user adds the email to their account, a verification email would be sent so the user can verify their email address with Artemis.

With that said, if a user doesn’t want to add an email to their account, service-based communications could be provided within the application.

The idea to request profile information in the IndieAuth authentication flow came to mind after I drafted this blog post. I thought I’d note it here in case it is of interest to anyone, and as a bookmark for myself to come back to in the future.

Also posted on IndieNews

Reference this post

Please reference this post with a link to this page. I prefer to be called James (he/him) or James’ Coffee Blog. Learn more

URL for this post:

Go Back to the Top