Live data from Hacker News

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

keratin.tech

11–20 of 57 posts

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

#12
post #8
post #5

Earlier quoted context omitted.

I'd love to fill that in! If anyone would like a comparison, please add links in this thread and I'll reply. Later, I can collect it into a published page.

https://auth0.com I've just started dabbling on a small project and would be interested to understand how features overlap and differences in license/distribution model.

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.

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

#13
post #7
post #5

Earlier quoted context omitted.

I'd love to fill that in! If anyone would like a comparison, please add links in this thread and I'll reply. Later, I can collect it into a published page.

That would be great, thanks! Here are the links to the projects I mentioned. https://github.com/coreos/dex https://github.com/ory/hydra

> 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.

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

#14
post #9

Is SAML supported and if not is it planned in the near future ?

I'm currently investing in JWT and have not done enough research on SAML to make it part of my plans. Happy to learn more.

You might want to take a look at AWS-Cognito and their SAML and OAuth2.0 integration. For our enterprise startup, we are leaning towards Cognito to provide multi-tenant UserPools with customer specified authentication providers.

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

#15
post #11

Has Keratin gone through any security research / penetration testing?

I would dearly love that! The answer is not yet. Can you recommend any testers that are OSS-friendly?

My current plan is to set up a HackerOne page. I know that bug bounties don't replace good penetration testing, but it's a start.

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

#16

Today I was evaluating what I we should use for something like this, a unified Facade with an API. We evaluated Traefik and Kong. Decision was for Kong, since we need more features like auth, logging, rate limit.

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.

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

#18
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.

There are tests - they're colocated with the source, not in a separate tests folder, e.g. https://github.com/keratin/authn-server/tree/master/services

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

#20
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.

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...

Post reply on HN