9 ms·

OpenAUTH: Universal, standards-based auth provider

194 points by jacobrussell 2y ago

chowells 2y ago
> While OpenAuth tries to be mostly stateless, it does need to store a minimal amount of data (refresh tokens, password hashes, etc). However this has been reduced to a simple KV store with various implementations for zero overhead systems like Cloudflare KV and DynamoDB. You should never need to directly access any data that is stored in there. Written like someone who's never actually maintained an identify provider used in B2B contract work. You will inevitably come into contact with people who cannot make things work on their side and are doing things so unexpectedly that logging is insufficient to track down the error. Sooner or later you will need to look at the data actually in storage to figure out what your customers who are threatening to cancel their contract are doing wrong. I've been there. Many times.
- Alupis 2y ago
  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 negativity in your comment. If anything, your complaint sounds like an issue you and your team cooked up on your own.
  - skywhopper 2y ago
    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.
    - Alupis 2y ago
      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.
      - inopinatus 2y ago
        The circumstances are immaterial; if the creators of a system are blasé enough to imagine you’ll neither need nor want to manage or query the underlying data storage, then they’re telegraphing naiveté and inexperience. Capacity, throughput, latency, consistency concerns exist in any nontrivial system and the pointy end/bottleneck of these is very often at the level of persistence. Auth services can add privacy and integrity to that pile. And so on. Consequently, glossing over it with a handwave is a bright red flag.
        IgorPartola 2y ago
        To me this statement read very differently. I read it as saying that the amount of state is small and portable enough that I wouldn’t have to worry about scalability issues or be married to a particular database product. I think the original complaint about it is overly critical and nit picking.
        thdxr 2y ago
        yes this was the intent
      - pixl97 2y ago
        99% of the time is a rather high rate of failure .. 1% of a year is still over 3 days. 1% of a million is still a lot of incidents
        afiori 2y ago
        Sure but you are allowed to put the 99% front and center in marketing. A good chunk of the other 1% are square-peg-in-round-home situations. It is good to support all the various edge cases but it is also on 6 to focus on the happy path
  - victor106 2y ago
    > since you often control the backing database unlike auth0, etc. Auth0 has an option where you can use your own database for identities
    - Alupis 2y ago
      Starting at $240 a month...
- pluto_modadic 2y ago
  [flagged]
- thdxr 2y ago
  all of the data in there will be exposed via an API and also directly queryable since it's in your infra but the idea here is openauth does not handle things like user storage - it just gives you callbacks to store the data in whatever database you're using precisely because of what you're talking about - eventually you need access to it
sontek 2y ago
Does it only support username/password + OAuth? I didn't see much information on if it supports SAML. I'm interested in how it compares to things like https://github.com/zitadel/zitadel https://github.com/zitadel/zitadel and https://github.com/ory/kratos https://github.com/ory/kratos
- reactordev 2y ago
  It looks like it’s strictly for OAuth 2.0 flows. No SAML, no ldap, no Kerberos, so it’s just a basic key exchange for those who can’t be bothered. Auth is hard and consumes too much sprint cycles, as is, so anything is welcome in this space. I personally will stick to keycloak.
  - Alupis 2y ago
    The people who require SAML, LDAP and Kerberos are often catering towards a specific userbase (ie. internal business customers). The needs for Auth & Auth are different for public-facing apps/services. It's not entirely unsurprising many newer Auth solutions don't even attempt to implement SAML et al. With all of the recent steep price hikes in the Auth SaaS space, it seems it's becoming increasingly important to actually own your user account data. By own, I mean have access to the database and be capable of migrating it somewhere else (even at a large inconvenience) if necessary. KeyCloak seems awesome for this - but I am liking the "explosion" of new Auth providers that seem to be popping up everywhere these days.
    - mooreds 2y ago
      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 and own your data[0]. Or let us run it for you. In the latter case, you still own your data--get it all from our cloud if you want to migrate. I'm proud that the team wrote an offboarding doc[1]. It's your darn customer data, and every provider should support out-migration. 0: https://fusionauth.io/download https://fusionauth.io/download 1: https://fusionauth.io/docs/lifecycle/migrate-users/offboard https://fusionauth.io/docs/lifecycle/migrate-users/offboard
mooreds 2y ago
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!)
- igor47 2y ago
  What's wrong with tokens in local storage?
  - ash 2y ago
    Less secure that HttpOnly cookies, which are not accessible by third-party JavaScript. LocalStorage also doesn't have automatic expiration.
    - zsims 2y ago
      Tradeoff is all the edge cases of cookies, CSRF etc. It's not a simple "cookies are better"
      - dylan604 2y ago
        enable same-site?? if you're doing things not from same-site, I'd posit you're doing something I want blocked anyways.
      - mooreds 2y ago
        But when you can use them, cookies are demonstrably better. XSS is the main argument against localstorage. Even this article[0], which pillories cookies, starts off with: ...if your website is vulnerable to XSS attacks, where a third party can run arbitrary scripts, your users’ tokens can be easily stolen [when stored in localstorage]. The reasons to avoid cookies: * APIs might require an authorization header in the browser fetch call. * APIs might live on a different domain, rendering cookies useless. CSRF is a danger, that's true. can be worked around. My understanding is that XSS has a wider scope and that many modern frameworks come with CSRF protection built in[1]. Whereas XSS is a risk any time you (or anyone in the future) includes any JS code on your website. 0: https://pilcrowonpaper.com/blog/local-storage-cookies/ https://pilcrowonpaper.com/blog/local-storage-cookies/ 1: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...
sedatk 2y ago
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.
- jzelinskie 2y ago
  "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.
  - mstade 2y ago
    The example in the video even has the name `authorizer` in the default export, but really it's an `authenticator` or `identifyer` or `isThisUserWhoTheySayTheyArer` – not a `shouldTheyHaveAccessizer`. I'm in total agreement with you but I guess the AuthN/AuthZ train left the station ages ago and no one outside of the business of selling these tools actually care. Oh well.. :o)
    - thdxr 2y ago
      yeah this is a naming mistake a realized but thankfully in beta so can rework it it used to be called authenticator! mixed it up unintentionally
- mooreds 2y ago
  Don't forget "Auth0". I've definitely talked to devs who were confused about the difference between Auth0 and OAuth. Which, by the way, is a testament to how great the Auth0 brand is.
MarthaIrene528 2y ago
[dead]
ptcrash 2y ago
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.
XCSme 2y ago
Is this like a Passport.js alternative? https://www.passportjs.org/ https://www.passportjs.org/
ash 2y ago
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-security-topics#section-2.4 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.
- lstamour 2y ago
  It's fair to say that with OAuth the resource owner can choose to display a consent screen or not. For example, when consent is granted already, it can be skipped if the resource owner does not need it. Likewise, Google Workspace and other enterprise services that use OAuth can configure in advance which apps are trusted and thus skip permission grants. Not to say the concern about redirects isn't legitimate, but there are other ways of handling this. Even redirects aren't necessary if OAuth is implemented in a browser-less or embedded browser fashion, e.g. SFAuthenticationSession for one non-standard example. I haven't looked this up in awhile but I believe the OAuth protocol was being extended more and more to other contexts beyond the browser - e.g. code flow or new app-based flows and even QR auth flows for TV or sharing prompts. (Note I am not commenting on OpenAUTH, just OAuth in general. It's complex, yes, but not as bad as it might seem at first glance. It's just not implemented in a standard way across every provider. Something like PassKeys might one day replace it.)
  - portaouflop 2y ago
    > Even redirects aren't necessary if OAuth is implemented in a browser-less or embedded browser fashion, e.g. SFAuthenticationSession Can you please expand on that or give me some hints what to look at? I have never heard of this before and I work with Oauth2 a lot. When I look for SFAuthenticationSession it seems to be specific to Safari and also deprecated. I always share this article because people overimplement OAuth2 for everything, it’s not a hammer: https://www.ory.sh/oauth2-openid-connect-do-you-need-use-cases-examples/ https://www.ory.sh/oauth2-openid-connect-do-you-need-use-cas...
xupybd 2y ago
https://www.keycloak.org/ https://www.keycloak.org/ is pretty great too, if you need a little more.
- pestaa 2y ago
  What do you mean a little more? More like several truckloads more. :) Keycloak is great, but it's a beast.
  - xupybd 2y ago
    It's a typical speech pattern here in NZ. A little more when you mean a lot. Sorry I forget to translate for international audiences. :)
  - Aeolun 2y ago
    Keycloak is a lot less than some other OAuth servers though.
    - xupybd 2y ago
      What's it missing?
throwaway984393 2y ago
[dead]
harrisi 2y ago
https://youtu.be/mKKx8uXw5ak https://youtu.be/mKKx8uXw5ak
vivzkestrel 2y ago
How does this compare to supertokens https://supertokens.com/ https://supertokens.com/ that supports fastify express, hono, bun, koa, nuxt, react, vue, angular with email password + social login + OTP based login + single sign on all wrapped in a self hostable nice package?
- nicognaw 2y ago
  OpenAuthJs is literally a hono app.
thayne 2y ago
I'm guessing this is for service providers and not identity providers. Just a suggestion, but that could be more clear in the description.
pomfrit 2y ago
2024 and we still are not sure how to implement auth. Webdev is fantastic.
apitman 2y ago
Trying to understand where this fits in to the current ecosystem. Looks like it's sort of like Passport but it runs in a separate server, and apps use OAuth2 to communicate with it? The example video looks like it's only doing authentication. Does it do any authorization? Do apps need to use OpenAuth libraries directly, or can they get back with basic cookies/redirects/etc?

194 points by jacobrussell 2y ago

> While OpenAuth tries to be mostly stateless, it does need to store a minimal amount of data (refresh tokens, password hashes, etc). However this has been reduced to a simple KV store with various implementations for zero overhead systems like Cloudflare KV and DynamoDB. You should never need to directly access any data that is stored in there. Written like someone who's never actually maintained an identify provider used in B2B contract work. You will inevitably come into contact with people who cannot make things work on their side and are doing things so unexpectedly that logging is insufficient to track down the error. Sooner or later you will need to look at the data actually in storage to figure out what your customers who are threatening to cancel their contract are doing wrong. I've been there. Many times.

Alupis 2y ago
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 negativity in your comment. If anything, your complaint sounds like an issue you and your team cooked up on your own.
- skywhopper 2y ago
  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.
  - Alupis 2y ago
    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.
    - inopinatus 2y ago
      The circumstances are immaterial; if the creators of a system are blasé enough to imagine you’ll neither need nor want to manage or query the underlying data storage, then they’re telegraphing naiveté and inexperience. Capacity, throughput, latency, consistency concerns exist in any nontrivial system and the pointy end/bottleneck of these is very often at the level of persistence. Auth services can add privacy and integrity to that pile. And so on. Consequently, glossing over it with a handwave is a bright red flag.
      - IgorPartola 2y ago
        To me this statement read very differently. I read it as saying that the amount of state is small and portable enough that I wouldn’t have to worry about scalability issues or be married to a particular database product. I think the original complaint about it is overly critical and nit picking.
        thdxr 2y ago
        yes this was the intent
    - pixl97 2y ago
      99% of the time is a rather high rate of failure .. 1% of a year is still over 3 days. 1% of a million is still a lot of incidents
      - afiori 2y ago
        Sure but you are allowed to put the 99% front and center in marketing. A good chunk of the other 1% are square-peg-in-round-home situations. It is good to support all the various edge cases but it is also on 6 to focus on the happy path
- victor106 2y ago
  > since you often control the backing database unlike auth0, etc. Auth0 has an option where you can use your own database for identities
  - Alupis 2y ago
    Starting at $240 a month...
pluto_modadic 2y ago
[flagged]
thdxr 2y ago
all of the data in there will be exposed via an API and also directly queryable since it's in your infra but the idea here is openauth does not handle things like user storage - it just gives you callbacks to store the data in whatever database you're using precisely because of what you're talking about - eventually you need access to it

sontek 2y ago

Does it only support username/password + OAuth? I didn't see much information on if it supports SAML. I'm interested in how it compares to things like https://github.com/zitadel/zitadel https://github.com/zitadel/zitadel and https://github.com/ory/kratos https://github.com/ory/kratos

reactordev 2y ago
It looks like it’s strictly for OAuth 2.0 flows. No SAML, no ldap, no Kerberos, so it’s just a basic key exchange for those who can’t be bothered. Auth is hard and consumes too much sprint cycles, as is, so anything is welcome in this space. I personally will stick to keycloak.
- Alupis 2y ago
  The people who require SAML, LDAP and Kerberos are often catering towards a specific userbase (ie. internal business customers). The needs for Auth & Auth are different for public-facing apps/services. It's not entirely unsurprising many newer Auth solutions don't even attempt to implement SAML et al. With all of the recent steep price hikes in the Auth SaaS space, it seems it's becoming increasingly important to actually own your user account data. By own, I mean have access to the database and be capable of migrating it somewhere else (even at a large inconvenience) if necessary. KeyCloak seems awesome for this - but I am liking the "explosion" of new Auth providers that seem to be popping up everywhere these days.
  - mooreds 2y ago
    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 and own your data[0]. Or let us run it for you. In the latter case, you still own your data--get it all from our cloud if you want to migrate. I'm proud that the team wrote an offboarding doc[1]. It's your darn customer data, and every provider should support out-migration. 0: https://fusionauth.io/download https://fusionauth.io/download 1: https://fusionauth.io/docs/lifecycle/migrate-users/offboard https://fusionauth.io/docs/lifecycle/migrate-users/offboard

mooreds 2y ago

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!)

igor47 2y ago
What's wrong with tokens in local storage?
- ash 2y ago
  Less secure that HttpOnly cookies, which are not accessible by third-party JavaScript. LocalStorage also doesn't have automatic expiration.
  - zsims 2y ago
    Tradeoff is all the edge cases of cookies, CSRF etc. It's not a simple "cookies are better"
    - dylan604 2y ago
      enable same-site?? if you're doing things not from same-site, I'd posit you're doing something I want blocked anyways.
    - mooreds 2y ago
      But when you can use them, cookies are demonstrably better. XSS is the main argument against localstorage. Even this article[0], which pillories cookies, starts off with: ...if your website is vulnerable to XSS attacks, where a third party can run arbitrary scripts, your users’ tokens can be easily stolen [when stored in localstorage]. The reasons to avoid cookies: * APIs might require an authorization header in the browser fetch call. * APIs might live on a different domain, rendering cookies useless. CSRF is a danger, that's true. can be worked around. My understanding is that XSS has a wider scope and that many modern frameworks come with CSRF protection built in[1]. Whereas XSS is a risk any time you (or anyone in the future) includes any JS code on your website. 0: https://pilcrowonpaper.com/blog/local-storage-cookies/ https://pilcrowonpaper.com/blog/local-storage-cookies/ 1: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...

sedatk 2y ago

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.

jzelinskie 2y ago
"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.
- mstade 2y ago
  The example in the video even has the name `authorizer` in the default export, but really it's an `authenticator` or `identifyer` or `isThisUserWhoTheySayTheyArer` – not a `shouldTheyHaveAccessizer`. I'm in total agreement with you but I guess the AuthN/AuthZ train left the station ages ago and no one outside of the business of selling these tools actually care. Oh well.. :o)
  - thdxr 2y ago
    yeah this is a naming mistake a realized but thankfully in beta so can rework it it used to be called authenticator! mixed it up unintentionally
mooreds 2y ago
Don't forget "Auth0". I've definitely talked to devs who were confused about the difference between Auth0 and OAuth. Which, by the way, is a testament to how great the Auth0 brand is.

MarthaIrene528 2y ago

[dead]

ptcrash 2y ago

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.

XCSme 2y ago

Is this like a Passport.js alternative? https://www.passportjs.org/ https://www.passportjs.org/

ash 2y ago

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-security-topics#section-2.4 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.

lstamour 2y ago
It's fair to say that with OAuth the resource owner can choose to display a consent screen or not. For example, when consent is granted already, it can be skipped if the resource owner does not need it. Likewise, Google Workspace and other enterprise services that use OAuth can configure in advance which apps are trusted and thus skip permission grants. Not to say the concern about redirects isn't legitimate, but there are other ways of handling this. Even redirects aren't necessary if OAuth is implemented in a browser-less or embedded browser fashion, e.g. SFAuthenticationSession for one non-standard example. I haven't looked this up in awhile but I believe the OAuth protocol was being extended more and more to other contexts beyond the browser - e.g. code flow or new app-based flows and even QR auth flows for TV or sharing prompts. (Note I am not commenting on OpenAUTH, just OAuth in general. It's complex, yes, but not as bad as it might seem at first glance. It's just not implemented in a standard way across every provider. Something like PassKeys might one day replace it.)
- portaouflop 2y ago
  > Even redirects aren't necessary if OAuth is implemented in a browser-less or embedded browser fashion, e.g. SFAuthenticationSession Can you please expand on that or give me some hints what to look at? I have never heard of this before and I work with Oauth2 a lot. When I look for SFAuthenticationSession it seems to be specific to Safari and also deprecated. I always share this article because people overimplement OAuth2 for everything, it’s not a hammer: https://www.ory.sh/oauth2-openid-connect-do-you-need-use-cases-examples/ https://www.ory.sh/oauth2-openid-connect-do-you-need-use-cas...

xupybd 2y ago

https://www.keycloak.org/ https://www.keycloak.org/ is pretty great too, if you need a little more.

pestaa 2y ago
What do you mean a little more? More like several truckloads more. :) Keycloak is great, but it's a beast.
- xupybd 2y ago
  It's a typical speech pattern here in NZ. A little more when you mean a lot. Sorry I forget to translate for international audiences. :)
- Aeolun 2y ago
  Keycloak is a lot less than some other OAuth servers though.
  - xupybd 2y ago
    What's it missing?

throwaway984393 2y ago

[dead]

harrisi 2y ago

https://youtu.be/mKKx8uXw5ak https://youtu.be/mKKx8uXw5ak

vivzkestrel 2y ago

How does this compare to supertokens https://supertokens.com/ https://supertokens.com/ that supports fastify express, hono, bun, koa, nuxt, react, vue, angular with email password + social login + OTP based login + single sign on all wrapped in a self hostable nice package?

nicognaw 2y ago
OpenAuthJs is literally a hono app.

thayne 2y ago

I'm guessing this is for service providers and not identity providers. Just a suggestion, but that could be more clear in the description.

pomfrit 2y ago

2024 and we still are not sure how to implement auth. Webdev is fantastic.

apitman 2y ago

Trying to understand where this fits in to the current ecosystem. Looks like it's sort of like Passport but it runs in a separate server, and apps use OAuth2 to communicate with it? The example video looks like it's only doing authentication. Does it do any authorization? Do apps need to use OpenAuth libraries directly, or can they get back with basic cookies/redirects/etc?