Hacker News Reader

Comment by praseodym | Hacker News Reader

How does Hydra compare to other OIDC server implementations like Dex and Keycloak?

It leaves the implementation of the login (enter /password, ...) and consent (may application X have access to your pictures?) flows up to the developers using HTTP Redirection flows. You can therefore integrate it much easier in existing applications.

Also, you have complete control over the ui and user experience and must not learn a template language (Keycloak) or fork (Dex) the project to customize it.

Compared to Keycloak, Hydra is much more lightweight (no JVM/JBoss). However, you need to implement the user database yourself and/or write your own connector for it.

If we have to implement all those things, is there really much of a remaining lift in implementing OIDC, apart from bringing in a library into a web app?

Yes, implementing both OAuth2 as well as OIDC according to spec is a significant development effort and countless teams and companies fail at pushing through, shipping incomplete or insecure implementations. If you’re greenfield, OAuth2/OIDC is with 99% certainty not the right fit for you anyways.

Ok makes sense, thanks (it was a genuine question, sounds like those protocols are quite complex.)

Bringing in a library is different from building it from scratch. Pretty much every language has solid OIDC frameworks now.

OIDC is great for greenfield and much better than writing user signin flow every time.

Username + Password with a cookie store is much better understood and harder to get wrong than implementing a full OIDC suite (server + client). If you're talking federated login, that's what OIDC is for. If you're talking "login", your opinion is misguided.

We might not be talking about the same thing. The thread was comparing to other OAuth servers, and then libraries, but nobody is talking about implementing it from scratch.

That being said, if you're working on a greenfield app where you need auth, using an OAuth/OIDC server is much better and faster than creating yet another membership system for that app. That's a major advantage of identity federation.

What is the suggested solution for Greenfield development?

Additionally, Greenfield dev where federated identity support is a requirement

This is NIH syndrome. You're way better off following the standards, and likely implementing standard libraries to actually make use of them.

Sorry, but following a standard for federation is not a substitute for building a log in system, which is what most people want when building "a web app".

Lets say there are no restrictions, what type of authentication flow would you recommend looking into? I was under the impression that OAuth2 was pretty much the goto standard nowadays.

OpenID Connect with the authorization code flow using PKCE is the newest and best standard, and now works the same for both client-side and server-side apps.

Reply on news.ycombinator.com