WingNews logo WingNews GitHub [2]

cainlevy's comments

cainlevy | 8 years ago | on: Show HN: Keratin AuthN – Accounts and Auth Microservice in Go

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!

cainlevy | 8 years ago | on: Show HN: Keratin AuthN – Accounts and Auth Microservice in Go

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.

cainlevy | 8 years ago | on: Show HN: Keratin AuthN – Accounts and Auth Microservice in Go

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.

cainlevy | 8 years ago | on: Show HN: Keratin AuthN – Accounts and Auth Microservice in Go

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.

cainlevy | 8 years ago | on: Show HN: Keratin AuthN – Accounts and Auth Microservice in Go

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.

cainlevy | 8 years ago | on: Show HN: Keratin AuthN – Accounts and Auth Microservice in Go

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.

cainlevy | 8 years ago | on: Show HN: Keratin AuthN – Accounts and Auth Microservice in Go

Tests are colocated inside packages (folders) using a `_test.go` convention.

Service tests[1] are the main unit tests, and use mock implementations of the data store interfaces.

Data (DAO) tests[2] are generally run across every implementation using only the public interface. This helps me stay sane with the mock implementations.

The API tests[3] are integration tests, and use Go's excellent httptest package to boot a real server and execute real HTTP commands.

[1] https://github.com/keratin/authn-server/tree/master/services

[2] https://github.com/keratin/authn-server/tree/master/data

[3] https://github.com/keratin/authn-server/tree/master/api/acco...

cainlevy | 8 years ago | on: Show HN: Keratin AuthN – Accounts and Auth Microservice in Go

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.

cainlevy | 8 years ago | on: Show HN: Keratin AuthN – Accounts and Auth Microservice in Go

> Dex is NOT a user-management system, but acts as a portal to other identity providers through "connectors."

> ORY Hydra is not an identity provider (user sign up, user log in, password reset flow), but connects to your existing identity provider through a consent app.

AuthN IS all the things that Dex and Hydra say they are not. I'll bet it could integrate with both given a bit of investment, e.g. by satisfying the "consent app" expectations.

AuthN does use as much of the OpenID Connect protocol as I could manage though. I started there and streamlined down to optimize for API-driven interactions rather than the redirect-driven interactions that are common with OAuth and OIC.

cainlevy | 8 years ago | on: Show HN: Keratin AuthN – Accounts and Auth Microservice in Go

Auth0 is top-notch SaaS. I have only good things to say about their product.

Aside from being OSS, one major difference is that Keratin AuthN is purely an API. It's optimized for customization so that it will fit with any bespoke (secure) UX you want to provide. I found Auth0's API to be something of an after-thought, second to their hosted/branded/templatable pages.

cainlevy | 9 years ago | on: Relay Modern: Simpler, faster, more extensible

Oh? Seems like you still want to support old client versions, which means retaining the fragments that they reference. The question then is what implications that has on a server -- do old fragments need to be eventually garbage collected?
page 1
more