It's come to my attention that StellarAuth is incredibly similar to SEP-0010 and as it does serve the same purpose I'm opening up a discussion on the differences between StellarAuth and SEP-0010. SEP-0010 has been around for awhile and it's to my shame for not doing better research around existing proposals and solutions to the authentication problem of Stellar. However after digging in and discussing with @nebolsin and @cballou I think there's still room for StellarAuth as a vehicle for getting SEP-0010 wider adoption and for adding the appropriate updates and changes which could make the proposal more secure and usable. To that end I'm going to dig in a bit into the internals of StellarAuth and point out the difference to SEP-0010 and why I've made the choices I have and why they may in fact be preferable to SEP-0010 as it stands today. Discussion is welcomed.

The largest difference would be that StellarAuth requires a transaction to be submitted to the ledger while SEP-0010 just verifies the transaction signatures. The reason for this I assume was to keep Stellar from being flooded with authentication transactions by only using the signature check functionality to verify identity rather than going the whole way to push a transaction into the network. While I understand the sentiment I A) don't think the volume would be large enough to make a difference, (if it were we'd have larger problems) and B) I think there's a lot of value to be gained by having login records embedded into the ledger. Immutable access logs are a powerful security measure and with tools like StellarGuard you can get TFA essentially for free. There's a reason we have blockchain and not just successful signatures, there's more to security than signing things.

Additionally there are several concerns I have with SEP-0010 when actually using it most significantly in the areas of additional signers and replay attacks.

SEP-0010 relies on the maxTimeout of the transaction to determine how long any given transaction can be used for verification and as long as you're under that timestamp you can use the same XDR to verify a session. This is probably an unwarranted concern though as the XDR must be successfully signed before it can generate a session but best practice would say once a challenge (transaction) has been used to generate a session it shouldn't be able to be used again ever in any case, currently it can. StellarAuth combats this be proactively generating a JWT which will remain invalid until the transaction it's associated with is submitted to the ledger. Each session then is tied individually and only to a specific pre-ledger transaction. To gain access to that session you must have access to the transaction and once it's been submitted the JWT goes live and replay attacks become a non issue as there's nothing to replay.

The second concern I encountered was specific to the implementation of SEP-0010 in the Evil Martians' demo in the fact that they bypass additional signers like StellarGuard. While this isn't specific to SEP-0010 and you could implement further checks on your own, it calls into question again the choice not to push transactions live to the ledger. In StellarAuth you would be blocked from authenticating until the transaction made it successfully to the ledger which will encompass all the checks including signers but also any future blocks which may be implemented. With so many potential pitfalls here and any given implementer of SEP-0010 left to handle this responsibly on their own it leaves SEP-0010 a little thin right now and opens the door for a service like StellarAuth to fill in the gaps and ensure all possible scenarios are covered.

One of the cool things about StellarAuth is its flexibility for far more than just login. Since the account acts as a sort of “role” you could create some pretty complex authentication scenarios. By just adding signers you can block authentication until all signers have added their signature. You can also create “teams” by adding all team members as signers with the same weight. Now any of them could sign into a single company account via that one Stellar account. Add custom metadata, home domains, assets, trustlines etc. and you’ve got room for a very robust authentication flow all from within the Stellar ecosystem. Some of this could work alongside SEP-0010 but because you aren’t actually submitting transactions to the network the functionality and checks for the authentication would have to be made on the implementers side rather than on the Stellar side greatly reducing the usefulness of the proposal as it stands today.

Ultimately it may come down to preference. Perhaps you don't want to flood the ledger with auth transactions or have to worry about the transaction fees. Perhaps you want to be able to authenticate accounts which don't even exist on Stellar or have been locked out due to high weights and a lack of appropriate signers or maybe bypassing additional signers is a non issue. It's possible but I don't think it's ideal or a good default. Both could be options but actual submissions to the ledger should at least be an option if not the recommended default in my opinion.

Apologies again if I've misrepresented or misunderstood SEP-0010 in any way, feel free to correct me and discuss further. Authentication via Stellar is an important yet tricky subject and the discussion is worth it to ensure we get it right.