Deprecation of JWT signed embeds [WALKED BACK]

@flamber, Metabase now has me very concerned and I would like some clarification.

Aug 4, 2020 Blog Post: How to embed Metabase in your app…

Under “Metabase embedding options -> Signed embed” it reads “…iframe secured by a signed JSON Web Token (JWT). Though this option will be deprecated soon…”

Deprecated from what Metabase v0.3x.x forward?
What about older Metabase versions for those who are dependent on JWT signed embeds?
Open source alternatives going forward for embedding secured dashboards without full app embedding (or is this w/SSO coming to the open source edition eventually)?

For use cases based on JWT signed embeds this is a very concerning development.

@AndrewMBaines, I hate to ping you but how does this affect you? As I understand from our past conversations on this forum (thank you very much by the way, you’ve helped me more than you know), you’ve invested an enormous amount of time and effort on Metabase iframed JWT signed embeds including external filters for cascading/linked/dependent functionality.

Bottom line, for those use cases dependent on this functionality is Metabase announcing a deal-killer with the deprecation of JWT signed embeds?

Hi @mesquest.

I wrote that article, and that line was incorrect (and my mistake). I had misinterpreted what our subject matter experts were saying.

We’re exploring how to best allow embeds. We’re looking into replacing the premium embedding license with a lower cost tier of the enterprise edition, but don’t have any concrete plans.

Bottom line: if you’re using the OSS version of embeds, nothing will change.

I’ve since updated the article to omit the line about deprecation so as not to cause concern.

Thanks for bringing this to my attention, and apologies for the confusion!



1 Like

@mesquest thanks for thinking of me - yes it would have caused problems!
@jab thanks for confirming that nothing is due to change.

Than you @jab, for walking this back, I have tagged the subject line as such so as not to alarm anyone further.

JWT as it is used in Metabase right now I do not believe is either SSO or OSS, it just is what it is (I hope you reversed the letters and there is not yet another one of these acronyms). Many have probably implemented standard JWT per the github reference apps with embed access controlled by the apps totally independent of Metabase.

JWT SSO as proposed in your blog post is a fine idea for Enterprise use but probably very difficult to implement in practice for SAAS-style apps. There is no bridge or path from such an app back to Metabase, it would have to be constructed, from scratch, on a case by case basis. To do so would take a high degree of technical skill effectively locking out all but the most advanced developers.

Speaking for myself, I have had to become an unintended fly-by-the-seat-of-my-pants programmer and web developer to implement Metabase with JWT embedding as it exists today. While Metabase’s abilities are impressive, for my use case I do not even touch the GUI favoring native SQL instead, make no use whatsoever of Metrics or Segments, have only the faintest idea of what Pulses are, and am only vaguely aware of X-rays. While I find Enterprise desirable from the security and embed drilldown perspective, I probably have no use for it otherwise. And between the serious technical challenges it would present and the cost, Enterprise simply is not a viable option in my use case at this point.

JWT as it is used in Metabase right now, on the other hand, even with locked parameters, is not really secure. Technically savvy app users can access the token-ized url and share it with whomever they wish with all functionality remaining intact so long as the JWT token is valid. Sensitive information then is a big no-no for Metabase embedding in this way, it is just not secure enough for that.

The only defense is a line of code calling for the JWT token to expire. Ideally expiration should be instantaneous (1s or less) and each time a filter is applied the JWT token should be re-issued without forcing an iframe refresh. This is something Metabase does not currently do as discussed at length on github in Proposal: simplify and unify embedding implementation #9494 where suggestion #5 sounds promising, and in Improved Embed Security #8111 from a user perspective.

JWT token expiration does work but tokens must be valid for a reasonable amount of time, an hour, a few hours at most. But that still leaves a gaping vulnerability that is unacceptable for sensitive information. Information that is not quite so sensitive, OK, that can work, it just depends on how much of this type of potential sharing activity is tolerable for specific use cases.

Unfortunately neither of these github issues nor anything of the kind is on the project roadmap (that I can see anyway). Enterprise is the main focus now, totally understandable, this is a startup, it must be monetized at some point for it to grow. Nevertheless from the moment the term “Enterprise” began popping up it has caused some apprehension among existing Metabase users. And if ever the day comes that Metabase is snapped up by some big outfit and goes the way of Tableau, MS BI et al, or ArcGis (Manifold is the Metabase of the GIS world by the way), then that is when many users will likely flee.

So yes, when the word “deprecate” pops up so do the red flags, whistles, alarms, flashing lights… and so forth.

Apologies for the length of this post but I felt I just had speak up. This probably is not the best place for such feedback but I have a feeling others are thinking along the same lines. Hopefully this is helpful to the Metabase team in some way.

Thanks so much for your feedback, it’s definitely appreciated and we’re always working to improve, so this level of detail and insight is really helpful. We’re still focused on the core BI functionality as a part of Metabase open source and that’s where we’re putting most of our effort this year, as you can see from the latest 0.36 release, and future plans. That roadmap isn’t set in stone, so things change as we receive feedback. :slight_smile: