keeping the state (e.g. progression) local until signed up

If the state is local how do I analyze whether the course is good or bad, how long does it take to answer questions, which ones were more difficult than others, stuff like that. Without server-side state those new users are basically non-existent wrt analytics. But if their state is on the server, making them regular users (but w/o credentials) seems just natural.

certain benefits of server-side state like cross-device sync won't be available until properly signed up

Exactly. That's the reason to sign up eventually. But I want to have usage data right from the start. If I can't see progress of new users, I can't see their problems - essentially my problems.

I understand that anonymous auth is probably not so small a feature for seemingly not so big a reason. After all, you can just force users to do regular auth. Anonymous auth is more about removing a hurdle to try your app: you launch the app and can start right away w/o unnecessary stuff. But at the same time, I'd like to process these users as my regular users, hence server-side.

Can this be implemented at all w/o making it part of TB core? Can I do it myself using TS API maybe?

These are all great points. Got it.

Can this be implemented at all w/o making it part of TB core? Can I do it myself using TS API maybe?

I can't think of a workaround from the client-side. Even if you randomly generated credentials (to fix up later), email addresses currently require to be verified to log in.

Now, you're asking specifically for the server-side TS runtime... technically anything goes. You can INSERT/UPDATE/DELETE users at will. Let me try to talk this through:

• You could have an endpoint that creates user-credentials: (random@ephemeral, randompw).
• You could then hand the credentials out or use them to mint tokens once and hand them out. This would allow users to re-sign in for the TTL of the refresh token.
• When you then wanted to upgrade them you could update the credentials. You should probably mark them unverified and re-verify the actual email.

Upgrading to OAuth might be a bit trickier. That said up and down-grading is something we might want to support anyway.

Alternatively, one could create a new user and then either:

• override existing user referenes with the new ID and delete the old one
• or override the old user with the new one, then delete the new one (one shouldn't just delete the old one and then override the PK on the new, since there may be foreign key triggers, e.g. deleting the old user may cascade deletions to other data).

Independently, cleaning up old ephemeral accounts should be fairly straight forward.

WDYT?

Thanks for the reply! I'm sorry for vanishing 😳 Felt uncomfortable answering w/o understanding how TB auth works under the hood. But then it took much longer than anticipated.

Equipped with the knowledge, I tried to imagine how anonymous users could be handled with custom endpoints. Below is a rough sketch. The question for now is just: could it be feasible in TB w/o being too impractical? I'd be glad to hear your opinions. The thing is long (I'm sorry) so no hurry whatsoever.

Registration

A user launches the mobile app which provides him with 2 choices:

1. Log into existing profile. Handled by regular /login and /oauth/provider/login endpoints.
2. (For new users) Begin using the app right away with an anon profile created by custom endpoint /anonymous/register.

/anonymous/register does:

• create new user with random email/password and verified = true
• create a profile for the user with anonymous = true
• mint and reply with new tokens for this user

The app receives the tokens and starts using them as usual. Some parts of the app check the anonymous profile flag and limit functionality (e.g. no leaderboards for anon users) suggesting creation of a full profile. To enforce those limits on the server, SQL access rules are used that check for profiles.anonymous flag.

Upgrade with email/password

A user decides to upgrade his anonymous profile using email/password auth. Handled by custom /anonymous/upgrade which does:

• obtain user from JWT and make sure it's an anon profile
• check that password is fine
• check that email is fine and does not already exist
• update email/password for the user and set profiles.anonymous = false (i.e. the profile is no longer anon)
• set verified = false and send verification email
• reply with the original JWT

Above, setting verified = false is not good b/c from that point an already logged-in user may be cut off from the app. Apps like Duolingo don't do that: you can freely use the app while unverified (with maybe some limitations). Can verification in theory be made a policy? Strict mode: you can't login unverified. Relaxed mode: you can login, verification just proves your credentials.

The alternative would be to implement the relaxed mode myself:

• always keep verified = true
• add field profiles.email_verified = false
• create custom /anonymous/verify_email/confirm endpoint which sets email_verified = true when the user follows the verification link

Upgrade with OAuth2 provider

A user decides to upgrade his anonymous profile using OAuth. Handled by custom /anonymous/oauth/<provider>/upgrade which does:

• obtain user from JWT and make sure it's an anon profile
• save JWT in a cookie (similar to oauth state for external provider)
• set custom callback /anonymous/oauth/<provider>/callback (see below)
• redirect to provider's authz endpoint

Later, provider calls /anonymous/oauth/<provider>/callback which does:

• obtain user credentials from provider's token endpoint using authz code as usual
• if user already exists in TB: ignore anon profile and reply with authz code for the existing user
• otherwise (for non-existent user):
• obtain user from JWT in the cookie and make sure it's an anon profile
• update the anon user with provider's user info and set profiles.anonymous = false
• reply with authz code for the updated user

Questions

Could this be feasible/practical? Or is it totally wrong/crazy maybe?

If it's feasible, this is probably can only be done with Rust API, right?

(repeat from "Upgrade with email/password" section) Can verification be made a policy with strict/relaxed modes?

A bit of a tangent, but e.g. Duolingo differs from TB in that it does not use emails from oauth providers. There, you can have both an email profile and also a Google-based profile backed by the very same email w/o conflict. Duo does this by generating random emails like [email protected] for oauth-based profiles. So email uniqueness is still kept. Could this in theory be made a policy in TB for oauth logins: either provider's email is taken or a random one generated with a template?

That said up and down-grading is something we might want to support anyway.

What do you mean by down-grading here?

I'm sorry for vanishing 😳

Not exactly the wording I would have chosen. I see you :) - FWIW, I also feel a lot more qualified to discuss this now with all the side-quests we had, since a lot of the implementation details had already drifted towards the back of my head.

A bit of a tangent, but e.g. Duolingo differs from TB in that it does not use emails from oauth providers. There, you can have both an email profile and also a Google-based profile backed by the very same email w/o conflict. Duo does this by generating random emails like [email protected] for oauth-based profiles. So email uniqueness is still kept. Could this in theory be made a policy in TB for oauth logins: either provider's email is taken or a random one generated with a template?

That said up and down-grading is something we might want to support anyway.

What do you mean by down-grading here?

Is this a feature or a workaround? As a general rule of thumb, I would always want to make sure that the stored info is correct. I would rather update the logic to account for new use-cases. Specifically:

• If there was an anonoymous bit, I would still leave the "email verified" bit as false.
• If we wanted to allow multiple accounts with the same email with and w/o OAuth, I would check for email and oauth properties. I don't think I would want to generate random, nonsense email addresses. At the end of the day, we should still be able to contact the user.

I'm wondering if duolingo allows that because they don't have the means to link an existing duolingo account with OAuth or unlink it from oauth (that's what I meant by down-grading, i.e. unlinking from oauth and "downgrading" to password-based login).

If it's feasible, this is probably can only be done with Rust API, right?

First of all we would have to migrate the database schema. At that point, we may as well consider it a first-class feature, in which case it probably would be consistent to implement it in Rust.

Could this be feasible/practical? Or is it totally wrong/crazy maybe?

I think we could make it work. I wonder if we should first support linking (upgrading) and unlinking (downgrading) existing accounts. It may or may not inform some of the "upgrading" and anonymous account to either password-based or oauth 🤷‍♀️

(Just for my own rememberance, a few details that popped to mind:

• "anonymous/ephemeral/opprtunistic" should be a flag in the DB but probably also in the token claims to facilitate the API authorization.
• Refresh tokens would probably need a different or longer TTL. It's the only thing that lets anonymous users re-auth. Once it's gone the account is dead.
• We would probably need some cleanup, e.g. delete ephemeral account that haven't seen a login in X months

)

Not exactly the wording I would have chosen. I see you :) - FWIW, I also feel a lot more qualified to discuss this now with all the side-quests we had, since a lot of the implementation details had already drifted towards the back of my head.

Really glad to hear

Is this a feature or a workaround?

I'd say it's an alternative to how TB handles emails. Thinking more about it, I can imagine problems with both approaches.

I'm wondering if duolingo allows that because they don't have the means to link an existing duolingo account with OAuth or unlink it from oauth

They have. In your duo account you 1) make sure you have the same email as in your Google account and then 2) toggle Google checkbox. I assume, then they get email from Google, compare with the current one, and, if they match, save Google's provider_user_id - this establishes the link.

As a general rule of thumb, I would always want to make sure that the stored info is correct.

Strictly, it wouldn't always be. Say I use gitlab to log into TB. TB saves my gitlab's email. Then I lose my email account and change gitlab to some new email. TB continues to use my old email.

I don't think I would want to generate random, nonsense email addresses.

As TB's creator, it's one thing. But as a developer of an app that uses TB as an engine, why not? After all, it's just an alternative way to handle emails. You either take email from a provider or not. Each scheme has its pros and cons. With TB scheme you grab the email, but that email may become stale, also some older account with the same email will prevent newer oauth login due to uniqueness conflict. With duolingo scheme you have to generate random emails, but oauth logins always succeed, although you could end up with 2 accounts fighting for the same email.

At the end of the day, we should still be able to contact the user.

Say I use gitlab to log into TB. TB saves my gitlab's email. Then my email is compromised and I change gitlab to some new email. TB continues to use my old compromised email. Would you now contact the user? While logging in with gitlab, did user wanted his email to be saved? In duolingo, oauth != email. If you want to set email for an oauth account, you explicitly do so. And then it's your problem if your email is compromised. If you want to link you email account with oauth, you also explicitly do so. But TB kinda sneakily grabs your email from your provider. E.g. github doesn't do that: when you sign-in with Google, github takes the email and leads you to the sign-up page where that email is shown and you must confirm account creation.

• "anonymous/ephemeral/opprtunistic" should be a flag in the DB but probably also in the token claims to facilitate the API authorization

Or maybe "guest" - a shorter name.

• Refresh tokens would probably need a different or longer TTL. It's the only thing that lets anonymous users re-auth. Once it's gone the account is dead.

Really good point. On a single device duolingo requires users to auth only once - at 1st start. Do they use refresh token rotation?

EDIT:

If there was an anonoymous bit, I would still leave the "email verified" bit as false.

Yep, email_verified bit is initially false and only set to true when an actual verification happens. This profile bit I imagined as a possible workaround for the current TB strictness where you cannot login until your email is verified. So you always keep _user.verified = true, but use profiles.email_verified for email verification. Could this strictness potentially be relaxed as a setting maybe? E.g. duolingo freely allows my email to be unverified. Basically, they do everything to not distract me from the app.

We should probably check on re-auth and update the address if it changed. You're right that there can be divergence until re-auth but for the lack of a more principled approach, I'd opportunistically consider this an edge-case.

Checking on re-auth is not reliable. You don't know when re-auth will happen. It may not happen at all (e.g. with token rotation). The user might want to have an email different from his oauth account's. The new email from oauth may conflict with some already existing in DB. The new email from oauth may not be verified at provider yet. It's much simpler to just take user's email once and declare it primary (like github) OR not take it at all (like duolingo).

Just so I understand you correctly, by different scheme you mean email vs username.

By scheme (or approach) here I mean whether to use email from oauth provider (TB) or not (Duolingo).

Sounds like github grabs it too but let's you add more (github let's you register N email addresses with your account). Copium aside, I don't want us to be sneaky.

Github grabs it, yes, but only to show next that this particular email will now be used as a primary email for the newly created account. Basically, what TB does behind the scenes.

If I'm not mistaken, users have to allow it with their external auth provider first.

Provider tells that TB will have access to their email.

Is there something else we could do better? We could certainly allow users to change their emails afterwards with validation and all.

Possibly already works

So I'd conclude that I'm fine with TB's existing email approach. Apart from random emails, duolingo's approach seems cleaner on separating email and oauth accounts. TB's seems more pragmatic. Each approach will have its edge cases. And adding duolingo way as an alternative, if badly needed, is a small change.

That's what I meant. When you enable guest auth we should check for (config.guest ? user.guest : false) || user.email_verified.
Adding a config option for this would be fairly easy. I do think that requiring validation...

With validation as an option: !validation_required || (config.guest && user.guest) || user.email_verified

I do think that requiring validation is probably the more sensible default for many use-cases

Quite probably yes

3. update stale email on oauth re-auth (if it wasn't changed by the user in (2)).

This I'm not sure (see above)

5. support different id scheme, e.g. username (unless folks want to use (4) to degrade email addresses from being a means of communication to simply a unique identifier)

This I'm not asking, was not my intention

It seems, we only disagree on some details how to model guest auth and maybe more ideologically what it means to ask for an email address

Probably less so this time

The new email from oauth may conflict with some already existing in DB.

As discussed, I'd be open to lift the uniqueness requirement to incorporate oauth

Frankly, this wasn't clear to me last time. You mean allow emails to not be unique? Could you elaborate a little then?

Right. We should have the primitives for users to implement what you call github's approach, i.e. prompt the user upon sign-up for their email.

If you mean google sign-in to github, they don't prompt, just show the email that's gonna be used. But they prompt for username.

I feel I'm starting go get it. You're thinking separating as in: email being used solely used as a unique identifier for auth vs as a means of communications otherwise.

Kinda yeah, you seem to hold on to email as a communication channel. With duolingo, email is more of a login identifier. You can register with an email and don't verify it. I have 2-year-old account and it's not verified. You can register with a fake email. I've registered with [email protected] and it works fine. BUT if you want to receive emails and such, you make sure to use a real email and verify it. Also, they require email uniqueness - no 2 accounts can have the same email.

I'm still grappling with duolingo. I don't understand why one wouldn't got full free-form username/handle in terms of separation.

They have unique usernames which can be used for login in place of emails. And they also have non-unique (public) names. E.g. if you state your public name as Joe at registration, then they generate you a username like Joe975793. Then, in your profile settings you can change that Joe795793 to something you like, provided it's unique.

I've tried a couple more things with duolingo:

• I had an old duo email account and now I did a google sign-in. They automatically linked that email account to google. Now I can log into it with email+password, google, and also username+password.
• I created a fresh duo account with google sign-in and now they grabbed my email, i.e. no random email was generated. Also, despite they grabbed a verified google email, they still sent a verification letter of their own.
• I have another duo account created a couple days ago with google sign-in and it has random email.

So it's not that simple as I thought.

All negotiable but I think we should decide on each dimension independently, e.g. loosening validation may make sense w/o guest accounts and guest accounts may make sense w/o loosened validation (especially if we were to allow non-email identifiers for auth).

👍

Frankly, this wasn't clear to me last time. You mean allow emails to not be unique? Could you elaborate a little then?

What I was trying to say is that I would prefer to update the uniqueness logic (after all it's ours) to check if email + oauth info is unique, rather than making up non-sense email addresses just to not change the uniqueness logic.

If you mean google sign-in to github, they don't prompt, just show the email that's gonna be used. But they prompt for username.

What I was trying to say is that we should have the right primitives to implement what makes the most sense for the specific experience: showing, prompting for a different email, prompting for a username, birthday, ...

Kinda yeah, you seem to hold on to email as a communication channel. With duolingo, email is more of a login identifier. You can register with an email and don't verify it. I have 2-year-old account and it's not verified. You can register with a fake email. I've registered with [email protected] and it works fine. BUT if you want to receive emails and such, you make sure to use a real email and verify it. Also, they require email uniqueness - no 2 accounts can have the same email.

I'm holding on to email addresses having a semantic meaning and implied behaviors. I still don't see, why someone who prefers unique identifiers would force them into the format of an email address. These days, it's almost a convention that user handles follow a "@username" format, I assume the @ is a relic of emails stripping the nonsensical part 🤷‍♀️

I'm impressed by you that you remember such old accounts. When I occasionally want to revive an old account from pre-password-manager times, I rely on email because I won't remember "foobar312a". (That said, while I do think that email is a feature even improving the users' experience for many apps, I will acknowledge that there are some where it's not... not sure about duolingo 🤷‍♀️ )

I had an old duo email account and now I did a google sign-in. They automatically linked that email account to google. Now I can log into it with email+password, google, and also username+password.

I can reason about that.

I created a fresh duo account with google sign-in and now they grabbed my email, i.e. no random email was generated. Also, despite they grabbed a verified google email, they still sent a verification letter of their own.

Interesting. I wouldn't mind.

I have another duo account created a couple days ago with google sign-in and it has random email.

That's exactly my worry. It seems they may have changed their stance and there is no fixing backwards, there's only patching up forwards. You're probably pointing out that they didn't magically update the email - I can reason about that. (I guess if we wanted account recovery, we should implement it explicitly, e.g. recovery email address)

So it's not that simple as I thought.

👍

For any configuration option that we offer, any accepted permutation should leave devs and users with a half-way sensible option.

What I was trying to say is that I would prefer to update the uniqueness logic (after all it's ours) to check if email + oauth info is unique, rather than making up non-sense email addresses just to not change the uniqueness logic.

What I was trying to say is that we should have the right primitives to implement what makes the most sense for the specific experience: showing, prompting for a different email, prompting for a username, birthday, ...

I'm holding on to email addresses having a semantic meaning and implied behaviors.

Right, got it. I was silly :)

I still don't see, why someone who prefers unique identifiers would force them into the format of an email address.

They probably have a non-nullable unique email column in DB just like TB. If they don't/can't have email, they generate a unique random one to satisfy constraints.

I'm impressed by you that you remember such old accounts.

I'm impressed too 😂

That's exactly my worry. It seems they may have changed their stance and there is no fixing backwards, there's only patching up forwards.

Probably I haven't understood them well. Let's just do what we already do, it's fine.

Guess we need some summary. The original question was "Is guest auth possible?". So it seems possible and it'd possibly look like:

1. Guest auth is controlled by config.guest setting (off by default).
2. It's implemented in Rust.
3. Add _user.guest to DB and guest claim to JWT.
4. Token rotation, or longer TTL, or other token flavor is used to keep guest accounts alive.
5. Cleanup: delete guest accounts that haven't seen a login in X months.

Other stuff that was discussed:

• Relax email verification requirement with a setting (verification is required by default).
• Link/unlink accounts to OAuth.
• Change email for oauth accounts (it works, I checked).
• Update stale email on oauth re-auth (but only if email wasn't explicitly set by the user).
• If oauth login fails due to email uniqueness conflict: (1) nudge the user to reset the password, sign in and link with oauth OR (2) auto-link user's email account with oauth like duolingo.
• Support different id scheme like usernames.
• Primitives to implement what makes the most sense for the specific experience: showing, prompting for a different email, prompting for a username, birthday, ...

They probably have a non-nullable unique email column in DB just like TB. If they don't/can't have email, they generate a unique random one to satisfy constraints.

You may be joking but I could totally see this to be not far from the truth 😅

Guess we need some summary. The original question was "Is guest auth possible?". So it seems possible and it'd possibly look like:

1. Guest auth is controlled by `config.guest` setting (off by default).
2. It's implemented in Rust.
3. Add `_user.guest` to DB and `guest` claim to JWT.
4. Token rotation, or longer TTL, or other token flavor is used to keep guest accounts alive.
5. Cleanup: delete guest accounts that haven't seen a login in X months.

👍

• To (4) I would say, different flavor or at least different key.
• Another big item is conversion, i.e. upgrading guest account to a full account, password or oauth.

Other stuff that was discussed:

* Relax email verification requirement with a setting (verification is required by default).

Totally up for discussion.

* Link/unlink accounts to OAuth.

We should probably have this at some point.

* Change email for oauth accounts (it works, I checked).
* Update stale email on oauth re-auth (if it wasn't changed by the user).

👍 If we consider explicit changing emails of oauth accounts a feature (which I think we do), we should probably not magically update emails at least not explicitly set ones.

* If oauth login fails due to email uniqueness conflict, update uniqueness requirements or nudge the user to reset the password, sign in and link with oauth.

Sounds good. Alternatively, what duolingo seems to do: auto-link 🤷‍♀️

* Support different id scheme like usernames.

I like the idea. That said, I'm struggling a bit to work out the details in my head. I used to have both and then removed usernames. I was maybe over-indexing on the eCommerce use-case where you need an email, thus requiring a username adds extra friction. Clearly, there are other use-cases where one would rather have usernames and no emails. It's certainly solvable but it quickly gets messy, at leas in my head.

* Primitives to implement what makes the most sense for the specific experience: showing, prompting for a different email, prompting for a username, birthday, ...

I like that a lot.

Thank you for the summary (and the discussion of course) 🙏 . To not just leave it at that, would you like us to follow through with the guest auth?

If we consider explicit changing emails of oauth accounts a feature (which I think we do), we should probably not magically update emails at least not explicitly set ones.

I forgot to mention that. Updated my list.

Sounds good. Alternatively, what duolingo seems to do: auto-link

Yes. Updated the list.

...would you like us to follow through with the guest auth?

Sure. I'll:

1. use my previous attempt as 1st draft
2. create a new thread
3. start with registering a guest user