[tg3]

That's an understandable position to take - these are sensitive pieces of information that provide a high degree of access.

We take the security side of this equation very seriously. All the tokens and credentials are encrypted (both at the database level and the field level) and access to keys and production systems themselves are tightly controlled. Our APIs are designed to prevent inadvertent leaking of credentials (e.g. it's impossible to retrieve client secrets from the front-end) and we have in place best practices to prevent things like XSS and CSRF.

But like many cloud providers, yes you have to trust us.

In the near future we'll work on some more public things (like a SOC 2) to make our specific policies easier to trust.

[toomuchtodo]

Please consider some sort of access log for all activity around the secrets you’re managing, exposed to users in their account. Also consider a way to revoke all secrets/tokens at once with a privileged (MFA authorized) user action.

Best of luck, I think this product has a lot of value ahead based on the pain points addressed.

EDIT: This might also be of use before your SOC 2: https://latacora.singles/2020/03/12/the-soc-starting.html

[tg3]

The access log is a great idea, we'll build that.

[grinich]

[Shameless plug] Happy to help you with that with WorkOS :)

Here's our HN launch: https://news.ycombinator.com/item?id=22607402

And some more info on the Audit Trail feature: https://workos.com/features/audit-trail

[ceejayoz]

> But like many cloud providers, yes you have to trust us.

In Facebook's case, I believe I'd have to explicitly sign a contract with you. https://developers.facebook.com/policy/ #6, #7, and #8. Is this supported?

[tg3]

Yes, we absolutely sign contracts.