Show HN: Hydra – Open-Source OAuth2 Server
gethydra.sh
gethydra.sh
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.
That being said, I'm not quite sure to which feature OP was referring in particular. Perhaps to the modular approach taken by Hydra when compared to Keycloak. Hydra has a much smaller scope than Keycloak, so it would be really hard to compare them. Keycloak does identity management, consent, access control and a lot of UI.
Hydra is not even a self-contained identity provider - it's basically just the shell of an OpenID Connect provider that provides tokens, sessions and security (hopefully avoiding implementing OIDC correctly yourself, which could be very tricky as the spec is downright massive). You have to provide in turn separate services which take care of login and consent.
I don't think Hydra is the only Open ID Connect implementation which follows this model of breaking down the IdP. Dex is another shell IdP that does that, and also built from the grounds up to be containerized (being started by CoreOS and all). The main difference is that is that Dex provides a more easy to use set of built-in connectors to popular identity management systems (and other identity provider protocols, such as SAML or even another OIDC provider). It's not as extensible and flexible as the Hydra model, but probably easier to use if you just want to quickly provide OIDC on top of an existing LDAP.
IdentityServer does have more of a framework/library approach so you can integrate it into your own code and apps but there's a turnkey UI project available that just needs some settings in a JSON config file to get running.
https://github.com/IdentityServer/IdentityServer4.Quickstart...
They also have the only good OIDC javascript client that implements the new PKCE flow for client-side apps: https://github.com/IdentityModel/oidc-client-js
Full disclosure I work for FusionAuth. We support all of these configurations.
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 OAuth related requests come in?
A diagram of how an OAuth2 server fits into an application architecture and a visualization of an OAuth flow in it would greatly help here.
OAuth 1.0/2.0 are a set of protocols and standards allowing applications to identify users and get access to their data using existing profiles. OAuth is mostly focused around authorization with claims (which are just key-value pairs) and authentication was an afterthought.
OpenID is another standard designed to let people authenticate across the web, launched with a lot of hype in the early web 2.0 days but never took off. OpenID Connect (OIDC) is a new standard based on OAuth 2 + OpenID to provide both authentication and authorization in a single flow.
OIDC/OAuth is all based on tokens, which are usually JWTs containing a bunch of claims that can be validated against the server that issued them. There are ID tokens (for the user info) and Access tokens (for accessing an API on behalf of that user), but some services like social logins don't provide any access tokens. Other providers might have rate limits, or dont have fine-grained permissions, or you maybe you have completely internal APIs that you need tokens for.
A token/identity server like Hydra can take care of creating and managing all the tokens and grants, and all the OAuth token flows, in a central location between internal and external APIs and user providers.
It's really just a webapp with endpoints that implement all the protocols so you can run it as a service somewhere. Once you do, your apps can then just call the token endpoint to recognize users and your APIs can use it to validate incoming requests which have JWTs. You still need the logic in your code to use OIDC sign-in and/or JWT validation but this is standard functionality and easily available in every stack.
https://fusionauth.io/articles/logins/webapp/oauth-authoriza...
https://fusionauth.io/articles/logins/types-of-logins-authen...
The BCP recommends either sending back client_id and iss (but that draft[1] is long expired, and nobody seems to support that implementation), or asking the client to provider a separate exact-match return URI for each AS. The second solution is what I'm doing when implementing multi-AS/IdP OAuth clients, but this requires the clients to be aware of this vulnerability, and that's a rather tall requirement.
[1] https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigati...
Ran across some unexpected drama while poking around: apparently, one of the main authors of OAuth2 spec withdrew his name from the publication and has repeatedly publicly derided the standard. https://vimeo.com/52882780. Parts I heard were good.
I'd just like to make a small request that developers on tiny internal-only APIs not make a big ordeal out of OAuth and require a big honking session store anchored against the "user's" OAuth creds on every internal, service-to-service request, thanks.
However, OIDC and OAuth2 are complex protocols which is also why we encourage most greenfield and small projects to avoid it unless explicitly required.
It’s also important to note that that particular person voiced criticism, but most of the biggest names in tech (GCP, AWS, ...) heavily rely on those protocols (+ extensions). His proposed alternative protocol Oz never got to real world adoption (to my knowledge) and has recently been archived. The prediction that we would see major OAuth2 security wholes within 3 years (so 2015j never came true. It doesn’t mean that he was wrong, but that there are opinions that contradict him, and that those opinions and voices have established themselves in the industry.
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 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?
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.
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.
OIDC is great for greenfield and much better than writing user signin flow every time.
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.