Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Anyone remembers .htaccess files from Apache? Good times.


Those would be quite nice, if web browsers were good HTTP clients.

The user experience with basic auth is not so good. The dialogs give little way to customize and providing information for user. No support for logout or any form of password changes.


Isn't that sort of a feature? Customizable HTTP auth dialogs are a security liability, as they blur the line between content and browser.


Yes and no. There is some part of it which helps to identify where you are connecting to. Meanwhile those dialogs aren't modal anymore, which allows access to https certificate info, but it is still complicated to provide trust for average users.


> The user experience with basic auth is not so good.

Apache actually also has an OpenID Connect module (it's certified and everything), which you can enable to have it work as a relying party: https://github.com/zmartzone/mod_auth_openidc

Basically, the actual UI will be handled by another system that you might be using, for example, in my case that might be a self-hosted Keycloak instance: https://www.keycloak.org/

I'd say that Keycloak is a pretty good solution in general, because it does some of the heavy lifting for you, maybe its shorter release cycle not being the best thing ever, though. I think IdentityServer also tried to fill this niche, but they went full on commercial recently, without OSS offerings.

As a sidenote, I also use mTLS for some personal resources and basicauth is still wonderfully easy to setup without a single point of failure for handling the authentication. A caveat might be that in practice people who try to use mTLS for app development shoot themselves in the foot, because that doesn't play nicely with reverse proxies etc.

Oh and also, to reduce needless disk IO, using a single config file approach as opposed to .htaccess can make Apache a bit more performant and easier to reason about: https://httpd.apache.org/docs/current/mod/core.html#allowove...


IdentityServer have a Community Edition that is suitable for OSS projects.


Hmm, from what I can tell, this appears to be sort of true: https://duendesoftware.com/products/CommunityEdition

However it's the kind of license that's gated behind a manual signup:

> If you would like to request a Community Edition license, please provide:

> Confirmation that you understood the qualifying criteria

> Your category (for-profit, non-profit, charity)

> Your (company) name

> Your address

> Your contact email

This seems to be reflected in that you cannot find any official Docker images, for example: https://hub.docker.com/search?q=identityserver

Contrast that to: https://hub.docker.com/r/keycloak/keycloak (admittedly, the Bitnami containers are better, since those provide good documentation right in Docker Hub, instead of being lazy like Keycloak did and just putting it on their site)

Overall, the licensing situation with IdentityServer seems interesting, perhaps a bit more restrictive than Keycloak or other competitors: https://leastprivilege.com/2020/10/01/the-future-of-identity...

Regardless, to me being able to download software without messing about with signups and justifying why I need it feels like a good litmus test for some of the culture and community behind it. Regardless, I don't think that there are any truly excellent solutions in this space out there.

Then again, you see basically the same with the likes of OpenLDAP, FreeIPA and others that still don't quite compete with Microsoft's AD. There's a lot of problems (identity and device management, authentication/authorization gateways etc.) that could have great OSS solutions for them, if at the end of the day everything didn't circle back to money. Oh well.


Logout is possible: The server has to send http status 401 if I recall correctly. The browser treats this as logout.


This requires some server side handling. The web browser could have a logout button so I can end my session. Probably that should be combined with a configured target page for the user.

And well, my experience there is about 20 years old, but back then sending 401 wasn't enough. You had to send a different auth request, which then would pop up a new password dialog first. Indoubt 401 is enough today as well, as the browser can't distinguish whether a specific resource is restricted or whether the whole session should be invalidated.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: