
Launch HN: Xkit (YC S18) – OAuth infrastructure as a service - tg3
Hey HN,<p>I’m Trey, the founder of Xkit (<a href="https:&#x2F;&#x2F;xkit.co" rel="nofollow">https:&#x2F;&#x2F;xkit.co</a>). 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.<p>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.<p>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).<p>So I stopped working on that FinTech service (for those keeping score at home, yes that&#x27;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 <i>for your integration</i>, not authorization boilerplate.<p>Two years and two pivots after I went through YC, I&#x27;m excited to share Xkit: the tool I wanted when I was building native integrations.<p>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.<p>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&#x2F;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 (<a href="https:&#x2F;&#x2F;xkit.co&#x2F;integrations" rel="nofollow">https:&#x2F;&#x2F;xkit.co&#x2F;integrations</a>) 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.<p>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&#x2F;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&#x27;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).<p>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.<p>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&#x27;s Xkit.<p>You can get a free dev account (up to 10 users) to try it out here: <a href="https:&#x2F;&#x2F;app.xkit.co&#x2F;sign-up" rel="nofollow">https:&#x2F;&#x2F;app.xkit.co&#x2F;sign-up</a>, and if you send me an email (trey@) telling me that you came from this post, I&#x27;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!<p>Trey
======
curo
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")

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

~~~
tg3
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.

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

~~~
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](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](https://news.ycombinator.com/item?id=22607402)

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

------
jdoty54
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...](https://chrome.google.com/webstore/detail/new-
xkit/inobiceghmpkaklcknpniboilbjmlald) But i'm sure you've already discovered
this :p

~~~
tg3
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](https://github.com/xkit-co)

~~~
jkap
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](https://new-xkit-
extension.tumblr.com)

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

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

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

~~~
tg3
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.

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

~~~
tg3
We have docs for it here:
[https://docs.xkit.co/docs/auth0-authentication](https://docs.xkit.co/docs/auth0-authentication)

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

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

~~~
tg3
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.

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

~~~
Sebb767
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.

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

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

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

~~~
tg3
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.

~~~
qppo
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.

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

------
jamesmcintyre
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/](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!

~~~
tg3
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!

------
dharness
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](https://bit.ly/2DRc04H)

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

~~~
e_y_
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.

~~~
tg3
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](https://app.xkit.co/sign-up)).

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

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

~~~
tanduv
> 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

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

~~~
Animats
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...](https://www.cio.com/article/2438284/outsourcing-sla-definitions-
and-solutions.html)

------
mooreds
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/](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](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!

~~~
tg3
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.

~~~
mooreds
Awesome, thanks!

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

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

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

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

