Live data from Hacker News

OpenAUTH: Universal, standards-based auth provider

openauth.js.org

11–20 of 76 posts

Re: OpenAUTH: Universal, standards-based auth provider

#11
post #4

Earlier quoted context omitted.

KV Stores aren't magical... and you do need to store this data somewhere . So what's different between this (or any of these new-aged Auth services) and something else more traditional? If anything, these new-age services make it easier to access your data if you need to, since you often control the backing database unlike auth0, etc. Both DynamoDB and Cloudflare KV are queriable. I guess I don't understand the negat…

I don’t think it’s the architecture or technology the commenter is reacting to, it’s this line: “You should never need to directly access any data that is stored in there.” Statements like that are a huge red flag that the designers of the product are not particularly experienced with operating this type of system at meaningful scale.

Eh, the technology stack they discuss is directly accessible, though.

I read this as an advertisement, meaning if everything it working well you don't need to manage the database. Which is probably how it works 99% of the time in fairness.

Re: OpenAUTH: Universal, standards-based auth provider

#12
post #10
post #7

Earlier quoted context omitted.

Disclosure: I work for FusionAuth. You should check out FusionAuth if you are looking at KeyCloak. We play in a similar same space (self-hostable, support for SAML, OIDC, OAuth2). I'd say KeyCloak has wider coverage for some of the more esoteric standards and is open source while we have a more modern API, dev-friendly docs, and great (paid) support. FusionAuth is not open source, but you can self-host it for free an…

Maybe I’m not your target audience but Yikes! Your pricing was unexpectedly high. Also it’s not clear what premium features were or why MFA is a premium feature but only available at top tiers.

To be fair, the pricing there is not out of line with other hosted SaaS auth services. The segmentation is also not out of line either.

However, the paywall (for all of these auth services) ends up being quite steep for the couple features that matter for a non-hobby app, such as custom domain name and MFA (totp or hooking up to an external SMS service). Unfortunately it makes these features expensive when you are starting out (paying ~$40 a month for only a handful of users, sort of thing...).

It is nice to see more and more of these services allow you to take out your data and migrate though - including the self-hosted options. Being vendor-locked for your user account data is a really big deal in my opinion. It often means having zero good options if the vendor decides to rake you over the coals one day.

Re: OpenAUTH: Universal, standards-based auth provider

#15
Happy to see the effort! Fresh blood in the authn space is always welcomed.

Without rehashing the other good points commenters have made already, I’ll just say that every project starts out immature. What makes a project great is how willing the maintainers will be to grow along with the project and incorporate feedback. I’m excited to see future evolutions of this one.

Re: OpenAUTH: Universal, standards-based auth provider

#16
post #13

Can we not call any authentication scheme/protocol/service starting with "Open" and even "O" anymore? We already have OAuth, OATH, OpenID, OpenIDConnect, and Okta; it's getting out of hand.

"Auth" is also super overloaded. OP is an authentication or AuthN tool which is not the same nor does it encompass authorization or AuthZ. I'm partial to using the terms "identity" and "permissions" instead.

Re: OpenAUTH: Universal, standards-based auth provider

#17
post #9

Good for them for trying! I've been in the auth space for a few years and am surprised that a stateless AWS lambda for doing the exchange. (At least I haven't seen any.) So it is nice to see some serverless innovation. Thoughts from a quick scan: - They support PKCE (yay!) - They suggest storing access tokens in localstorage (boo!) - They support JWKS (yay!)

What's wrong with tokens in local storage?

Re: OpenAUTH: Universal, standards-based auth provider

#19
Cool project!

OAuth-based auth providers are nice, but they can have a weakness. When you have just one app, OAuth can be overkill: protocol is complex, and users suffer jarring redirects¹.

This is not surprising, because OAuth / OIDC is fundamentally designed for (at least) three parties that don't fully trust each other: user, account provider and an app². But in a single app there are only two parties: user and app itself. Auth and app can fully trust each other, protocol can be simpler, and redirects can be avoided.

I'm curious what OpenAUTH authors think about it.

¹ Except for Resource Owner Password Credentials (ROPC) grant type, but it's no longer recommended: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-secur...

² In addition, OAuth is mostly designed for and by account providers, and follows their interests more than interests of app developers.

Re: OpenAUTH: Universal, standards-based auth provider

#20
post #17
post #9

Good for them for trying! I've been in the auth space for a few years and am surprised that a stateless AWS lambda for doing the exchange. (At least I haven't seen any.) So it is nice to see some serverless innovation. Thoughts from a quick scan: - They support PKCE (yay!) - They suggest storing access tokens in localstorage (boo!) - They support JWKS (yay!)

What's wrong with tokens in local storage?

Less secure that HttpOnly cookies, which are not accessible by third-party JavaScript. LocalStorage also doesn't have automatic expiration.
Post reply on HN