jsso2 VS Keycloak

That's weird. I implemented it a year ago and it basically works perfectly on all the browsers I use. I can enroll a Yubikey on my desktop, and then hold it up to my iPhone to log in. (Of course, I also enrolled FaceID on the phone.)

My one complaint is that enrollments don't sync between my iPhone and my iPad. Had to enroll my face twice.

Code is here: https://github.com/jrockway/jsso2 (not security reviewed or well documented)

I went this route. I really like the design of Google's Identity-Aware Proxy. You host your apps behind it, the proxy authenticates users and passes a JWT to the application that contains additional metadata. The app can choose to care or not care about the JWT. This is nice for read-only things that aren't particularly important (something like jaeger-ui). Or the app can choose to care, and do one cryptographic operation to get a trustworthy username and group membership list. This is so much easier from an operations and implementation perspective than integrating something like OIDC. I wish more applications supported this, and didn't force me to hack OIDC into this flow.

As for WebAuthn, yes, that's what you should be using these days. People are terrible at choosing passwords, so why make them?

I wrote an authenticating proxy that maintains username -> WebAuthn credentials, and use it for my personal projects. I wouldn't recommend that someone else use it (incomplete featureset, not security reviewed), but it's totally open source so you can steal the bits you like: https://github.com/jrockway/jsso2

The end result is that I can open up Grafana on my phone and sign in with FaceID. Or if my face falls off, I can scan my YubiKey with NFC. All given to you for free for using WebAuthn. And it costs $0/month, which is much less than the Oktas of the world charge for a more

I was thinking very seriously about starting this company. There were some details I could never work out, and then Covid hit, so I didn't pursue it.

My thoughts are:

1) One login per day per person is the maximum number of times I would ever consider asking for authentication. This is where OAuth fails; you visit an app that wants you to authenticate, but you don't get automatically logged in. You have to click at least twice. Huge drag and I hate it to death. When I worked at Google, we had BeyondCorp and I was asked for a password and security key touch once a day and could then browse internal apps freely. I would not accept anything less. (Okta and Auth0 fail here.)

But, this requires infrastructure, like trusting client devices and their screen locks. Writing software to secure some random bring-your-own-laptop is a full-on company in and of itself, and if that fails, your whole authentication system fails. (Malware starts impersonating the human.) Google's corporate engineering got this right, but I don't have that knowledge/experience to do that myself.

2) I really like the "identity aware proxy" design. There is an internal network, your app servers run there, and the proxy bridges that to the Internet and handles all the authentication details. The proxy signs a token that says who accessed it, and the app doesn't need to care. The problem here is that no apps support this. Every open-source web application bundles 10,000 lines of code for their own IAM system, and everyone seems totally fine with this. There is no standard, really, for identity aware proxies, and therefore no way for an app to recognize a standard token. (And, apps also need to do IAM management beyond just knowing who the logged-in user is, so you need a protocol to talk to the identity provider.) Yes, OIDC tries to fix some of these things, but it really isn't ... good. It optimizes for the problem of letting you log in to StealMyEmail.com with your Google account, without compromising your entire Google account. Not what people need for their internal applications.

Anyway, I bring it up because people clearly don't like this idea. They can't run an "internal network" securely, because you see the same flaws with this architecture again and again -- chat service's link unfurler takes a malformed link and makes a GET request to an internal application and leaks data; someone's jumpbox gets compromised and their network gets completely owned; "SSL added and removed here :-)"; etc. Very few people have successfully set up internal mTLS, which you really need for the proxy model to work. So instead, they just treat each app as its own island with a set of users, and identity provider, and session tokens, etc. Okta and Auth0 handle this case really well (well, they charge you a lot of money to pretend to sync the users), and that's why they're successful. But the user experience sucks, and the application developer experience sucks, and the application operator experience sucks. Hey, everyone's happy! Give me 6.5 billion dollars!

3) Every identity provider needs some answer to the SSH problem. People have been trying to do this for more than 30 years and it continues to suck. I think it's unsolvable. But thinking it's unsolvable means you don't get any customers, so that's a problem for me ;)

4) People are very interested in add-ons that are required by standard compliance rules. To be in certain businesses, you have to have a "web application firewall", which is basically something that greps the incoming request for "DROP TABLE users" and returns an error if that's in there. Denylisting will never work, but maintaining that denylist is yet another full-time company. You'll never catch up with the established players here, at least not as a 2 person startup.

5) The product I wanted to make was a centrally-managed IDP, with little proxies you could place wherever you needed one. At my last job, this is something we tried to buy from Duo, but their product was terrible. Our software engineering team had one Kubernetes cluster, with one connection to the Internet that was easy to proxy. (We used Envoy, and I wrote an SSO auth plugin, and everything was great for us.) Our network engineering team just had VMs everywhere, with an nginx that reached out to Duo for auth. It checked the security box, but you had to log into every web app twice -- once to log into Duo, once to log into the app itself. Awful.

Anyway, I do like the model. It's easy enough to write a nginx plugin and Envoy sidecar and whatever else people want, and then have it connect over TLS to receive instructions from a central leader. The tough bit is keeping those proxies functional when the central server dies (maybe new users can't login when it's down, but people with session material should be able to keep using it). There are a few designs -- just push the session cookie to every proxy when someone logs in and have the proxy check sessions with a simple string comparison. Now you survive some types of downtime (good luck firing someone when the central server is down), but that lets a proxy administrator start impersonating other users by writing a malicious proxy, GDB-ing it, whatever. So that's no good. Another option is to use public key crypto so that the proxy operator can't mint valid tokens, but every time I think about it I feel like I have the design, then I write out the details and find that it doesn't work. (That happened just now, I thought I had it for sure, but I don't ;)

All of these details were the killer for me. The business looks tough, but the technology isn't easy either. I did get mad enough to write something for myself (https://github.com/jrockway/jsso2), but that is not something I would ever consider selling -- it's just a very simple IDP and authenticating proxy. Perfect for blocking HN users from visiting https://alertmanager.jrock.us/, but still lets me look at it from my phone. (With FaceID and not a password, of course!)

I don't know what the future here is. Companies like Tailscale have the right idea -- don't trust any endpoint, human or "server". But you have to bring your own IDP, and applications can't know which human they are talking to. (Or at least, there wasn't an API to map the Tailscale source IP address to the human username when I last looked.) And, the mesh doesn't work for people that are already happy with having an internal network. I run everything on Kubernetes, and I don't want to use some crazy CNI to make every Pod a member of the network... too much stuff can break for the 0.0001% of the time when I want to directly connect to a Pod.

I guess what happened is that nobody ever decided how things should be done, so everyone does their own thing. That makes it a difficult market for a startup to enter, because you have to hope that your opinion is shared by enough people to have a customerbase to support you.

TL;DR: Everything is awful and it makes me mad.

In this article we'll be using Keycloak to secure a Vue.js Web application. We're going to leverage oidc-client-ts to integrate OIDC authentication with the Vue app. The oidc-client-ts package is a well-maintained and used library. It provides a lot of utilities for building out a fully production app.

Keycloak has been a leader in the Identity and Access Management world since its launch almost 8 years ago. It is an open-source offering under the stewardship of Red Hat

It sounds like what you're looking for is an identity provider.

A popular open source option is https://www.keycloak.org/

This application can manage your users, then you can use standards like OpenID or SAML to plug it into your application, of which there are usually many plugins to accomplish this depending on your tech stack.

KeyCloak is a Cloud Native Computing Foundation (CNCF) project that offers enterprise IAM solutions. Keycloak emphasizes proficient enterprise authorization solutions by providing:

Outline only uses SSO for authentication. The solution when self hosting is use a private keycloak server [1]. This allows you to do email based auth.

[1] https://www.keycloak.org/

> Keycloak was good but has too much legacy for 10+ years.

I got curious, actually seems to check out and explains why it's so well documented (but also complex and oftentimes confusing):

> The first production release of Keycloak was in September 2014, with development having started about a year earlier.

https://en.wikipedia.org/wiki/Keycloak

https://github.com/keycloak/keycloak/releases/tag/1.0.0.Fina...

> Don't outsource either your authentication or authorization. Run it in-house.

This is hard to do, though. I hope people here will drop a lot of combinations that work for them!

Personally, for a small/medium scale project, I went with:

Keycloak: https://www.keycloak.org/

It supports various backing RDBMSes (like PostgreSQL, MariaDB/MySQL and others), allows both users that you persist in your own DB, as well as various external sources, like social login across various platforms, is an absolute pain to configure and sometimes acts in stupid ways behind a reverse proxy, but has most of the features that you might ever want, which sadly comes coupled with some complexity and an enterprise feeling.

I quite like that it offers the login/registration views that you need with redirects, as well as user management, storing roles/permissions and other custom attributes. It's on par with what you'd expect and should serve you nicely.

mod_auth_openidc: https://github.com/OpenIDC/mod_auth_openidc

This one's a certified OpenID Connect Relying Party implementation for... Apache2/httpd.

Some might worry about the performance and there are other options out there (like a module for OpenResty, which is built on top of Nginx), but when coupled with mod_md Apache makes for a great reverse proxy/ingress for my personal needs.

The benefit here is that I don't need 10 different implementations for each service/back end language that's used, I can outsource the heavy lifting to mod_auth_openidc (protected paths, needed roles/permissions, redirect URLs, token renewal and other things) and just read a few trusted headers behind the reverse proxy if further checks are needed, which is easy in all technologies.

That said, the configuration there is also hard and annoying to do, as is working with OpenID Connect in general, even though you can kind of understand why that complexity is inherent. Here's a link with some certified implementations, by the way: https://openid.net/developers/certified-openid-connect-imple...

You couldn't pay me to use their bullshit...if you need an identity server/provider go with Keycloak. Open source, free, and standards based, works better and scales better too.

#docker-compose.yml version: '3' volumes: postgres_data: driver: local services: postgres: container_name: postgres image: postgres:15-alpine restart: unless-stopped volumes: - postgres_data:/var/lib/postgresql/data - ./init/db:/docker-entrypoint-initdb.d/ command: postgres -c wal_level=logical ports: - '5433:5432' environment: POSTGRES_DB: ${POSTGRES_DB} POSTGRES_USER: ${POSTGRES_USER} POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} hasura: container_name: hasura image: hasura/graphql-engine:v2.29.0 restart: unless-stopped depends_on: - postgres # - keycloak ports: - '6080:8080' volumes: - ./hasura/metadata:/hasura-metadata environment: ## postgres database to store Hasura metadata HASURA_GRAPHQL_METADATA_DATABASE_URL: postgres://${POSTGRES_USER}:${POSTGRES_PASSWORD}@postgres:5432/hasura_metadata HASURA_GRAPHQL_DATABASE_URL: postgres://${POSTGRES_USER}:${POSTGRES_PASSWORD}@postgres:5432/${POSTGRES_DB} HASURA_GRAPHQL_LOG_LEVEL: warn ## enable the console served by server HASURA_GRAPHQL_ENABLE_CONSOLE: 'true' # set to "false" to disable console ## enable debugging mode. It is recommended to disable this in production HASURA_GRAPHQL_DEV_MODE: 'true' HASURA_GRAPHQL_ENABLED_LOG_TYPES: startup, http-log, webhook-log, websocket-log, query-log ## enable jwt secret when keycloak realm is ready # HASURA_GRAPHQL_JWT_SECRET: '{ "type": "RS256", "jwk_url": "http://keycloak:8080/realms/development/protocol/openid-connect/certs" }' HASURA_GRAPHQL_ADMIN_SECRET: ${HASURA_GRAPHQL_ADMIN_SECRET} HASURA_GRAPHQL_UNAUTHORIZED_ROLE: anonymous HASURA_GRAPHQL_ENABLE_REMOTE_SCHEMA_PERMISSIONS: 'true' HASURA_GRAPHQL_MIGRATIONS_SERVER_TIMEOUT: 30 # To view tables in Postgres # pgweb: # container_name: pgweb # image: sosedoff/pgweb:latest # restart: unless-stopped # ports: # - '8081:8081' # environment: # - DATABASE_URL=postgres://${POSTGRES_USER}:${POSTGRES_PASSWORD}@postgres:5432/${POSTGRES_DB}?sslmode=disable # depends_on: # - postgres keycloak: container_name: keycloak image: quay.io/keycloak/keycloak:22.0.5 command: ['start-dev'] # Uncomment following if you want to import realm configuration on start up # command: ['start-dev', '--import-realm'] environment: ## https://www.keycloak.org/server/all-config KEYCLOAK_ADMIN: admin KEYCLOAK_ADMIN_PASSWORD: password123 KC_DB: postgres KC_DB_PASSWORD: postgres_pass KC_DB_USERNAME: postgres KC_DB_SCHEMA: public KC_DB_URL: jdbc:postgresql://postgres:5432/keycloak_db KC_HOSTNAME: localhost ports: - 8090:8080 depends_on: - postgres # Uncomment following if you want to import realm configuration on start up # volumes: # - ./realm-export.json:/opt/keycloak/data/import/realm.json:ro