Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Keratin AuthN – Accounts and Auth Microservice in Go

keratin.tech

Post reply on HN
Print view View original

21–30 of 57 posts

Re: Show HN: Keratin AuthN – Accounts and Auth Microservice in Go

#21

Post by Lord_Zero »

je42 wrote: post #17

almost no test coverage. did i miss them ? for proper use in production you would need to have hundreds of unittests and a whole bunch of component + integration and e2e tests.

Check the make file:

https://github.com/keratin/authn-server/blob/master/Makefile...

Notice it runs "go test $(shell glide nv)"

`glide nv` is a command that gets you all packages except the vendor directory https://github.com/Masterminds/glide#glide-novendor-aliased-...

then read the go doc for test https://golang.org/cmd/go/#hdr-Test_packages:

> 'Go test' recompiles each package along with any files with names matching the file pattern "*_test.go".

Re: Show HN: Keratin AuthN – Accounts and Auth Microservice in Go

#22

Post by cainlevy »

brianolson wrote: post #19

It's just name/pass It would be much more interesting to me if it also did Oauth2 login with Google/Facebook/Twitter/etc.

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.

Re: Show HN: Keratin AuthN – Accounts and Auth Microservice in Go

#25

Post by mindcrash »

krullie wrote: post #3

How does it compare to Hydra/Dex? What I'm missing is a page that tells me where it sits in the ecosystem. A versus page if you will.

Hydra and Dex both support OAuth and OpenID Connect. This apparently supports neither, but comes with its own JWT structure.

With inbound federation that shouldn't be much of a problem, but with outbound federation you'll have some very difficult questions to answer (especially because all major identity solutions are pretty much OIC centric these days)

Re: Show HN: Keratin AuthN – Accounts and Auth Microservice in Go

#26

Post by cainlevy »

mindcrash wrote: post #25
krullie wrote: post #3

How does it compare to Hydra/Dex? What I'm missing is a page that tells me where it sits in the ecosystem. A versus page if you will.

Hydra and Dex both support OAuth and OpenID Connect. This apparently supports neither, but comes with its own JWT structure. With inbound federation that shouldn't be much of a problem, but with outbound federation you'll have some very difficult questions to answer (especially because all major identity solutions are pretty much OIC centric these days)

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.

Re: Show HN: Keratin AuthN – Accounts and Auth Microservice in Go

#28

Post by ShabbosGoy »

ahoka wrote: post #24

"Microservices perform better, especially when written in Go." Nonsense.

Sort of agree, that's a very noisy and broad statement. I'd argue that the underlying I/O and event loop implementation matters more. At the end of the day it's all about highly available systems. Am I wrong?

Re: Show HN: Keratin AuthN – Accounts and Auth Microservice in Go

#30

Post by cainlevy »

nmenglund wrote: post #29

How does AuthN compare to Keycloak? http://www.keycloak.org

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.

Post reply on HN