4 ms·

Services like this need an easy way to allow people to use their own domain names, and we need to lower the barrier of entry to individuals registering domains

Services like this need an easy way to allow people to use their own domain names, and we need to lower the barrier of entry to individuals registering domains and setting up HTTPS. Imagine a SaaS that sells domains, then provides and easy (and open) API for delegating control over subdomains using OAuth2. So I sign up for sheetui, and during the registration process they redirect me to a namecheap.com (where anderspitman.net is registered) OAuth2 server, I grant them control over sheetui.anderspitman.net, and they can now host there on my behalf. sheetui.com also shouldn't have to deal with TLS certs. Why doesn't namecheap.com handle that for me? HTTP requests can be proxied through something like ngrok which again uses OAuth2 tokens for auth. Now we have a stack where people can securely host websites from there phone.

tjchear 6y ago
This is an interesting use case (the delegation of subdomain). Sounds like something that can be built atop Amazon Route 53. Have you seen this need come up a lot?
- anderspitman 6y ago
  I think it would be helpful for decentralizing things, ie less necessary for the web we have than the web I want. For example I'm working on a project right now that's ideal for self-hosting, but I really want to encourage people to use their own domain names, and registering them and handling HTTPS is a rather large barrier.
- hanniabu 6y ago
  Personally I would love the ability to show data on my website using a Google sheet where others less technical can contribute to (open source projects) as opposed to editing json files. It would only make sense for me to do it if it's still hosted under my domain though.
vertex-four 6y ago
Hahaha oh wow, I had a design document for this last year, down to the details. OAuth2 doesn't quite fit the bill without a little modification, unfortunately.
- anderspitman 6y ago
  Would love to discuss it. I think this could be a solid business. I have little interest in building it myself, but may have to in order to make my other projects easier to self-host. I keep bringing it up hoping to find out it already exists. What issues did you run into with OAuth2? Are you open to sharing your design doc?
  - vertex-four 6y ago
    If you want to contact me, I'm shell@alterednarrative.net on email and XMPP. I'll try and find whether I still have the design notes, but doubt it; I've been through a couple of laptops since and lost a lot. One of my goals was that the flow could start from a service provider - you type in the domain name you want the service to be bound to on the service provider's website, and it goes from there. If you were to use OAuth2 at this point, there's no existing client ID/password, and allowing public dynamic client registration leads to DoS potential as someone could easily register a practically infinite amount of clients and fill up disk space. So you want a custom flow which winds up, at the end, with the consent of the domain owner, returning OAuth2 credentials to the service provider. This flow is fairly complex to spec out in a way that doesn't have subtle security issues (e.g. this initial flow can't trust much info from the service provider which could be something akin to a phishing scam, returning to the service provider on error has to be done carefully because of risk of being used in an open redirect chain, etc). After that it's mostly a case of supplying auth keys for RFC2136 so the service can manage its delegated domain, handling credential rotation, and properly handling edge cases like either the service provider or the domain management system losing track of state, or the domain being lost/transferred to another entity. Honestly I'd like to build something like this for my own projects, and might do so as a weekend project soon, esp since it's just been validated as something useful. :D
    - anderspitman 6y ago
      I'll shoot you an email, and we can talk more if you do end up working on this. I'm not a big fan of pre-registered clients in the first place. Ideally any client should be able to talk to any OAuth2 server that speaks the same profile, ie endpoints and scopes. Aaron Parecki describes a way to allow "anonymous" clients here[0]. As I understand that's how IndieAuth is implemented. But I'm still relatively new to OAuth, and I don't doubt there could be subtle security issues. Do you have any thoughts on that? [0]: https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web
martin-adams 6y ago
Rather than leaving all this to the many registrars, what about a SaaS (let’s call it usemycustomdomain) that allows you to point a CNAME record for a subdomain to it, then when you sign up to an app that supports custom domains, you can oAuth2 to usemycustomdomain. Then usemycustomdomain can do the SSL management and termination and proxy the traffic to different SaaS products. It could even support custom URLs on a domain.
- anderspitman 6y ago
  That would make it more flexible, but in my mind the whole point of this thing existing is to take the pain out of having a custom domain, and making the process accessible to more people. Part of that would include handling registration and hiding all the DNS nonsense unless you really want to fiddle with it.
scurvyyy 6y ago
This is very interesting. I'm trying to understand the use case a little better. Does it seem related to the emerging standard on delegated credentials for TLS (https://blog.cloudflare.com/keyless-delegation/ https://blog.cloudflare.com/keyless-delegation/)?

tjchear 6y ago

This is an interesting use case (the delegation of subdomain). Sounds like something that can be built atop Amazon Route 53. Have you seen this need come up a lot?

anderspitman 6y ago
I think it would be helpful for decentralizing things, ie less necessary for the web we have than the web I want. For example I'm working on a project right now that's ideal for self-hosting, but I really want to encourage people to use their own domain names, and registering them and handling HTTPS is a rather large barrier.
hanniabu 6y ago
Personally I would love the ability to show data on my website using a Google sheet where others less technical can contribute to (open source projects) as opposed to editing json files. It would only make sense for me to do it if it's still hosted under my domain though.

vertex-four 6y ago

Hahaha oh wow, I had a design document for this last year, down to the details. OAuth2 doesn't quite fit the bill without a little modification, unfortunately.

anderspitman 6y ago
Would love to discuss it. I think this could be a solid business. I have little interest in building it myself, but may have to in order to make my other projects easier to self-host. I keep bringing it up hoping to find out it already exists. What issues did you run into with OAuth2? Are you open to sharing your design doc?
- vertex-four 6y ago
  If you want to contact me, I'm shell@alterednarrative.net on email and XMPP. I'll try and find whether I still have the design notes, but doubt it; I've been through a couple of laptops since and lost a lot. One of my goals was that the flow could start from a service provider - you type in the domain name you want the service to be bound to on the service provider's website, and it goes from there. If you were to use OAuth2 at this point, there's no existing client ID/password, and allowing public dynamic client registration leads to DoS potential as someone could easily register a practically infinite amount of clients and fill up disk space. So you want a custom flow which winds up, at the end, with the consent of the domain owner, returning OAuth2 credentials to the service provider. This flow is fairly complex to spec out in a way that doesn't have subtle security issues (e.g. this initial flow can't trust much info from the service provider which could be something akin to a phishing scam, returning to the service provider on error has to be done carefully because of risk of being used in an open redirect chain, etc). After that it's mostly a case of supplying auth keys for RFC2136 so the service can manage its delegated domain, handling credential rotation, and properly handling edge cases like either the service provider or the domain management system losing track of state, or the domain being lost/transferred to another entity. Honestly I'd like to build something like this for my own projects, and might do so as a weekend project soon, esp since it's just been validated as something useful. :D
  - anderspitman 6y ago
    I'll shoot you an email, and we can talk more if you do end up working on this. I'm not a big fan of pre-registered clients in the first place. Ideally any client should be able to talk to any OAuth2 server that speaks the same profile, ie endpoints and scopes. Aaron Parecki describes a way to allow "anonymous" clients here[0]. As I understand that's how IndieAuth is implemented. But I'm still relatively new to OAuth, and I don't doubt there could be subtle security issues. Do you have any thoughts on that? [0]: https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web

martin-adams 6y ago

Rather than leaving all this to the many registrars, what about a SaaS (let’s call it usemycustomdomain) that allows you to point a CNAME record for a subdomain to it, then when you sign up to an app that supports custom domains, you can oAuth2 to usemycustomdomain. Then usemycustomdomain can do the SSL management and termination and proxy the traffic to different SaaS products. It could even support custom URLs on a domain.

anderspitman 6y ago
That would make it more flexible, but in my mind the whole point of this thing existing is to take the pain out of having a custom domain, and making the process accessible to more people. Part of that would include handling registration and hiding all the DNS nonsense unless you really want to fiddle with it.

scurvyyy 6y ago

This is very interesting. I'm trying to understand the use case a little better. Does it seem related to the emerging standard on delegated credentials for TLS (https://blog.cloudflare.com/keyless-delegation/ https://blog.cloudflare.com/keyless-delegation/)?