Launch HN: Xkit (YC S18) – OAuth infrastructure as a service
I’m Trey, the founder of Xkit (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) 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 applicati...
55 comments
[ 0.48 ms ] story [ 109 ms ] threadWe 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.
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
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
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?
Our github is https://github.com/xkit-co
[1]: https://new-xkit-extension.tumblr.com
But, what I'd love is an Auth service that does what you do for Office365 accounts. For some reason, nobody does this and, at least in Auth0, you have to manually set up O365 as a custom OIDC provider.
There is some significant overlap, for example with OAuth tokens, but I'd say they work together more than they compete.
As for Office365: that's one of the integrations that's coming up soon for us. There are a lot of Microsoft Graph integrations that we'd like to add.
You can create a separate token specifically for Xkit or re-use an existing one.
a) is SalesForce integration in the queue? Our primary use case is syncing customer records
b) i presume since you store the tokens, there's massive vendor lock-in right? just wondering how we might be at the mercy of your team (e.g., if you got acquired, raised prices, etc)
I think you're onto something big! At first I thought this was Auth0-like, so I suppose something more obvious in the landing page copy might help (e.g., "Build integrations into your SaaS apps in minutes")
a) Yes, I'm testing our Salesforce integration this week
b) While we don't have documentation for it yet, we support migration both in and out by loading and reading the current tokens for all of your users.
That's good feedback on our landing page, we've had the Auth0 comparison come up quite a bit, so we'll need to tweak it.
If you have a project that can't afford our Startup tier for some reason, shoot me a note (trey@) and I'll see what I can do.
on-prem doesn't even make sense for the 99% that aren't concerned about the security of it, as long as someone else is responsible for it.
lastly, the rate of implementation and tweaks to integrations for such a thing is going to be very, very high. there is just no sensible way to deploy this on-prem. (selling and supporting an on-prem product is very different from developing your own in-house solution.)
As a side note, OAuth2 explicitly supports multiple clients and in fact recommends it if you are using the clients in different contexts. Google implements this pretty effectively imo.
Now an off topic question: how did you stay motivated as a solo founder through 2 years and 2 pivots? Was it always just you, or did you have other co-founders that ended up leaving?
Re: staying motivated.
I was always a solo founder.
I think for me it starts with experience. I co-founded a startup when I was just out of college, and the ups and downs and challenges with staying motivated were by far the most important thing that I learned. Since then, I worked at two different startups and different stages and saw them go through good times (acquisition) and bad times (layoffs). So I think those experiences helped me keep myself level.
I also have a good professional and personal network of mentors, colleagues, fellow startup founders, family, and friends. My support system has been really important in keeping me going. YC has helped tremendously with this part.
And finally, I personally feel a lot of responsibility to spend my investors' money wisely. A lot of people believed in me and took a chance on me, so I feel I need to uphold my end of the bargain.
Long answer, and the full answer would probably require an hourlong therapy session, but that's off the top of my head :)
Personally I'd be annoyed having to enter my email to check out a demo; I don't want to receive emails about something until I have a better idea whether it would be useful.
THESE SERVICES ARE PROVIDED BY COMPANY ON AN “AS IS” AND “AS AVAILABLE” BASIS. COMPANY MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND, EXPRESS OR IMPLIED, AS TO THE OPERATION OF THEIR SERVICES, OR THE INFORMATION, CONTENT OR MATERIALS INCLUDED THEREIN. YOU EXPRESSLY AGREE THAT YOUR USE OF THESE SERVICES, THEIR CONTENT, AND ANY SERVICES OR ITEMS OBTAINED FROM US IS AT YOUR SOLE RISK.
NEITHER COMPANY NOR ANY PERSON ASSOCIATED WITH COMPANY MAKES ANY WARRANTY OR REPRESENTATION WITH RESPECT TO THE COMPLETENESS, SECURITY, RELIABILITY, QUALITY, ACCURACY, OR AVAILABILITY OF THE SERVICES. WITHOUT LIMITING THE FOREGOING, NEITHER COMPANY NOR ANYONE ASSOCIATED WITH COMPANY REPRESENTS OR WARRANTS THAT THE SERVICES, THEIR CONTENT, OR ANY SERVICES OR ITEMS OBTAINED THROUGH THE SERVICES WILL BE ACCURATE, RELIABLE, ERROR-FREE, OR UNINTERRUPTED, THAT DEFECTS WILL BE CORRECTED, THAT THE SERVICES OR THE SERVER THAT MAKES IT AVAILABLE ARE FREE OF VIRUSES OR OTHER HARMFUL COMPONENTS OR THAT THE SERVICES OR ANY SERVICES OR ITEMS OBTAINED THROUGH THE SERVICES WILL OTHERWISE MEET YOUR NEEDS OR EXPECTATIONS.
COMPANY HEREBY DISCLAIMS ALL WARRANTIES OF ANY KIND, WHETHER EXPRESS OR IMPLIED, STATUTORY, OR OTHERWISE, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT, AND FITNESS FOR PARTICULAR PURPOSE.
THE FOREGOING DOES NOT AFFECT ANY WARRANTIES WHICH CANNOT BE EXCLUDED OR LIMITED UNDER APPLICABLE LAW.
EXCEPT AS PROHIBITED BY LAW, YOU WILL HOLD US AND OUR OFFICERS, DIRECTORS, EMPLOYEES, AND AGENTS HARMLESS FOR ANY INDIRECT, PUNITIVE, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGE, HOWEVER IT ARISES (INCLUDING ATTORNEYS' FEES AND ALL RELATED COSTS AND EXPENSES OF LITIGATION AND ARBITRATION, OR AT TRIAL OR ON APPEAL, IF ANY, WHETHER OR NOT LITIGATION OR ARBITRATION IS INSTITUTED), WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE, OR OTHER TORTIOUS ACTION, OR ARISING OUT OF OR IN CONNECTION WITH THIS AGREEMENT, INCLUDING WITHOUT LIMITATION ANY CLAIM FOR PERSONAL INJURY OR PROPERTY DAMAGE, ARISING FROM THIS AGREEMENT AND ANY VIOLATION BY YOU OF ANY FEDERAL, STATE, OR LOCAL LAWS, STATUTES, RULES, OR REGULATIONS, EVEN IF COMPANY HAS BEEN PREVIOUSLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. EXCEPT AS PROHIBITED BY LAW, IF THERE IS LIABILITY FOUND ON THE PART OF COMPANY, IT WILL BE LIMITED TO THE AMOUNT PAID FOR THE PRODUCTS AND/OR SERVICES, AND UNDER NO CIRCUMSTANCES WILL THERE BE CONSEQUENTIAL OR PUNITIVE DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF PUNITIVE, INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO THE PRIOR LIMITATION OR EXCLUSION MAY NOT APPLY TO YOU.
> "SECURITY, RELIABILITY, QUALITY, ACCURACY" is not guaranteed.
Not something you want for a paid IaaS that deals with OAuth. I hope this is boilerplate that someone copypasta'd
"An indemnification clause is an important provision in which the service provider agrees to indemnify the customer company for any breaches of its warranties. Indemnification means that the provider will have to pay the customer for any third-party litigation costs resulting from its breach of the warranties. If you use a standard SLA provided by the service provider, it is likely this provision will be absent; ask your in-house counsel to draft a simple provision to include it, although the service provider may want further negotiation of this point."
In other words, many vendors like to find suckers who will sign their standard one-sided agreement, but there's usually room for negotiation.
[1] https://www.cio.com/article/2438284/outsourcing-sla-definiti...
* Are you looking to explicitly support other auth providers (I for one would love to have you support https://fusionauth.io/ -- full disclosure I work for them)? Or is the best path forward there to just use the Custom Token Issuer instructions?
* There's a typo here where it looks like the markdown hasn't been correctly processed: https://docs.xkit.co/docs/custom-catalog:
> If you want full control over how users interact with the Integration Catalog beyond what's available in [Self-hosting(doc:self-hosted-catalog), you can use our libraries or APIs to fully customize the experience.
* I'm trying to understand why someone would create their own catalog. Is that because they have their own suite of applications currently using OAuth for auth? So kind of a AWS Service Catalog play? Or is it more "I'll take care of adding this fiddly integration to XYZ service once so that all my developers can use this integration in the varied apps they are building"?
* What is the difference between using xkit and a tool like Zapier to handle SaaS integration? It looks like with xkit you have more control, including over the integration process. Why would I want to use something lower level like xkit?
Again, congrats on the launch!
I'm happy to add other auth providers to our docs. Shoot me a note (trey@) with the instructions and I'll add it in.
Many developers want to have their integration catalog match the look and feel of the rest of their application, or they have additional configuration for their integrations outside of what Xkit provides. In these cases, building their own custom catalog using xkit.js makes the most sense.
Zapier is a tool focused on the user of SaaS products (e.g. I want to connect my Google Sheets account to my Mailchimp account). Xkit is made for developers (e.g. I want the users of my brand new CRM tool to be able to pull in data from Google Sheets).
Many developers start out by just adding a Zapier integration and telling their customers to hook up to other tools themselves. However, many companies find that having those integrations be native (rather than going through Zapier) is helpful with both sales and activation, not to mention the increased level of control you have. We're helping developers build those types of integrations.
Why I ask is that I like the simplicity of Firebase as a back-end and attempted to use Google Auth for a desktop app (in C++). It was a pain to setup and still doesn’t work well.
It would save us a great deal of dev effort if there was a layer which could talk to Google and handle this for me.
P.S. The part about trusting a ‘startup’ with auth tokens may be worth addressing in some way on your website.
That's good feedback on addressing the trust issue head-on, we'll work on that.
If you do go native, please expose it through a C API and not C++ or Rust.
We're unlikely to support private cloud in the near term.
As for the design of your site, it definitely leaves me assuming it's just an auth service. I'd focus more on showing psuedo example interfaces / flows that your service powers. For instance, show an example client app on the left, your sdk drops in, on the right your integrations UX showing all the apps you can now integrate with.
I'm reminded of the copy & explanatory / storytelling on this site: https://www.freshpaint.io/
Instead of "Codelessly connect your site to your stack" they could've said "Enterprise-grade analytics with less configuration." But they went with a phrase that does more to highlight how their offering is new and brings a new form of value.
Maybe a/b test your one-liner? Some ideas:
"Add 25+ SaaS integrations to your app. We take care of the authentication."
"The first low-code, secure way to add SaaS integrations FAST."
"A new, low-code way to add 25+ SaaS integrations to your app."
"Less time re-implementing auth, more time building features."
"A faster, more secure approach to integrations."
Good luck!
I agree we need to re-think our home page a bit. We initially focused on "OAuth" to really get specific about what we do, but it's had the unfortunate side effect of making us seem like an auth provider.
I like the idea of specific examples, and your headline ideas are great!