Firebase has this concept of anonymous authentication. In general how would you go about doing this in Vapor?
#Is it possible to do Anonymous Authentication with Vapor
muted junco
fading lagoon
Anonymous authentication is pretty simple. It uses the exact same access/refresh token pair as the other methods, the only difference is how it starts. The client says "gimme a user identity", and the server rolls a random UID
muted junco
At what point would you “connect” it to a user?
fading lagoon
Depends
Particularly on what you mean by connecting
It's a full-fledged user account the moment it's generated
But it might make sense to link it with an email/social/SIWA/etc account so the same account can be reused on other devices (or recovered on the same one after a browser reset)
To be fair without linking, it acts more like a persistent session ID
muted junco
Just in general how it works because I made an API for a client, and they saw this Firebase anonymous auth and were wondering how much it would take to make it. As opposed to how I coded it was by entering an email / password that’s saved to the db
fading lagoon
so basically, in a token-based email auth system with, you would have a "register" endpoint where the user submits their email and password, and you'd store those in the database (well, a hash of the password), and at the same time, generate, store and return a token that the client will include in later requests that identify the user.
a returning user would call a "login" endpoint with the email and password, you would verify those against the database; and if a match is found, generate, store and return a token.
anonymous auth doesn't have this register/login separation, there is only one endpoint: "gimme a token", which generates a user and a token, stores both, and returns the token. all the other endpoints that are token-authenticated behave the same.
Firebase Auth (and Auth0 for that regard) use not one, but two tokens. there's a short-lived access token (a JWT that is only valid for let's say 15 minutes, during which it's always trusted), and a refresh token that gets stored in the database. and there's a separate endpoint that takes a refresh token and returns a newly generated access token. for this token refresh endpoint, these is no difference between an email or an anonymous user, as both are expected to have a refresh token saved in the database.
muted junco
Thanks for the explanation! @fading lagoon is there a tutorial somewhere that shows this process?
fading lagoon
I don't think there is
muted junco
awwhh that's sad, thanks though!
dire sky
Just further on this, as @fading lagoon said, implementing some kind of session based anonymous identity as a proxy for what would otherwise be a persisted user identity in a non-anonymous context is probably quite trivial. Provided that you’re still storing those anonymous identities in a shared place (DB rather than in memory) to allow multiple processes to access the same information in cases of load balancing or if your server is restarted.
Where the magic of at least Firebase’s solution comes is in the eventual linking of anonymous identities with non-anonymous counterparts.
You may wish to think about how ownership of resources (a user’s content / interactions) is modelled to allow those relationships to be reassigned in an efficient manner.
Imagine if an anonymous user eventually linking their identity to a non-anonymous one required changing foreign keys on every single record they had previously created. That could be a right pain and perhaps even cause some unexpected behaviour for things like database update timestamp triggers.