21–30 of 52 posts
Earlier 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.
What is the suggested solution for Greenfield development?
I wonder how many open source projects use this name. There's also Hydra[1], a Nix-based continuous build system. [1] https://nixos.org/hydra/
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.
I wonder how many open source projects use this name. There's also Hydra[1], a Nix-based continuous build system. [1] https://nixos.org/hydra/
There is also the Hydra[1] parallel Scala compiler. [1] https://www.triplequote.com/hydra/
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…
In 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.
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.
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.
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...
Earlier quoted context omitted.
There is also the Hydra[1] parallel Scala compiler. [1] https://www.triplequote.com/hydra/
My first thought was THC Hydra [1] [1] https://sectools.org/tool/hydra/
Earlier quoted context omitted.
My first thought was THC Hydra [1] [1] https://sectools.org/tool/hydra/
My first thought was NZB Hydra 2 [0] [0] https://github.com/theotherp/nzbhydra2