28 ms·

Launch HN: Xkit (YC S18) – OAuth infrastructure as a service

138 points by tg3 6y ago

Hey HN, I’m Trey, the founder of Xkit (https://xkit.co https://xkit.co). Xkit helps developers build and maintain native integrations by turning OAuth for 25 of the most popular SaaS apps into a single API call that always returns fresh access tokens. I went through YC two years ago in S18 (and some of you may have seen our launch) with Sparkswap, a trust-minimized bitcoin exchange. After a year and half of building that product and building up a small but loyal following, I made the hard decision to shut it down. The audience for a trust-minimized service like Sparkswap was too niche and the regulatory costs were too high. It felt like the only way to stay in that business would be to compromise on some of our core principles (e.g. go after gambling behavior, play regulatory games), so I decided to stop working in crypto and move to FinTech more broadly. While doing customer discovery for a more traditional FinTech service, I encountered a pretty common request: integrations to the SaaS products my prospective customers were already using. As I was implementing OAuth with a slight variation for the 5th time, I realized I was re-writing code that thousands of other developers (probably including a bunch of people here) have already written (and debugged, and maintained). So I stopped working on that FinTech service (for those keeping score at home, yes that's two pivots) and started building a tool to let you outsource the pain of authorizing 3rd party apps with a particular focus on OAuth. From my perspective, for an integration to really be native, it will probably be faster and easier to just write some code instead of fighting against a GUI. But my goal was to make sure that nearly every line of code you write is actually for your integration, not authorization boilerplate. Two years and two pivots after I went through YC, I'm excited to share Xkit: the tool I wanted when I was building native integrations. Xkit is really two things: 1) An end-user experience for viewing and connecting 3rd party apps, and 2) An API for retrieving always-fresh access tokens. To make the first work, we establish a session with your user by piggy-backing on your existing authentication method (e.g. you send us their current JWT, and we validate it). From there, we can handle the OAuth dance: CSRF/state tokens, scope handling, callbacks, etc. For the end-user UI, we have a pre-built integration catalog to give your users an interface to browse your integrations, connect new ones, and repair broken ones. In fact, our integrations page (https://xkit.co/integrations https://xkit.co/integrations) is just our pre-built catalog rendered directly on our Webflow site. If you want more control over the experience you can do that too: our xkit.js library has all the tools for you to quickly build your own catalog without having to dig into OAuth. For the API, just call it with the ID of the user and the name of the service, and we return a non-expired access token. You can call it from any backend process: a cloud function/lambda, a microservice, or a monolithic server. This makes your integration code a lot simpler: one API call using one API key rather than storing, encrypting, and refreshing tokens. You can even get access tokens on the front-end if you have a valid user session, so if you're building a front-end only app you no longer have to even think about whether a specific provider implements PKCE (looking at you, Atlassian). We already work with over 25 of the most popular SaaS apps (Intercom and Zendesk added just last week!) and setting each one up typically just involves plugging in your OAuth credentials. Imagine you had a team at your company that were experts in all the weird (sometimes undocumented) ways that various providers extend the OAuth spec, and they built an internal service that does all that stuff The Right Way™, lets you move it out of your core applications, and still gives PM and Design flexibility on the integration experience. That's Xkit. You can get a free dev account (up to 10 users) to try it out here: https://app.xkit.co/sign-up https://app.xkit.co/sign-up, and if you send me an email (trey@) telling me that you came from this post, I'll give you 50% off your first year of the Startup or Pro plans. Thanks for making it through the wall of text. Would love to hear what you think! Trey

programmarchy 6y ago
I build a lot of integrations, so this looks useful. Would this allow you to do something like build the My Apps / My Connections screen found in Zapier?
- tg3 6y ago
  Yes, the integration catalog experience for a logged in user would be very similar to the My Apps screen in Zapier. (by default the styling is a bit different, but you can customize that e.g. if you prefer the list vs grid view)
jaywalk 6y ago
So I have to trust your company with valid access tokens for all of my users. No thanks.
- tg3 6y ago
  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 6y ago
    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 https://latacora.singles/2020/03/12/the-soc-starting.html

138 points by tg3 6y ago

programmarchy 6y ago

I build a lot of integrations, so this looks useful. Would this allow you to do something like build the My Apps / My Connections screen found in Zapier?

tg3 6y ago
Yes, the integration catalog experience for a logged in user would be very similar to the My Apps screen in Zapier. (by default the styling is a bit different, but you can customize that e.g. if you prefer the list vs grid view)

jaywalk 6y ago

So I have to trust your company with valid access tokens for all of my users. No thanks.

tg3 6y ago
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 6y ago
  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 https://latacora.singles/2020/03/12/the-soc-starting.html