ffo

Why do you think it is reuse?

You will not use the same passkey for multiple application/service.

You will generate a passkey per application/service.

I will certainly though not disagree on security... if that is your thing then do not sync private keys around, but the tradeoff is always there. If security would be critical, I would favor client certs with smartcards, but browsers do not support that "too well"

I mean the question if private keys should be synced is the fun one to argue about ;-)

My thinking is always if you do passkeys for phishing protection or potentially UX improvements then there is no harm syncing keys. (I would argue the security is increased by adding phishing protection over password/2fa) If you do it for security, then you do not want to sync keys and rely on key storage that do not allow extraction (most secure will be "offline" key stores like YubiKeys). I guess the latter is more important in enterprise/business scenarios rather than in b2c context.

A little OT but it will also be fun in b2c explaining customers that there keystore is full on the hardware key. (of the top of my head YubiKey 5 have a limit of about 25 keys)

Even though I work at a company that also supplies passkeys support to its customers, I feel it is worth for people to have a read of (1). The platform lock-in is a real problem we already see. Even password managers that sync the private key most of the times do not allow to export the key material. Oh, and if a customer ever wants to change the domain name for branding related stuff, is also where the fun starts.

My 2 cents are that passwords/2fa, passkeys, federation and maybe soon verifiable credentials are concepts that will work for a long time in parallel. So, if you ever choose a system that does the "identity/authentication" plumbing work for you, I think you should focus solutions that are open source and allow you to mix and match the different concepts. IMO this applies to b2c and b2b alike ;-)

[1] https://fy.blackhats.net.au/blog/2024-04-26-passkeys-a-shatt...

I agree, the network part looks overly complicated to me as well.

Bandwidth was at least relatable to some extend. But now it looks like one needs to combine requests and client traffic as well as server traffic.

It wonder how that works if you proxy another vercel site through a vercel project. I.e. a nextjs projects proxies /docs to a docusaurus page. Because as of today the billed the bandwidth and requests twice :-(

Hehe, it has been a while since that discussion.

Many things happened since then ;-)

Co-Founder here, let me know if you have questions about our approach ;-)

> Zitadel, heard but not tried yet. The keycloak vs zitadel page doesn't help. Is the Zitadel access token also jwt like in keycloak and included role membership?

By default Zitadel uses opaque tokens but you can switch to JWT and use an piece of JS code (actions) to insert whatever claim you want into the tokens

Let me assure you the core product will stay open with a permissive open source license.

That said, there will be components that will be closed source who mainly bring value in the area of identity based threat analytics since even we need a way of monetisation.

Happy to share more thoughts on this if you like to discuss this.

Sure, there needs to be a „de facto“ OSS player in the space. Let me tell you that is what we definitely aspire to become.

I always think there was not yet the „gitlab“ effect in the identity space.

I think both products could even coexist ;-)

SQLlite would be super nice, but we lack engineering capacity right now to get that done.

Since ZITADEL now uses passwap [1] for password hashing, we are now able to allow migrations from Keycloak to ZITADEL.

In the past we only supported bcrypt while Keycloak used PBKDF2 ;-)

[1] https://github.com/zitadel/passwap#algorithms

ZITADEL Co-Founder here.

Thank you for the nice words you describe well what we try to achieve!

With ZITADEL we aspire to become the best of Auth0 and Keycloak in more modern package. Or in other words are a end-to-end open source identity infrastructure. I know this sounds a little unspecific but our goals are:

1) Have AuthN/AuthZ, Login, SSO as Turnkey features but also allow people to build their own UIs

2) Have an audit trail that allows people to see all changes ever made

3) Give devs the ability to extend zitadel with custom code (actions)

4) Support well given standards (OIDC/Oauth/SAML/LDAP) with certification if possible

5) Be ease to operate and scale

6) Provide APIs for everything ;-)

Btw. its always nice to see other projects to solve problems in the identity space. To me it feels like Obligator can, at the moment, be best compared to Dex since it feels a lot like a façade service that has little user management capabilities (not that this is a bad thing) but wraps them for easier usage in multiple services. But please take this observation with a lot of salt since I have not used or tinkered with Obligator.

Cheers Florian

Zitadel co-founder here.

Thanks for the kind words!

As you already pointed out we are currently working on two major improvements. A new resource based API which allows creating your own login/register and many more things (1) and a login/register sdk for typescript (2). This decision was definitely influenced by our great community and helps us shape the product.

We dearly believe the market needs a modern open source identity platform that can replace Auth0 Personal opinion, do not fight me for this ;-) I often think of what we do as GitLab vs. GitHub. Going with an open core/source product against a well established cloud only/closed source player. From Keycloak we took inspiration in the ability to self-host. We think it is important to allow people to control their critical user data.

[1] i.e https://github.com/zitadel/zitadel/tree/main/proto/zitadel/s... [2] https://github.com/zitadel/typescript

Zitadel co-founder here.

We support multiple approaches for multi-tenancy.

In a typical setup you will only need an instance (a virtual Zitadel system). This already supports B2C and B2B deployments.

If you want to host multiple customers, fully isolated, you could create an instance for each customer. However this is only necessary if you want to become a Zitadel service provider in most cases ;-)

Some docs for this:

Organization vs Instance: https://zitadel.com/blog/multi-tenancy-with-organizations Instance: https://zitadel.com/docs/concepts/structure/instance Organization: https://zitadel.com/docs/concepts/structure/organizations

Hope this helps!

That is the reason why we also provide a cloud service with zitadel.

But it is important to us to let customers choose what they like more.

Sometime the gained control (and responsibility) when self-hosting might be crucial for the specific use-case.

Co-Founder here. Nice to hear this. Let us know where we can further improve our product.

Well you don't ;-)

If you stick to OAuth and OIDC you have the option to validate the tokens against the userinfo and introspect endpoints, but that's, just another "database"

One could include the SID claim, with this the token at least could be tested against a users session on the IdP/OP. (This is being used in the ID_Token in OIDC)

Well, when dealing with OIDC / OAuth you can bind the tokens to the user session or trigger back channel logouts. But anyways its not really easy to tell an RP to stop using a token.

Well, yes ;-)

Well true, public keys would be better wording wise.

One thing I just wanted to append to this here:

> Not necessarily in real-time, but at least on a frequent periodic basis.

Periodically fetching the keys is not really a best practice on its own. The consumer (RP) must be able to handle newly published keys at runtime. Since a JWT includes a KID it is recommended to lookup a local cache pre-filled from a scheduler while fetching new KIDs on demand.

Well you can have the turnkey of keycloak and JWT optional with ZITADEL ;-)

Or you want to share sessions across multiple domains.

This is where a identity service also can help ;-)

The cookies is mainly used to identity the user (e.g. his session and prior authentication), while the tokens are used to forward something to proof that the an application wants to access one or multiple apis.

Well you want to check your session cookies as well against something ;-)

Surely you could trust a signature and lifetime but that makes the cookie no different than a JWT (only storage wise the differ in that case).

Generally speaking it is recommended to use opaque tokens and rely on the userinfo / introspect endpoint call to make for the session management.

Only in specific cases where latency and/or scaling might become an issue you should opt for JWT. At least this is my opinion.

This is so true in practice ;-)

Also a problem I encountered in the wild, is that a potential attacker tries to trick a user into installing a malicious CA Public key as requirement to be allowed past the captive portal.

Unfortunately mitigating this is hard(er) and only mTLS could solve that issue.

I stand by my point that we openly disclose this and if you don’t want to share data either disable it or don‘t use it.

I think we state transparently enough that we only report usage data and not your data within ZITADEL and you are free to disable it any time.

If you don’t agree with this I recommend not using ZITADEL

Thanks for the input.

We definitely have SCIM2.0 on the radar. If someone feels intrigued we would happily accept a PR

Only my own experience and secondary sources https://keycloak.discourse.group/t/maximum-limit-of-realms/8... https://stackoverflow.com/questions/54465114/when-realm-coun...