Hacker News new | past | comments | ask | show | jobs | submit login
Launch HN: Xkit (YC S18) – OAuth infrastructure as a service
138 points by tg3 11 months ago | hide | past | favorite | 54 comments
Hey HN,

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 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, 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




I've been looking for this for a while -- love it.

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")


Thanks!

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.


Pricing is an issue though. There is no tier for unfunded projects or the unfunded stage


We have a Developer plan that's free up to 10 users. Our Startup tier ($50/month) is intended for early stage projects without significant funding.

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.


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


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.


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


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


[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


> 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?


Yes, we absolutely sign contracts.


Yes, it’s a very hard sell. I wonder who is the real startup’s client? Some TLA I guess.


Maybe its just me but all I can see with your company is the tumblr extension xkit. https://chrome.google.com/webstore/detail/new-xkit/inobicegh... But i'm sure you've already discovered this :p


Yeah, Xkit is unfortunately also the name of a defunct Tumblr extension. We thought it was worth the (minor) collision.

Our github is https://github.com/xkit-co


Xkit is still actively maintained, albeit by a new team [1]. When I saw this, my first thought was "since when was Xkit a YC company," so definitely an unfortunate name collision.

[1]: https://new-xkit-extension.tumblr.com


Congratulations on the launch! I'll probably end up being a customer as our product will integrate with multiple external services (Salesforce, Intercom, Calendly).

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?


That's great! We support Intercom, Salesforce is coming soon, and I can look into adding Calendly too.

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 :)


I'd love to have some competition for Auth0 so this is good.

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.


We don't exactly compete with Auth0. Their focus is on how you authenticate users, where we're trying to make it easy to add integrations to extend your product with data or functionality from other products.

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.


How would the access token sharing will work between Auth0 and XKit ?


We have docs for it here: https://docs.xkit.co/docs/auth0-authentication

You can create a separate token specifically for Xkit or re-use an existing one.


If I'm not mistaken, OAuth 2 does not support multiple clients, but in this case the token authorized by a user ends up being known by 2 clients: Xkit, and Xkit's customer. What exactly is being shown in the consent screen the user accepts? Are users aware that they grant scopes to 2 distinct parties? Couldn't this be considered abuse by the SaaS Apps themselves?


Xkit acts purely as an agent for our customers, we don't make use of the access granted ourselves (and as mentioned in another comment, we're happy to sign contracts to that effect). As a result, the consent screen and what users are aware of is the identity of the party they're granting access to - the Xkit customer, not Xkit itself.

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.


great stuff. you do have a security problem, which you've acknowledged. so you won't get customers that actually are invested in security. fortunately, that's a scant few. you shouldn't waste efforts chasing them. just do the right [security] things, which will satisfy the 99% that aren't complaining. you will never ever be able to address the actual security conscious because, well, you can't.


Why wouldn't they? If some companies are that invested in keeping their data off the cloud (on which I agree that those are few and far in between) I could easily this as an on-prem instance.


there goes the business model, including the velocity. do you even startup, bro? sorry for that. a cheeky way to say, growth rate is critical in a funded business like this. an on-prem product is hard enough, an on-prem security critical product, whose entire reason for on-prem is the security aspect? it would kill them.

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.)


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?


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)


Congrats on the launch. Are there plans for SDKs in various languages or is this going to be JS only for now?

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.


We've had a handful of requests for native app support, so it's definitely something we'd like to do eventually, although we're more likely to start with Electron since it will be easier to port from our existing SDK.

That's good feedback on addressing the trust issue head-on, we'll work on that.


Maybe anecdata here but I read this post, had a need for your service, and moved on because it wasn't native. You may not be getting requests because people like me won't even bother looking past the fact it's JavaScript and will either roll our own or stick with the cloud vendors C++ SDKs.

If you do go native, please expose it through a C API and not C++ or Rust.


That's good feedback. We'll have to examine the native use-case a little more closely.


I think there's a huge, growing need for this and your sdk/api's seem very well-thought!

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!


Thanks for the kind words.

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!


Not trying to be critical or anything but the design really reminds me of those domain-name parking pages - like this: https://bit.ly/2DRc04H


Hmm, there is an unfortunate resemblance there. Thanks for the feedback.


The problem is that the box asking you to enter your email is the most prominent feature on the page before you scroll, which is reminiscent of those sites that try to get you to sign up for their newsletter before you can read the article.

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.


You can create an account and set everything up without ever talking to us if you prefer (that's the "Create a free account" link above the fold, https://app.xkit.co/sign-up).


Their terms:

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.


Could you write a one sentence summary on why I should care?


> Use at your own risk.

> "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


Is this a significant departure from the boilerplate of other similar products?


In IT outsourcing, yes. See this article from CIO magazine.[1] Key items:

"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...


Relying on a tool that offers no SLA is sketchy, especially if it’s going to offer an important component. If Jira goes down, not a big deal. But if part of my application breaks because of a third party tool I’m paying for to be up and functional, I’m gonna be mad.


It might be far less than ideal, but I was under the impression that's pretty standard. Unless you pay for an enterprise plan (and possibly extra on top of that depending on your SLA requirements) at best you'll get a billing credit for the downtime.


Does writing in CAPS makes it more law enforceable? This is a bit ridiculous...


Apparently there is a legal reason to use caps (which is, to make certain terms "conspicuous" such that a "reasonable person" ought to have noticed it)! https://www.termsfeed.com/blog/all-caps-legal-agreements/


Probably as simple as not having to debate if a letter is an I or an L or a 1.


First, congrats! Launching anything is hard, let alone after two pivots. I had a couple of questions and comments:

* 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!


Thanks for the note on the typo, I've fixed it.

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.


Awesome, thanks!


Trey - congrats on the launch! Love what you are doing and cant wait to see how you evolve it. Integrations are definitely a PITA and Oauth2 is a great starting point! Best wishes!


When are you getting a SOC2 audit? Can I deploy to my own private cloud?


Shoot me an email for more details on the SOC2 (trey@).

We're unlikely to support private cloud in the near term.




Applications are open for YC Winter 2022

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: