[HN Gopher] Launch HN: Xkit (YC S18) - OAuth infrastructure as a...
___________________________________________________________________
Launch HN: Xkit (YC S18) - OAuth infrastructure as a service
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(tm), 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
Author : tg3
Score : 75 points
Date : 2020-08-11 15:25 UTC (7 hours ago)
| jaywalk wrote:
| So I have to trust your company with valid access tokens for all
| of my users. No thanks.
| tg3 wrote:
| 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.
| ceejayoz wrote:
| > 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 wrote:
| Yes, we absolutely sign contracts.
| toomuchtodo wrote:
| 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 wrote:
| The access log is a great idea, we'll build that.
| rsweeney21 wrote:
| 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?
| jiveturkey wrote:
| 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.
| jdoty54 wrote:
| 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
| tg3 wrote:
| 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
| jkap wrote:
| 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
| NewEntryHN wrote:
| 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 wrote:
| 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.
| curo wrote:
| 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")
| tg3 wrote:
| 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.
| programmarchy wrote:
| 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 wrote:
| 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)
| jayp wrote:
| 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!
| maxcan wrote:
| 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 wrote:
| 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.
___________________________________________________________________
(page generated 2020-08-11 23:01 UTC)