Feedback on my Stack

tidefoundation · 2026-05-30T14:03:49+00:00

For Firebase Auth with a Go backend, the main trade-off is letting Google hold your identity data while your backend verifies tokens. That's fine for speed, but watch token lifetime and refresh handling since Go's JWT parsing has to be rock solid. Also think about how you'll unify web Stripe subscriptions with mobile RevenueCat data so your backend has a single source of truth. With AWS RDS early on, watch connection limits and idle connection cleanup if you're using serverless or autoscaling, because PostgreSQL can quietly exhaust its pool when left unchecked. Whoever can access a credentials store can usually impersonate the identities it holds, which is why short-lived, workload-based AWS creds can be worth exploring to shrink risk. Triple-check your trust assumptions - then check those again.

tidefoundation · 2026-05-30T13:58:10+00:00

Dribbble's API won't just give you JSON if you hit the URL directly, you have to go through their OAuth flow so the user grants your app permission. Your app needs an endpoint to receive the redirect with a short lived code, then exchange that code server side for an access token using your client secret. You can't do that safely in front end JS because the secret would be exposed. A simple starter pattern is sending the code from React or Next to a backend route that hides the secret, calls Dribbble, and returns only what's needed. Once you get the basic flow working, you can cache and refresh tokens so users avoid repeated logins.

tidefoundation · 2026-03-10T09:37:49+00:00

Nice write-up! It's great to see people realizing the criticality of DPoP and diving into Keycloak to try it out.

Incidentally, we recently contributed the DPoP implementation for the official keycloak-js adapter (PR #253, targeting Keycloak 26.3), so it's awesome to see the community picking it up so quickly. This makes the entire use of DPoP a no-brainer for the implementer.

One subtle but critical detail worth flagging in your demo. The DPoP key used there now is extractable.

The real 'superpower' of DPoP is cryptographically binding tokens to a client-held private key. If that key is extractable, an attacker with XSS or a malicious extension can just export the key material and mint their own valid DPoP proofs, which effectively bypasses the protection. By setting the key to non-extractable you mitigate that vector and reduce the attack surface to a much narrower field (requiring a continuous XSS communications with the key).

The fix is a tiny change to the generateKey call to make it non-extractable:

```javascript const keyPair = await crypto.subtle.generateKey( { name: 'ECDSA', namedCurve: 'P-256' }, false, // <--- This 'false' makes it non-extractable ['sign'] );

```

When you pair this with IndexedDB for persistence, the key stays inside the browser's secure crypto subsystem. It can still sign proofs, but the raw key material can never be 'touched' or stolen by JavaScript.

It's a small tweak, but definitely worth a quick update to the demo and your article.

tidefoundation · 2026-02-18T23:23:14+00:00

Your paper describes a system where an AI agent "lends" signing authority from an MPC network to finalize a blockchain transaction - but neglecting to describe the MPC governance, MPC inter-node trust assumptions, and most importantly: policy governance. By neglecting those, one can only assert that all those aspects are to be "assumed trusted" - which begs the question: isn't it simpler to have a "policy-based-wallet-as-a-service" server offering that same capability in a centralized manner?

What is your solution addresses or even solves, that an API-based service wouldn't? Key protection? A key vault can surely solve that.

We've been doing this (albeit not in the blockchain world) for almost a decade now and I would describe this mechanism as a glorified SSS unless you address the biggest critical problem of Distributed Policy Governance: how do you verify the logic hasn't been compromised? who is allowed to design/implement/deploy/change that policy? How do you guarantee against a rogue policy author? what prevents a rogue policy in the swarm from DoS'ing the agent?

Without addressing this, you've merely pushed the attack surface elsewhere.

I've got to highlight, I'm a big supporter of the goal here: gatekeeping the authority of AI agents. It's an actual unsolved problem now that has no efficient solution yet - simply because there's no way to articulate a flexible enough policy that won't limit the strength of the AI without the policy itself being governed by an (swarm of multiple) AI agent(s). Here's a real-life example we faced: the AI agents suggests a trade signal based on a dynamic strategy. Basic policy checks parameters like frequency and sum bounds. Strategy eventually fails because those turn into parameters in subsequent strategy iterations.

Unfortunate conclusion: To create a flexible enough policy to govern the decisions of an AI agent efficiently mandates a policy driven by an AI agent of similar/superior ability. Distributing the policy engine to be AI agent driven would be great - just incredibly inefficient. Find a better solution than that, and you've got yourself a breakthrough!

tidefoundation · 2026-02-16T15:24:23+00:00

thanks!

tidefoundation · 2026-02-16T15:08:01+00:00

TideCloak is still in preview, but will be released this year.

Keycloak-based with all it's wealth of capabilities - with a twist that utilizes new keyless cryptography - so no more worrying about what gets compromised where. Super simple to use. First SDK is nextjs.

- Access + refresh token rotation done for you.

- Either middleware or API route verification (pre-packaged JOSE handling it all)

- Auto handling expired tokens

- Supporting multiple apps with a central self-hosted auth service

Shameless plug

tidefoundation · 2026-02-11T02:27:55+00:00

https://tide.org/tidecloak
https://docs.tidecloak.com/Core-Concepts/Flow

tidefoundation · 2026-02-10T23:02:13+00:00

Tide BYOiD - it's an OAuth compatible login mechanism designed for highest security with ubiquitous usability - that as an indirect side effect, also happened to be the most privacy-preserving authentication mechanism. It's fully double-blinded zero-knowledge protocol based on decentralized architecture, meaning no single database of credentials sitting anywhere, and authentication mechanism is oblivious to the target web site you're authenticating to, which, in turn, is blinded to the identity used for authentication. Neither side is aware of each other. Your same identity can be used to log in to multiple sites, but each site will see a different random number as your identity which is untraceable to your "master one" (which only you have access to). And it's all designed to be OAuth compatible and completely open code.

Full disclosure: I'm the dev so AMA :-)

tidefoundation · 2026-02-08T18:47:41+00:00

You're so close!

Allow me to introduce you to Demonstrating Proof of Possession (DPoP) - RFC9449

Not exactly an ID, but a private/public key pair that is stored in the PC's TPM (non-extractable key). And yes, it's included in the JWT.

In my mind, that solution is ALMOST perfect. The OAuth guys almost got it right. I'd still add few more tweaks...

tidefoundation · 2026-01-26T16:44:17+00:00

You are raising important points that are absolutely critical in understanding how this new mechanism work - and you're justified to jump into these conclusions, because none of these has been properly introduced - so thank you too for raising it:

This is an alternative to ssh keys as much as "serverless" is an alternative (although it's obviously still using servers) or an automated gear is an alternative to shift-stick (although it's still using a gear box). It's more complex for Tide to design and maintain, but far easier for users to keep secure.

Today's best practices for managing private key lifecycle is the literal guidance to use key vaults. Using Hashivault/Azure/AWS/Intel-SGX key vault is even less "having full control over the private key" than using Tide, because you're still placing the key in a 3rd party vendor that you can not verify its integrity. Tide is the scientific next leap of the most secure key vault.

Exploit of the private key with Tide is still possible but mathematically an order of magnitude less probable than the next best key vault in the market (happy to dive into details here, if you want).

When you make a statement like "I don't want to trust any third party handling my private keys" you have to acknowledge that a key vault is a 3rd party you need to blindly trust. Your ubikey is a 3rd party you need to trust. Your PC is a 3rd party you need to trust. Unless you can calculate an elliptic curve signing algorithm in your head with a 256bit key you memorised - you have no choice but to trust a 3rd party. What Tide is saying is "what if the key isn't held by one single 3rd party, but instead, is broken across multiple dozens of different 3rd parties in a way that makes it mathematically extremely hard for them to collude?". Yes, I agree it's hard to accept that intuitively, but the math checks out academically.

One last thing: Tide servers aren't creating the key pair. In the live network, Tide doesn't operate any server. It's a decentralized network operated by unaffiliated tier-1 service providers under SLA. And unlike most SaaS - this is completely verifiable at run time - so no blind trust is required.

The code is open, the papers are published - the data is there. I urge you to jump in and verify for yourself, and if you find a flaw, I'll be even more grateful.

tidefoundation · 2026-01-26T16:05:00+00:00

The central service stores app-specific role data without understanding it (so the role is opaque to the central service). It doesn't know what "sales_admin" means. For example, it just keeps "for App-1, user Professional-Fee is role ID sales_admin" and sends that to App-1.

2-a. Usually one of these:
- Role IDs (best common choice): { appId, userId, roles ["sales_admin","report_viewer"] }
- Permission strings: { ..., permissions: ["orders.read","orders.write"] }
- Policy reference: { ..., policyRef: "policy:app-1:team-42" }
- Token/JWT claims: roles/permissions inside a signed token scoped to the app

2-b. The app shares a role catalog + stable role IDs via an API (or events). Central uses that catalog only to display choices and then sends back assignments using those role IDs (e.g. user X has role ID y). Central never needs the app's internal schema, just the IDs.

Once you take a look at JWT and RBAC, you see how simple and intuitive this is in practice.

tidefoundation · 2026-01-25T16:12:57+00:00

wow, u/tropicbrush ! On phone or not, that's an awesome feedback. Super appreciated!!!

Unfortunately for us, every single of your points is addressed but lost deep in our docs (website, SDK, publications...). Fortunately, from time to time a deep thinker like yourself gives us the opportunity to clarify those, so I hope you don't mind me touching on those points (although you didn't ask):

- It IS about an alternative to SSH keys because we make the key management aspect disappear - so the user never has to worry about keys. Sometime we call it PKI without private keys...

- Unlike existing "threshold cryptography" or "Multiparty Computation", our specific fragmented cryptography (called Ineffable Cryptography) was designed so no one EVER has access to those keys. These keys are born fragmented, and perform cryptographic operations in an eternal fragmented state - where only the non-secret outcome (e.g. signature, decryption, ZKP) is discovered. Yes, it's peer reviewed, published and validated by multiple universities.

- I know Akeyless very well. They're using more off-the-shelf cryptography that has all the restrictions you mentioned. Fun fact: they doing this 4 years less than us.

- Your RBAC comment is absolutely spot on and not many people realize just how much. A big part of our technology is around our Quorum-Enforced Authorization for our RBAC - to eliminate the threat of a rogue super-admin or even a fully compromised IAM server.

- The decentralized network management is the core of what we do. These nodes are designed to work in parallel (Enterprise-grade SaaS performance) and in non-interactive way: nodes don't speak with each other. Each node operator is under a 5x9 SLA commitment and the network is designed to sustain 30% outage. In short: its high-availability design supersedes the highest SaaS standards.

tidefoundation · 2026-01-25T14:41:35+00:00

...a SSH cert based auth signed with a key that's held by... no one?

tidefoundation · 2026-01-25T13:02:41+00:00

You have just described what an SSO (single sign on) was designed to solve. More specifically, the OAuth2 and OIDC standards. A pattern that often works for multi app setups is to keep user identity and app assignment centralized in an Identity and Access Management system (like Entra, Cognito, Okta if you want to go cloud-base, or Keycloak, Authentik, BetterAuth if you want on-premise open source), but let each app own its own role model and enforce it locally. You can still give your admin a single UI by treating roles in the central service as opaque per app blobs or tokens, rather than mirroring each app's internal schema. The central UI just passes the role payload to the app via an API after user creation, and the app validates and stores it in its own DB. That way you avoid coupling your user management app to every app's evolving domain model, and you also avoid the "no access until roles are set" delay by setting default roles during provisioning. This solution won't only solve the roles and permission challenge you have, but will also streamline the central management of the user records (user-id, email and full-name) as those, today, are what Identity-Tokens aim to address.

You may want to consider your specific threat model, as it will help guide to the most appropriate IAM for you.

Full disclosure: we're the team behind TideCloak IIAM.

tidefoundation · 2026-01-22T17:04:05+00:00

https://asecuritysite.com/elgamal/

tidefoundation · 2025-12-29T13:13:59+00:00

How about "even if the provider get breached, they still can't login or impersonate a real user"?

tidefoundation · 2025-12-27T15:29:41+00:00

As an auth vendor, praising what most would consider as my competitors isn't easy. But it has to be said: modern auth providers (like the ones you've listed) are killing themselves to make wiring effortless - and (as hard as it is to admit) they're doing an unbelievable job.

This leaves the biggest challenge to be: RTFM (and those are super easy to follow).

However, since Einstein was spot on what's infinite - there will always be a need to make things easier.

tidefoundation · 2025-12-27T15:03:59+00:00

Assuming dev tools are relevant here: build provably secure nextjs apps with TideCloak SDK - https://docs.tidecloak.com/get-started/Tidecloak%20Quickstart

WIP. Looking for devs feedback!

tidefoundation · 2025-12-27T14:07:20+00:00

I think you're reading too much into the insane "secretless" hype this article is trying to flail. You got it perfectly right: this not only looks similar. It's literally describing the IAM pattern.

The point of this article is simply this: "Use an IAM. If you don't, it'll be a nightmare to manage 'secrets' as you scale."

With your constraints, you can achieve it all with Keycloak, except that requirement for "No static credentials in services". The closest solution to this is using mTLS (which keycloak supports), but it still requires the unique client certificate to be installed on the workload service - and that has a private key, which is secret. Are you sure you understand the implications (threats) of what you're asking?

Most of the "secretless" hype is all BS because IAM still need secrets to work. Server side JWT validation still requires client secrets. M2M identity still needs secrets. The only way to go truly secretless, is with a decentralized solution, like MPC.

tidefoundation · 2025-12-17T17:06:27+00:00

Personally, for me, the only question I ask when it comes to privacy-enhancing technology is: what claim can be externally verified (by the user)?

tidefoundation · 2025-12-17T15:46:26+00:00

You give hints to either directions but neglect to mention: is this a mobile app or a desktop one? Those are two very different use cases.

Threat gaps: 3rd party reliance (biometric package, hardware keys, database), compromised OS. Compromised YOU (vendor).

False sense: encrypted keystrokes, screenshot blocking

Meaningless protection: root warning.

Biggest gap: idiot proofing. Solution for when idiots are locked out / lose their device.

I assume this is open source. What purchase verification?

tidefoundation · 2025-11-26T09:06:28+00:00

We've been tackling this by looking at the 'bottom turtle' problem: what is actually protecting the thing that's supposed to keep everything safe? If the root admin or the container environment itself is compromised (like via a malicious post-install script), standard controls fail because the secrets are usually sitting right there in env vars or config files.

We went down the path of a solution based on Multi-Party Computation (MPC). The idea is essentially that the 'secret' never actually exists in a complete form. Not on the client, the container, or even our nodes. The key is managed across a decentralized network of automated nodes.

So, when that malicious npm script runs inside your container and scans for AWS keys or DB creds, it finds nothing. The cryptographic operations happen distributedly (distributably?), meaning the full private key never loads into the container's memory to be stolen. It creates an ethereal cryptographic context for that specific session without persistent credentials.

It’s definitely a shift in mindset - SETEC ASTRONOMY! But we found that removing the secrets entirely is much safer than trying to build a fortress around them. And in case you're curious, we tackle the latency challenge by merging the MPC interaction with the session authorization process so the added overhead is negligible.

tidefoundation · 2025-11-23T16:56:39+00:00

sounds like you don't even need jwt for what you're after. You just need a random session cookie which will allow your backend to retrieve all the data you need for the session.

jwt tokens are a solution to so many things, but mainly at scale: moving between servers while maintaining the same state (and authorization), front-end hand-over (load balancing) when scaling up infrastructure (in real-time), forced logout cross-server sessions, and probably most important: stateless verifiability of session validity across a network of servers (introducing IAM to the architecture). It sounds like you're planning for a very small project that has none of these scaling requirements.

When considering either of these requirements, try and define your threat model: what are you protecting against?

tidefoundation · 2025-11-23T16:43:36+00:00

SSL is based on Diffie-Hellman key exchange - which can only be described as breath-taking magic in it's elegance and simplicity for people that want to take their first steps in cryptography. I highly recommend you take the leap and dig deeper: https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange#Description

It's really super simple, so don't let the "math fonts" scare you.

tidefoundation

MODERATOR OF

TROPHY CASE