SQRL and subdomains

[eplossl]

Ok, so I know I'm new to this and I likely have missed reading something that might answer my question here. That said, if I have, please feel free to refer me to the appropriate documentation and tell me to go RTFM.

I have a fan organization of which I am a part which has a homebrew membership database that we have written. We have also built it to be an OAuth provider for other subdomains on the same root domain so that we can use one password to log into the org membership database, the org forums, the org moodle instance, etc. Shortly after the launch party stream, I reached out to the head developer for the database (I'm part of the dev team as well), and suggested that we look into adding SQRL support for anyone interested in using it. He's concerned about a couple of things:

1. how hard will it be to add this support (I think not very, we just need to implement an SQRL server in our environment)
2. How can we then use it to provide login access to forums.group.org as well as database.group.org, and otherthing.group.org?

I may be misunderstanding how this works, but I think that I understand that SQRL has a different key for sub1.domain.com than it would have for sub2.domain.com & etc. Or can I have a key for domain.com that works for sub1.domain.com as well as sub2.domain.com, without any further ado? Since we are using OAuth now, would we likely have to do something strange to allow for the forums/etc. to validate login stuff for users attempting to connect?

If this is clear as mud, please let me know and I'll clarify a bit, as I feel muddled at the moment by my own words...

 

[PHolder]

You want one domain authentication, no? As in no matter where they are, they're authenticating to sqrl.domain.com and then redirected back to the service they came from? Using a single cookie that authenticates across all your domains which the SQRL server can access and provide is the simplest answer. This is basically single sign-on.

 

[eplossl]

Right. The issue I'm dealing with is that we're currently using the main database as an Oauth provider for the mobile apps and forums, and are wanting to also use it for connectivity to Moodle (testing system, for those not aware), though we currently haven't gotten that working due to some sort of bug that I don't really know the details of.

 

[PHolder]

Well... I'm not expert in OAuth, so I can't really help there. There is the sqrloauth.com site though, and it might work for you, but you would be outsourcing your authentication to another site. (I don't know if the author, @josecgomez , who is available here, is sharing his code or not.) You can engage with him in his own sub-forum if you wish. (Edit: Here's his sub-forum: https://sqrl.grc.com/forums/jose-gomezs-oauth-2-provider.50/ )

But if you're relying on OAuth this is probably because you don't have single signon really, you have a bunch of disparate tools and you're using OAuth to "glue" them together, in essence. SQRL would work better if you had one "master cookie" that was an authentication cookie for all your various parts. Then you could log in once with SQRL, get that cookie, and take it anywhere else you went and remain authenticated with it.

 

[shanedk]

I'm not sure why you'd need OAuth, unless you're not wanting to build a full SQRL implementation yourself.

The SQRL identity is whichever one is in the link/QR code. If you wanted, you could have separate users made for forums.group.org and database.group.org just by including the subdomains in the SQRL link. Or you could make it universal and just send group.org out in the SQRL link, and they all can use the same SQRL ID for the user. You don't really need to use OAuth to do the latter; just have the SQRL link have "group.org" as the domain name.

 

[ramriot]

Ok, so I know I'm new to this and I likely have missed reading something that might answer my question here. That said, if I have, please feel free to refer me to the appropriate documentation and tell me to go RTFM.

I have a fan organization of which I am a part which has a homebrew membership database that we have written. We have also built it to be an OAuth provider for other subdomains on the same root domain so that we can use one password to log into the org membership database, the org forums, the org moodle instance, etc. Shortly after the launch party stream, I reached out to the head developer for the database (I'm part of the dev team as well), and suggested that we look into adding SQRL support for anyone interested in using it. He's concerned about a couple of things:

1. how hard will it be to add this support (I think not very, we just need to implement an SQRL server in our environment)
2. How can we then use it to provide login access to forums.group.org as well as database.group.org, and otherthing.group.org?

I may be misunderstanding how this works, but I think that I understand that SQRL has a different key for sub1.domain.com than it would have for sub2.domain.com & etc. Or can I have a key for domain.com that works for sub1.domain.com as well as sub2.domain.com, without any further ado? Since we are using OAuth now, would we likely have to do something strange to allow for the forums/etc. to validate login stuff for users attempting to connect?

If this is clear as mud, please let me know and I'll clarify a bit, as I feel muddled at the moment by my own words...

OK, so at present you can put put a SQRL server on any fully qualified domain you like & have it offer SQRL links to be placed on any page on any other domain as there is no protocol restriction ( it can look a little like phishing to users if they are not made aware that forum.domain.org is ok to have a link like sqrl://sqrl.domain.org/... on it). However your existing single sign-on system works the sqrl server only needs to talk to that to authenticate users so it can manage sessions.

NOT in V1.00, but future versions of the protocol will most probably be more restrictive & browser based plugins may complain loudly if cross domain / subdomain authentication is attempted unless the SQRL server explicitly allows it.

 

[Alan M Cameron]

This question interests me as I am trying to emulate the forums' URL https://sqrl.grc.com/ with a subdomain of my main website alancameron.net using PHP version of SSP-API. In my admittedly primitive way of thinking I was planning to use a sqrl subdomain to provide the initial contact point, send the SQRL invitation to sign on using SQRL, but immediately redirect the client to the main domain with a special URI which handles the storing of the IP address and User Identity so that the next time my website sees the same IP and User Identity I can skip the sign in page and go directly to the main website pages. The response from @ramriot and others makes me think I may be wrong in my assumption/s would anyone care to comment?

 

[PHolder]

I think you design your system so you're comfortable with the user experience. I have no problem with the idea that users will accept authentication on a domain being delegated to sqrl.domain.com. The question will be if SQRL is your only option or not, because if it's not, what domain will be handling the non-SQRL authentication and can you resolve that in a way that feels unified for your users? I would prefer a system where all the user stuff went to one machine. It could be called anything semantically meaningful: simply domain.com, or something like auth.domain.com, profile.domain.com, user.domain.com, sso.domain.com, login.domain.com, etc. That one server could host a SQRL link to sqrl.domain.com (proxy it off to the SQRL server, for example) without setting off alarms in the user's view.