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.
