| This are all great points, really appreciate it. Before I respond to the individual stuff, I'll define some of the functionality because you rightly point out that it might be a bit vague. At a high level, RoleUp uses OAuth or API keys to connect to different services and pull in the details of all the user accounts it finds. Depending on the service, each integration can:
- list accounts
- create/remove accounts
- list memberships of those accounts (any groups, teams, orgs, etc)
- list the roles of those accounts (developer, admin, owner, cloud-function:viewer, etc) Then those accounts are grouped by email into identities that you can manually adjust if you want. But it doesn't provide an identity service itself, I don't offer single-sign on. I just help with managing accounts and onboarding/offboarding people. In terms of security, all credentials are encrypted at rest, and in transit, and only decrypted by the application immediately before being used to call the target service. On top of that, it uses Google's KMS for key management, and all keys in the system are auto-rotated every 30 days. - In terms of cost, my initial thoughts were that it would be easier for the customer to manage if it's just an inexpensive usage-based plan, rather than having the whole thing randomly stop working when they cross the threshold of some tier. - That said, I see what you are saying. Firstly people expect a tiered model, and without that, it's a bit scary because they can't visualize the cost. Also, even if their whole shop is going to cost them only $10 a month in usage, they won't know that until they sign up and get the bill. So a free tier, with middle limited one, and upper unlimited would probably be best. - Definitely had considered the self-hosted option, but kicked that can down the road. It wouldn't be too difficult at this point though. It can work with basically any DB the way it's written and requires minimal resources. - Open source too is fine. If anything, maybe preferred for me tbh. - In terms of "auth for internal services", I think that's a point of confusion. I tried to summarize at the beginning. - And yeah, already on the demo idea. I need a lower barrier to allowing people to try it out. - Good point about the integrations, I was relying on people trying it to see how it works, but I can see why that's too high a bar. - And I thought about the security page, but had not gotten to it. It's something I put a lot of thought into, and I was going to do a sort of technical series of blog posts on the subject to show the architecture and the choices I made. But you're right. Even just a simple page explaining that everything is encrypted with auto-rotating keys would be useful. - Another thing I considered in order to deal with the security concerns, is to just 100% end-to-end encrypt all user data and credentials. It wouldn't actually require too much modification to how the system is designed, but it would mean that syncing could only happen if an admin was logged in and provided the key, or if they made their key available via a webhook or something. |