Show HN: Hydra – Open-Source OAuth2 Server
41–50 of 52 posts
Re: Show HN: Hydra – Open-Source OAuth2 Server
#42That worked swimmingly in the few places that supported OpenID, but eventually even StackOverflow dropped support.
I must admit I haven't kept up with what has happened since in this area, so stupid question:
Could I install this server and have my own OAuth2/OIDC provider that would allow me to login to websites using my own provider (instead of "Login with Microsoft Github", "Login with Facebook", "Login with Google", "Login with Twitter"), or is this something else/the reverse?
Re: Show HN: Hydra – Open-Source OAuth2 Server
#43Earlier quoted context omitted.
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.
Re: Show HN: Hydra – Open-Source OAuth2 Server
#44A looong time ago, when OpenID was sort-of new, I implemented my own OpenID provider, because I wanted to log into StackOverflow and other places, but I didn't want to use a third party service. That worked swimmingly in the few places that supported OpenID, but eventually even StackOverflow dropped support. I must admit I haven't kept up with what has happened since in this area, so stupid question: Could I install…
Re: Show HN: Hydra – Open-Source OAuth2 Server
#45In my research, Hydra is the only OSS OIDC server implementation that is built from the start in a modern, containerized manner.
https://identityserver.io/ https://fusionauth.io/ https://www.keycloak.org/ https://www.gluu.org/ Basically all of them can run in a container, it's just hosting a few endpoints and generating tokens. The complexity is in the protocols and not the app. Some of them offer a user database as well and might require a SQL DB connection.
Full disclosure I work for FusionAuth. We support all of these configurations.
Re: Show HN: Hydra – Open-Source OAuth2 Server
#46I'm not too familiar with this space, so please excuse my question. What is OAuth2 server is? I was under the impression that for a given service/API typically OAuth2 is implemented by the provider on their servers, either from scratch or using some sort of library. With an OAuth2 server are you running a separate server or is it an internal service that your application code connects to (and forwards requests?) when…
https://fusionauth.io/articles/logins/webapp/oauth-authoriza...
https://fusionauth.io/articles/logins/types-of-logins-authen...
Re: Show HN: Hydra – Open-Source OAuth2 Server
#47Earlier quoted context omitted.
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.
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.
Re: Show HN: Hydra – Open-Source OAuth2 Server
#48Earlier quoted context omitted.
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.
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.
Re: Show HN: Hydra – Open-Source OAuth2 Server
#49A looong time ago, when OpenID was sort-of new, I implemented my own OpenID provider, because I wanted to log into StackOverflow and other places, but I didn't want to use a third party service. That worked swimmingly in the few places that supported OpenID, but eventually even StackOverflow dropped support. I must admit I haven't kept up with what has happened since in this area, so stupid question: Could I install…
No, OIDC providers can only be accessed by registered clients so those sites cant use your provider unless they specifically add it. Otherwise you would be able to login with any of those accounts on any site already.
Re: Show HN: Hydra – Open-Source OAuth2 Server
#50Earlier quoted context omitted.
No, OIDC providers can only be accessed by registered clients so those sites cant use your provider unless they specifically add it. Otherwise you would be able to login with any of those accounts on any site already.
Ok, so there really isn't anything like OpenID any more?
OpenID Connect is the latest version of OpenID, and it uses OAuth to federate access to other identity providers but sites now have to implement a separate registration for each provider (google, facebook, etc) so what they choose to implement is what you get, and there's no realistic option to use your own.