Everything someone comes up with has a threat model it fits within. How concerned are you, really, that you're going to be targeted by a mal-actor trying to steal your credentials. Normally, you take the best precautions, and get on with life--no need to live your life in fear, unless you do things that make you a target. I use a password manager, and have a unique password for everything. I would like to think one day I might not have to do this, as passwords might become a way of the past, but I already have this with SSH and look how that hasn't exactly spread like wildfire. Security improvements/changes take forever... And SQRL adoption, if it ever happens, is probably at least a decade off.
SQRL OAuth 2.0 Provider
- Thread starter josecgomez
- Start date
- Watchers 17
Hey guys @PHolder / @Steve etc so sorry about the ghost honestly I figured this was dead in the water. @Jeffa pinged me a couple of days ago, it is back up and running required a reboot and there was an external API I was using that has gone bust since the 3 years ago I looked at it.
Everything should be back up and running and I'm installing some monitoring tools to keep it going. I am more than willing to open source it too.
The issue with new registrations has been fixed also it was related to that API I mentioned (its an API that generates "random" user information cause I wanted to allow users to be anonymous. That has been fixed and it is now fully internally hosted so it shouldn't be a problem any more.
I will once again start maintaining a presence here and the twit forums, I'm also active in @Jeffa 's slack, and like I said if someone wants to contribute I can add you as contributor no issues there.
Everything should be back up and running and I'm installing some monitoring tools to keep it going. I am more than willing to open source it too.
The issue with new registrations has been fixed also it was related to that API I mentioned (its an API that generates "random" user information cause I wanted to allow users to be anonymous. That has been fixed and it is now fully internally hosted so it shouldn't be a problem any more.
I will once again start maintaining a presence here and the twit forums, I'm also active in @Jeffa 's slack, and like I said if someone wants to contribute I can add you as contributor no issues there.
agreed, unfortunately it doesn't exist (and probably never will) as much as I love/loved working on this project the reality of it is that without steve actively behind it, no official RFC and nobody large enough or influential enough evangelizing it isn't going to go anywhere.
Also having worked on it both written a client and a server side I can tell you this is way way way too complicated probably because it addresses all the possible flaws. Originally SQRL was simple, generate private key, sign up on site/create account, provide a signed token that the site can verify was indeed signed by you (Sign both tokens with the same key), and that's it.
But we (Steve and the rest of us) added so much complexity like ASK, CPS, LockOut, SQRL Only, and don't even talk to me about the process to replace a private key. That last one should have been as easy as sign in (with password or SQRL) click replace key (enter your password or secondary authentication mechanism 2FA), hand it a new token, #profit. It became a beast to implement. Perfect is the enemy of good enough, I believe the initial concept was gold, now it is too complex.
Hell even the storage block for keeping the identity is a nightmare that requires crazy encoding when a simply encrypted JSON object would have sufficed
BTW Leo's forum uses Discourse which is an awesome plugin friendly platform written in Ruby I would love to help write a native plugin for that unfortunately I don't speak that framework at all. If anyone does though I would be willing to help in any way I can to provide a native SQRL plugin.
Last edited:
I think sqrloauth.com helps adoption. It allows users to use SQRL where they could not otherwise. From the user perspective the main friction is the initial setup. Getting users, any users, with SQRL id’s helps in the long run.
What needs to happen is for something new to adopt SQRL from day one. Say someone had a great idea for "PodCast Maker Extreme Pro" that all the YouTuber's just HAD to have. If it came with a SQRL option, there would probably be enough of them (the "influencers") that would feel the need to be on the cutting edge that it would blow up over night.
It might work but I think in some ways SQRL is stuck between a rock and a hard place.
Anyone that is starting something new will crave new signups more than anything and they are unlikely to put their potential users thru the “NEW ID” process. (Unless their service specifically needs something that only SQRL can offer of course)
Anyone with an existing user base that they are already monetising will not want to lose signups by doing something new. (With the same caveat above of course)
One thought I did have was running something like a kickstarter or indie-go-go to raise an obscene purse and then giving it all back to the backers via some form of “lottery” that can only be entered with a SQRL ID.
On second thought entry should not me restricted to backers. The logic being that the more folks that hear about it and create an ID the better this help spread the word that SQRL exists and what it can do and also increases the pool of people that already have an ID.
Last edited:
Take a tip from the cryptocurrency community. The tactic wasn't to get firms to take crypto exclusively, just to have it as an option alongside regular payment methods. Adoption is slow, but progressing. SQRL could be the same way.
Also, crypto wallets have shown better ways of doing things like master key management. If what Jose says is a real problem, there are alternatives that can be implemented.
Also, crypto wallets have shown better ways of doing things like master key management. If what Jose says is a real problem, there are alternatives that can be implemented.
I agree that slowly sprinkling SQRL around is a good way to go, but we need to go back and have an RFC written one that addresses some of the issues I mentioned above (if needed) and provides a standard implementation for it RFC style.
That storage block is kind of criminally complex and could have been easily done as a simple json/xml document that is encrypted with the master password / rescue code
The communication between client and server is all done using x-www-form-urlencoded format is which again mostly outdated and could easily be replaced by standard RESTFul methods and a RAW/JSON Request Body
Simple / little stuff that will make a HUGE difference when trying to implement this in 100 different languages and frameworks.
I think that the reason it is all so small is to make sure it fits int he QR code backups.
On the wire I totally agree.
There are many ways of getting the same job done that would be more native to a modern dev. Steve likes small.
In the end I just treat it as an interchange format.
If I had the knowledge and ability, I'd spearhead this myself. But I'd gladly assist anyone who could.
Yeah, that was headed up by Adam Conley. I was relying on him for things like the major formatting and how the whole thing works. I was just contributing copy. When he disappeared, I didn't know how to continue working with it.
I still have it if someone else wants to join in. I think though, it might have to be restarted from scratch.
I still have it if someone else wants to join in. I think though, it might have to be restarted from scratch.
Hi @josecgomez,
To use you server what values should I be using to for:
I was planning on documenting how to use your server with the built in OAuth2 clients that exist in a lot of software, but I could not find any details if these URLS for your server written down anywhere.
Can you help please?
To use you server what values should I be using to for:
Code:
user_info_url:
authorize_url:
token_url:I was planning on documenting how to use your server with the built in OAuth2 clients that exist in a lot of software, but I could not find any details if these URLS for your server written down anywhere.
Can you help please?