THIS IS A READ-ONLY ARCHIVE OF THE SQRL PROJECT FORUM
SQRL OAuth 2.0 Provider | SQRL Forums

SQRL OAuth 2.0 Provider


josecgomez

Active member
Aug 6, 2018
25
12
Update 1/3/2019:
Fixed a few bugs including the ability to Lock / Unlock the SQRL account.

-----------------
Hi All
Over the last couple of weeks, I've been working on a functioning OAuth
2 provider that works with SQRL (Exclusively)

This should in my opinion allow millions of sites (if they chose to) to
adopt SQRL without having to change much on the backend.

I am finally in a pre-alpha release stage and wanted to share it with
everyone here and get some input and thoughts on it.

Following the SQRL moto, I've made it so you can remain pretty anonymous
and still use the service and of course there are really no Secrets to
keep. When you first login I will create a "random" account for you using an account generating API, it is up to you if you want to update change those account details or if you want to remain "anonymous"

It currently implements the basic Authorization Code grant flow and
works fairly well.

I'm planning on releasing it in Beta sometime this week to let whomever
wants to try it play with it.

I run a discourse forum like Leo so I've made sure that it will work
with Discourse out of the box so the community at twit should be able to
start using it (if Leo chooses to) pretty easily.

Anyways here's a quick demo of it in my discourse instance.
(Again, this is still in alpha / pre-alpha so if you go poking around
things may blow up lol but feel free to)

It uses the Ask facility (if available) to act as the Permissions
Granting Screen of OAuth, I thought it was a pretty neat way of putting
the entire permissions structure in SQRL

We also have the ability if we want to, to make each site have a unique
identity though I have that disabled right now, but if you think it
would be worth it, I can certainly make it default. The reason for
disabling it is that managing the accounts could get cumbersome.

I have to give a BIG thanks to @TechLiam and @Jeffa who have been my
sounding board over in slack while I slugged through the protocols and
Faught with the specs.

Also, a zillion thanks to @Paul F who let me use some of his tools like
SQRLView and his command line SQRLClient for troubleshooting.

Seriously SQRLView is an amazing piece of software and it should be
shouted from the rooftops for anyone writing and or dealing with SQRL.

Liam's DotNetCore Middle-ware is also a great piece of open source
engineering and it keeps getting better.

Cheers guys and thanks again, I look forward to some feedback.

OAuthSqrlDemo.gif


Thanks to @Steve for providing this space for testing, enhancements , feature requests and issues. I will be making a write up on how to use it and set it up etc shortly.
 
Last edited:
It looks like they all log in as sqrloauth.com. This could be a potential privacy issue as every website would end up with the same public key, leading to the ability to associate the user across websites.

Suggestion, if this is feasible: give each site its own special SQRL URL, such as sqrloauth.com/example.com. You'd have it in your .htaccess file to redirect all such URLs to the SQRL server. You'd also have the "x" option at the end (in this example, x=12) so that you would be creating a different public key for each website.
 
Suggestion, if this is feasible: give each site its own special SQRL URL, such as sqrloauth.com/example.com. You'd have it in your .htaccess file to redirect all such URLs to the SQRL server. You'd also have the "x" option at the end (in this example, x=12) so that you would be creating a different public key for each website.

Yes this is already possible ( the X option tied to the site's client ID) I just have it disabled for now for one reason, if you log in with separate identities to each site, then managing that account becomes difficult.

If you just browse to sqrloauth.com and Authenticate thre you'll get one ID

But maybe you want to modify the account for "otherSite.com" so if you have a separate ID for that site then how do you go about managing that account?

I could try and provide an endpoint for each site, but you'd have to know to go visit
sqrloauth.com/mySite in order to log in and manage that account.

Any ideas how that may work better?
 
I guess I could provide a drop-down / site-list on the home page to allow you to log in to that site specifically... Hmm
 
So first, great idea & thank you so much for doing this.

On the privacy leak front, having this one site manage all your non-SQRL supporting sites OAUTH grants does create a small deanonymization issue, assuming that is that you don't leak the SQRL public key as part of the grant object, in which case the leak multiplies.

I do like the idea of using the x= feature with the target domain following your sqrloauth.com/ to make a more unique Realm. Am I right in thinking that the generation of these can be automated for grant renewal?
 
Great work @josecgomez glad I was able to help and if you want the X param to be able to work properly for your use case here I might need to do a change to middleware but we can discuss that in Slack if you need it. For now, it's a good proof of concept and I think allows many more sites to start using SQRL without too much work a grate sell for a business.

Good job and keep the work up :)
 
  • Like
Reactions: josecgomez
The ability of someone to manage their linked accounts on your site is an interesting wrinkle. But if the login to sqrloauth.com (I'll call that the "master account") is separate to the actual site logins, then now all you're worried about is a site compromise.

Is there a reason for the site keeping that information in the open when the user isn't logged in to the master account? If not, you could have the site logins work normally, and then when the user logs into his master account, use SQRL's Index Secret to encrypt the information as to which accounts are his. That way, if there's a site compromise, an attacker still won't be able to get the data.

Just thinking out loud.
 
So first, great idea & thank you so much for doing this.

On the privacy leak front, having this one site manage all your non-SQRL supporting sites OAUTH grants does create a small deanonymization issue, assuming that is that you don't leak the SQRL public key as part of the grant object, in which case the leak multiplies.

I do like the idea of using the x= feature with the target domain following your sqrloauth.com/ to make a more unique Realm. Am I right in thinking that the generation of these can be automated for grant renewal?

It doesn't leak or provide the SQRL Public Key at any point during out, the OAuth Flow is actually fairly privacy aware, the server only ever sends back Auth Code and Auto Token that's the only data going out of the server to the individual sites.

The get user info end point does return some "user identifiable data" such as username, email etc and that could be used for tracking purposes.
 

I would try this one


I can help you set it up if you can't figure it out ( no inductions yet)
Thanks for the offer, I found a similar one "Omni Orange OAuth", it seems though that to allow enable OAuth SSO from somewhere not already enabled requires the server admin (me) to configure some things. That's a similar level of effort to adding SQRL to a site where there is a plugin already available & easier than if there is not.

Unfortunately since there still is a requirement for admin config then perhaps I was too hasty in trumpeting this new features praises.

I wonder if there is a SSO solution protocol that does not require special config for a site to support any source, I think OpenID is such a protocol, what does everyone think?
 
All solutions are going to require configuration on the server side (admin)
Open ID requires you to plug in the secret, client id, and configuration URL (similar to OAuth 2)

I'm not certain I understand what you are looking for?

If you enable for example a "Login with Google" style SSO then you need go to google create an app, get the client id, secret, and then go to your site and plug those values into the plugin for google auth... Same as OAuth 2, or SQRL or any other authentication method

I guess I'm not following what the expectation is for requirements from Admin Site.

Can you expand a bit as to what you are looking for? I'm not certain that such a solution exists.
 
  • Like
Reactions: anaman1
Hello. Thanks for the good work. A suggestion I have is: ADD the SQRL Logo to the clickable 'with SQRL' login button. I see that some of the other choices show a logo beside them and using a SQRL logo instead of the generic login 'arrow and button' graphic also reinforces it being a SQRL choice and could help with recognition and uptake by the public.
 
  • Like
Reactions: josecgomez
All solutions are going to require configuration on the server side (admin)
Open ID requires you to plug in the secret, client id, and configuration URL (similar to OAuth 2)

I'm not certain I understand what you are looking for?

If you enable for example a "Login with Google" style SSO then you need go to google create an app, get the client id, secret, and then go to your site and plug those values into the plugin for google auth... Same as OAuth 2, or SQRL or any other authentication method

I guess I'm not following what the expectation is for requirements from Admin Site.

Can you expand a bit as to what you are looking for? I'm not certain that such a solution exists.

Sorry,

I think the problem is that we are so often the controllers of our own sites we forget that for most sites out there this is not true.

As you say both OAuth & OpenID require configuration on a target site so they can be leveraged to offer SSO back to a source that has SQRL. The difference though is who gets to add that config. In the case of OAuth I believe it would be up to the target sites Admin to offer the OAuth feature to users for a specific site, while for OpenID it is the user that adds this themself for any site.

Thus if SSO by SQRL is to be viable to the most sites then having a site offer OpenID or similar is a better option than OAuth.
 
Anything that is not equivalent to having it built into a site is just a stop gap. I don't really feel we should spill much ink trying to choose the most perfect of the imperfect options.
 
Anything that is not equivalent to having it built into a site is just a stop gap. I don't really feel we should spill much ink trying to choose the most perfect of the imperfect options.

Perfection is the enemy of good enough...
 
@josecgomez how would this work if at some point a site that uses your OAuth Provider for example twit.community decides to stop using your provider and start using their own?
Would all the user accounts need to be recreated ? would an email and pass need to be associated with the account then remove SQRL auth and re-add it with the new SQRL OAuth Provider site?

Thanks.
 
@josecgomez how would this work if at some point a site that uses your OAuth Provider for example twit.community decides to stop using your provider and start using their own?
Would all the user accounts need to be recreated ? would an email and pass need to be associated with the account then remove SQRL auth and re-add it with the new SQRL OAuth Provider site?

Thanks.
Each site manages their own accounts. If they decided to stop using OAuth the accounts on each site remain the only thing that would have to happen is you re-associate your SQRL identity with that site or the new site.
But the original account on the site would remain
 
This may complicate things no? It was supposed to be two party. Me, and the website to authenticate to. Now there's Oauth? And with a name like that I won't be able to evangelize for sure! I tested twit.community... using my Samsung Galaxy S8+ docked in DEX so it happens in the Samsung internet brower. Log in. I saw SQRL center left; and QR center right. The phone's in the dock so QR is not for now. I clicked on the SQRL logo, I entered my SQRL password with success...
But rather than be logged into and present at twit.community... I suddenly on browser tab sqrloauth.com heading EditUserInfo, with fields to fill in.
Oauth wants all my info? who's Oauth? I was wanting to do login to twit!?
 
OAuth is not the preferred solution, it is just the currently available solution. The OAuth protocol requires information because of who originated it (FaceBroke and Google and big companies like that) and they gather info about you when you use it. The provider of the SQRL OAuth is not about this, and will provide the service without requiring real information.

The real solution is for all sites to integrate a native SQRL solution, but that will take time. OAuth support like this is a stopgap until then.
 
  • Like
Reactions: Ziran and ahauser