Live data from Hacker News

Show HN: Hydra – Open-Source OAuth2 Server

gethydra.sh

1–10 of 52 posts

Re: Show HN: Hydra – Open-Source OAuth2 Server

#3

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.

Re: Show HN: Hydra – Open-Source OAuth2 Server

#5

Does Hydra follow the OAuth Security BCP ( https://tools.ietf.org/html/draft-ietf-oauth-security-topics... )? I do not see PKCE or mix-up mitigation mentioned, for example.

While not explicitly mentioned, PKCE is supported! And yes, that draft was an important guide during implementation.

Re: Show HN: Hydra – Open-Source OAuth2 Server

#7
post #3

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 t…

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?

Re: Show HN: Hydra – Open-Source OAuth2 Server

#9
post #7
post #3

Earlier quoted context omitted.

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 t…

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.
Post reply on HN