ffo

8 ms·

31.
by ffo 2y ago
Out of curiosity what made you pick Zitadel over Authentik? Disclaimer: I am the CEO of Zitadel ;-)
32.
by ffo 2y ago
On the note of oss and sso that works well for b2b. Zitadel can be tool to get rid of the plumbing work that you encounter with all the permutations one can have with the different customer requirements. Disclaimer: I am a co-founder
33.
by ffo 2y ago
Haha comparison made me giggle.
34.
by ffo 2y ago
Yes but the same logic about loosing the secret applies to passwords and any other factors (given we ignore a potential reset process) Providers will most of the time allow to register multiple passkeys or other authentication means, hopefu
35.
by ffo 2y ago
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
36.
by ffo 2y ago
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 se
37.
by ffo 2y ago
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 k
38.
by ffo 3y ago
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
39.
by ffo 3y ago
Hehe, it has been a while since that discussion. Many things happened since then ;-)
40.
by ffo 3y ago
Co-Founder here, let me know if you have questions about our approach ;-)
41.
by ffo 3y ago
> 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 u
42.
by ffo 3y ago
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
43.
by ffo 3y ago
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.
44.
by ffo 3y ago
I think both products could even coexist ;-) SQLlite would be super nice, but we lack engineering capacity right now to get that done.
45.
Migrate Users from Keycloak to Zitadel(zitadel.com)
37 points by ffo 3y ago|7 comments
46.
by ffo 3y ago
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/p
47.
by ffo 3y ago
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
48.
by ffo 3y ago
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 lo
49.
by ffo 3y ago
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,
50.
by ffo 3y ago
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
51.
Go OpenID/OAuth2 Lib with Token Exchange and Device Authorization Support(zitadel.com)
5 points by ffo 4y ago|0 comments
52.
by ffo 4y ago
Co-Founder here. Nice to hear this. Let us know where we can further improve our product.
53.
by ffo 4y ago
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"
54.
by ffo 4y ago
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)
55.
by ffo 4y ago
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.
56.
by ffo 4y ago
Well, yes ;-)
57.
by ffo 4y ago
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
58.
by ffo 4y ago
Well you can have the turnkey of keycloak and JWT optional with ZITADEL ;-)
59.
by ffo 4y ago
Or you want to share sessions across multiple domains. This is where a identity service also can help ;-)
60.
by ffo 4y ago
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.

More ›