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.
The difference is probably between "can be made to run in a container" (which is true for almost every app) and "designed from day 1 to be containerized" - which is obviously not true for solutions like Keycloak.
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.
Thanks for this list! I wonder why Identity Servier is tied into .NET - an OAuth 2.0 / OIDC provider just provides OAuth services. Couldn't this be used by any service provider or client?
It's a C#/.NET app but it's not tied to it. OAuth/OIDC is all HTTP endpoints and redirects.
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.
I'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 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.
Authentication = who are you. Authorization = what are you allowed to do.
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.
I think this allows you to turn whatever you use for user authentication into an OAuth2 provider by letting you implement the hooks that authenticate users while handling the OAuth2 bits. Or at least that is what I got from the introduction at https://www.ory.sh/docs/hydra/#what-is-ory-hydra .
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.
I was just researching OAuth servers last week and came across Hydra several times. Congrats all on a big release!
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.
The blog posts and discussion was long ago (the video is 6 years old). Since then, that particular author acknowledged that (iirc) OpenID Connect solves many of the things he criticized. I have to look up the source, it’s been a while.
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.
A 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 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?
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.
OpenID still required sites to implement that standard as a relying party so it couldn't be used arbitrarily. It gave you the ability to choose a specific OpenID identity provider to store your account info (including your own), but it didnt get adoption so now it's obsolete.
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.
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.
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.
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.
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".
