cainlevy

Yeah. I think Travis provides a warmed server.

Thanks for the report! I believe I've tracked this down to an initialization routine that MySQL goes through on the first boot. It happens after docker-compose unblocks. Likely a wontfix. :/

Fixed, thanks!

That all sounds like a direction I'd happily consider:

* Google Cloud Storage implementations for data interfaces

* Metrics interface with a Prometheus implementation (STATSD to follow)

* Redis-backed HLL metrics are optional

Feel free to open issues in the tracker if you reach that point!

Thanks!

Have you seen the /stats endpoint? It exposes the metrics as JSON, which may be a good match for your suggestion. I'd also like to export the key events to a STATSD-compatible sink so a sophisticated user can manage metrics in their own system.

Redis is already on hand because of other features though, and HLL is a pretty cheap integration. I figure it's a decent starting point for many people.

Yep, it's very broad. Let's say it depends how "majestic" a person's monolith is? :D

One point of context I'd like to inject here is that chatter between AuthN and a host app is pretty minimal. Aside from executing admin actions like locking an account, the main dependency is fetching a public key to verify JWTs. This public key can be cached using a standard key fingerprint, which means it only needs to happen once per process.

Architecture does matter, and I've been pretty happy with how AuthN's boundary has played out.

It's on my roadmap. Prioritizing is hard. :/

Keycloak does some really great things. It does require managing a Java runtime though, and is missing the streamlining that allows AuthN to run as an invisible API.

Keycloak (and similar) hosts and renders your login page. You customize through theming. You're expected to redirect users through a standard OAuth2/OIDC flow on a different domain.

AuthN doesn't render any HTML. That's all you, from start to finish. This means you have control over the UX and can build the login page directly into your own app, just like you would when using an auth library in a typical monolith.

Yeah, I don't expect this JWT scheme to become an adopted standard. It's been streamlined from OIC for the narrow use case of working tightly with a trusted app.

Adding support for inbound federation is on the roadmap. Support for outbound federation using OIC isn't out of the question either, but I don't yet see the motivation.

Yeah, name/pass sounds pretty simple, doesn't it? But doing it correctly, securely, with a service architecture? That gets interesting.

> It would be much more interesting to me if it also did Oauth2 login with Google/Facebook/Twitter/etc.

Totally agreed. The reason I designed AuthN around accounts first is because I believe that's the best way to launch an app. OAuth2 and OIC logins are powerful, but they're secondary to the classic login.

Strong choice! My dream is for AuthN to provide authentication and account functionality for folks who have not yet invested in an API gateway, and then seamlessly plug in when their architecture matures later. Extracting user accounts can be a difficult barrier for transitions like that.