[HN Gopher] OpenAUTH: Universal, standards-based auth provider
___________________________________________________________________
OpenAUTH: Universal, standards-based auth provider
Author : jacobrussell
Score : 177 points
Date : 2024-12-16 01:17 UTC (2 days ago)
(HTM) web link (openauth.js.org)
(TXT) w3m dump (openauth.js.org)
| chowells wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| The circumstances are immaterial; if the creators of a
| system are blase enough to imagine you'll neither need
| nor want to manage or query the underlying data storage,
| then they're telegraphing naivete 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 wrote:
| 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 wrote:
| yes this was the intent
| pixl97 wrote:
| 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 wrote:
| 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 wrote:
| > since you often control the backing database unlike auth0,
| etc.
|
| Auth0 has an option where you can use your own database for
| identities
| Alupis wrote:
| Starting at $240 a month...
| thdxr wrote:
| 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 wrote:
| 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 and
| https://github.com/ory/kratos
| reactordev wrote:
| 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 wrote:
| 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 wrote:
| 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
|
| 1: https://fusionauth.io/docs/lifecycle/migrate-
| users/offboard
| efitz wrote:
| 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.
| Alupis wrote:
| 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.
| mooreds wrote:
| Hiya, thanks for the feedback.
|
| TOTP based MFA is included in the free, community plan.
|
| As I mentioned elsewhere, for folks who are price
| conscious, self-hosting is the better option.
|
| But I get it! The story I tell internally all the time is
| that when I was working at a startup, our entirely
| hosting bill was on the order of $200/month (on Heroku;
| it was a while ago). There's no way we would have paid
| $350 just for an identity solution. But we would probably
| have chosen to host FusionAuth community on heroku for
| much much less and operated it ourselves.
|
| Anyway, thanks for your feedback.
| mooreds wrote:
| Hiya, thanks for the response.
|
| Our pricing is kinda complicated as discussed before[0].
| We're working on simplifying things.
|
| Here's a list of features[1] which hopefully are clearer
| about what you get on what plans.
|
| Where things get complex is that we sell both
| features/support and hosting, and you can buy both,
| either or neither from us. Our hosting isn't multi-tenant
| SaaS, but rather dedicated infrastructure providing
| network and database level isolation. That means what we
| offer is different than say a Stytch that offers a multi-
| tenant logical isolation.
|
| Most folks that are price conscious run it themselves on
| EC2 or Render or elsewhere[2].
|
| 0: https://news.ycombinator.com/item?id=41269197
|
| 1: https://fusionauth.io/feature-list
|
| 2: Here's render instructions:
| https://fusionauth.io/blog/fusionauth-on-render
| sontek wrote:
| Most b2b products are going to need SAML auth. Any
| reasonably sized tech business will want to onboard their
| employees into the software through SSO and the easiest way
| to do that is usually SAML if they are using something like
| Okta or JumpCloud.
|
| Along with that, if they have compliance requirements like
| SOC2 then they really want the whole flow including
| offboarding any employees that have left the company.
| Alupis wrote:
| You are describing enterprise, not normal b2b. Majority
| of businesses out there buying SaaS/PaaS products are not
| big enterprise with SSO needs nor compliance
| requirements. The SMB market is _huge_.
|
| Enterprise types of users are their own beast.
| thdxr wrote:
| we will add SAML adapters as well
|
| but the flow between your apps and openauth will always be
| oauth
| mooreds wrote:
| 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 wrote:
| What's wrong with tokens in local storage?
| ash wrote:
| Less secure that HttpOnly cookies, which are not accessible
| by third-party JavaScript. LocalStorage also doesn't have
| automatic expiration.
| zsims wrote:
| Tradeoff is all the edge cases of cookies, CSRF etc. It's
| not a simple "cookies are better"
| dylan604 wrote:
| enable same-site??
|
| if you're doing things not from same-site, I'd posit
| you're doing something I want blocked anyways.
| mooreds wrote:
| 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/
|
| 1: https://cheatsheetseries.owasp.org/cheatsheets/Cross-
| Site_Re...
| arkh wrote:
| > * APIs might live on a different domain, rendering
| cookies useless.
|
| That's when you implement a BFF which manages your tokens
| and shares a session cookie with your frontend while
| proxying all requests to your APIs. And as said, you
| "just" have to setup a way for your BFF to share CSRF
| tokens with your frontend.
| mooreds wrote:
| Yup, big fan of the BFF. Philippe de Ryck did a
| presentation on the fundamental insecurity of token
| storage on the client that he allowed us to share:
| https://www.youtube.com/watch?v=2nVYLruX76M
|
| If you can't use cookies (which as mentioned above, have
| limits) and you can't use a solution like DPoP (which
| binds tokens to clients but is not widely deployed), then
| use the BFF. This obviously has other non-security
| related impacts and is still vulnerable to session
| riding, but the tokens can't be stolen.
| arkh wrote:
| > Philippe de Ryck
|
| Almost certain it is one of those presentations which got
| me on the BFF bandwagon. Really awesome speaker.
| unscaled wrote:
| CSRF is not as big of an issue as it used to be, and when
| it is an issue it can be solved more easily and
| comprehensively than XSS:
|
| 1. The default value for SameSite attribute is now "Lax"
| in most browsers. This means that unless you explicitly
| set your authentication cookies to SameSite=None (and why
| would you?), you are generally not vulnerable to cookie-
| based CSRF (other forms of CSRF are still possible, but
| not relevant to the issue of storing tokens in local
| storage or cookies).
|
| 2. Most modern SSR and hybrid frameworks have built-in
| CSRF protection for forms and you have to explicitly
| disable that protection in order to be vulnerable to
| CSRF.
|
| 3. APIs which support cookie authentication for SPAs can
| be deployed on another domain and use CORS headers to
| prevent CSRF, even with SameSite=None cookies.
|
| On the other hand, there are no mechanisms which offer
| comprehensive protection from XSS. It's enough for a
| single JavaScript dependency that you use to have a bug
| and it's game over.
|
| For this reason, OAuth 2.0 for Browser-Based Applications
| (draft)[1] strongly recommends using a HttpOnly cookie to
| store the access token:
|
| "This architecture (using a BFF with HttpOnly cookies) is
| strongly recommended for business applications, sensitive
| applications, and applications that handle personal
| data."
|
| With regards to storing access tokens and refresh tokens
| on local storage without any protection it says:
|
| "To summarize, the architecture of a browser-based OAuth
| client application is straightforward, but results in a
| significant increase in the attack surface of the
| application. The attacker is not only able to hijack the
| client, but also to extract a full-featured set of tokens
| from the browser-based application.This architecture is
| not recommended for business applications, sensitive
| applications, and applications that handle personal
| data."
|
| And this is what it has to say about storing the refresh
| token in a cookie, while keeping the access token
| accessible to JavaScript:
|
| "When considering a token-mediating backend architecture
| (= storing only access token in local storage), it is
| strongly recommended to evaluate if adopting a full BFF
| (storing all tokens in a cookie) as discussed in Section
| 6.1 is a viable alternative. Only when the use cases or
| system requirements would prevent the use of a proxying
| BFF should the token-mediating backend be considered over
| a full BFF."
|
| In short, the official OAuth WG stance is very clear:
|
| 1. HttpOnly cookies ARE better in terms of security. 2.
| Storing Refresh Tokens in local storage is only
| recommended for low-security use cases (no personal data,
| no enterprise compliance requirements). 3. Storing short-
| lived Access Tokens in local storage should only be
| considered if there are technical complexities that
| prevent you from using only cookies.
|
| [1] https://datatracker.ietf.org/doc/html/draft-ietf-
| oauth-brows...
| rcaught wrote:
| Malicious access to these tokens is malicious access to the
| service.
| unscaled wrote:
| - JWT algorithm is not configurable: good!
|
| - JWT Algorithm is RS512: uggh.
|
| Huge access tokens, slow validation AND bad security at the
| same time, boy we must be lucky.
|
| - Encrypted JWT when saving sensitive information in cookie?
| Good start...
|
| - ... Using Asymmetric encryption? Oh no...
|
| - RSA-OAEP: At least it's not PKCS#1.5 amirite?
|
| - Same RSA key is used for encryption and signature(?) Not
| great.
|
| - Stateful Access Tokens: well...
|
| I'm not sure how I feel about using stateful access tokens here
| at all. Since there is already a KV dependency, there are some
| advantages to storing stateful access tokens in the KV, most
| importantly you can easily revoke the tokens directly by
| deleting them. Revoking stateless tokens, on the other hand, is
| quite hard and not something that most web applications would
| care to implement.
|
| The most common trade-off (and indeed, half of the raison
| d'etre for OAuth 2.0 refresh tokens) is to have a very short-
| lived (e.g. 5 minutes) stateless access token and a long-lived
| stateful refresh token (which OpenAUTH already does).
| Revocation would still come with some delay, but you won't be
| able to use an outdated token for a long time after the user
| logs out or changes password. This is an acceptable trade-off
| for many applications, but I'm not sure if it's right to offer
| it as the only solution in a software package that wants to be
| generic: many applications will have compliance requirements
| that could rule out accepting logged out session tokens for
| such a period.
|
| - JWT in any form or manner
|
| The elephant in the room. Since JWT allows you to choose your
| own algorithm and offers some some rather bad options, using
| JWT can be considered as "Rolling your own crypto Lite". You
| have a lot of choices here and if you are not an expert you're
| bound to make some wrong choices: such as the ones I've listed
| above. If OpenAUTH had used PASETO for its tokens, it wouldn't
| be running into these issues at least since no clearly insecure
| options are available.
|
| If you do use JWT, for the love of all that is good, never
| stray away from this path:
|
| 1. For symmetric tokens, use the HS* family of algorithms.
| That's the only available option anyway.
|
| 2. When using HS256/384/512, you should use randomly generated
| secrets from /dev/urandom [1]. The secret size in bits should
| be the same size as the HS algorithm bits (i.e. 32 bytes for
| HS256, 48 bytes for HS384 and 64 bytes for HS512). In any case,
| you should NEVER use passwords as the HS256/384/512 algorithm
| secret.
|
| 3. Do not use asymmetric tokens unless the there are are
| multiple token verifying parties which are separate from the
| token issuer. If the token issuer is the same as the verifier,
| you should use a symmetric token. If you've got one issuer and
| one verifier, you should probably still use a symmetric token
| with a shared secret, since there is no issue of trust.
| Asymmetric cryptography is always an order of magnitude easier
| to screw up than symmetric cryptography.
|
| 4. If you do use asymmetric cryptography, always use Ed25519.
| If you are forced to use something else for compatibility, use
| ES256/384/512. It still has some issues (especially if your
| random number generator is unreliable), but it's still better
| than RSA. You really want to use Ed25519 though.
|
| 5. If you want to encrypt JWT, don't. JWE is too hard to use
| correctly, and the only reliably secure option that is usually
| implemented by libraries (A256GCMKW) is slow and it's not very
| popular so I'm not sure how much analysis the algorithm (AES
| Key Wrap) has seen.
|
| 6. The best and easiest option for encryption if you really
| must use JWT (and can't use PASETO): Just take your payload,
| encrypt it with NaCl/Libsodium (secretbox[2]), base64 encode
| the result and stuff it inside a JWT claim. This will be
| faster, easier and more secure than anything JWE can offer.
|
| [1] https://www.latacora.com/blog/2018/04/03/cryptographic-
| right...
|
| [2] https://libsodium.gitbook.io/doc/secret-
| key_cryptography/sec...
| unscaled wrote:
| There is already a closed ticket about JWT usage.
| Unfortunately the ticket author did not point at any specific
| weaknesses besides revocation to which the app author
| answered:
|
| "JWTs aren't innately problematic - they come with the
| tradeoff of not being able to be revoked. The ideal setup is
| setting a short expiry time on the access_token (eg 5min) and
| setting a long expiry on the refresh token (which is not a
| JWT and can be revoked)."
|
| The fact that this tradeoff is acceptable to some apps is
| correct. But I disagree that JWT tokens aren't innately
| problematic. Stateless tokens aren't innately problematic.
| Even stateless access tokens aren't innately problematic if
| you're willing to live with the tradeoffs (revocation delay
| or a centralized/propagated revocation list). But JWT _is_
| innately problematic, in the most literal sense possibly: the
| very nature of the JWT specification is to permit the largest
| amount of cryptographic flexibility including supporting (and
| even recommending) insecure cryptographic algorithms, that
| may cause security problems if chosen. In other words: it is
| innately (= in its very nature) problematic (= has the
| potential of causing problems). JWT is the poster child of
| being "innately problematic".
|
| I think the app author confuses "innately problematic" with
| "impossible to implement securely". JWT is not impossible to
| implement securely. After all, even SAML with the nefarious
| XMLdsig is possible to implement securely and we do, in fact,
| have secure implementations of SAML. The real problem is that
| JWT is _hard_ to implement securely if you do not have the
| right expertise. And OpenAUTH is giving us (yet another)
| clear example where the JWT implementation is less than
| ideal.
|
| I will be the first to admit that I am not expert enough to
| know how to hack this kind of cryptography, but I am also not
| good enough to prove that it is safe to use.
| michaelt wrote:
| _> we do, in fact, have secure implementations of SAML._
|
| Do we?
|
| I thought we only had implementations where with no
| _currently known_ security problems.
| swiftcoder wrote:
| > no currently known security problems
|
| To be fair, that is the layman's definition of "secure"
| xmodem wrote:
| > If you do use asymmetric cryptography, always use Ed25519
|
| What about secp256k1 / ES256K?
| thdxr wrote:
| thanks for writing this up! i have been looking at switching
| to PASETO instead of jwt
|
| one thing though - the reason we use asymmetric encryption is
| to allow other clients to validate tokens without calling a
| central server
|
| eg if you use AWS API Gateway they specifically have jwt
| authorization support where you can point them to a jwks url
| and it will validate requests
|
| i need to look into the algorithm again - another constraint
| was trying to work across everywhere JS runs and i need to
| check if a better algorithm can be used that still works
| everywhere
| sedatk wrote:
| 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 wrote:
| "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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| ptcrash wrote:
| 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 wrote:
| Is this like a Passport.js alternative?
|
| https://www.passportjs.org/
| ash wrote:
| 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 redirects1.
|
| 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 app2. 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.
|
| 1 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...
|
| 2 In addition, OAuth is mostly designed for and by account
| providers, and follows their interests more than interests of app
| developers.
| lstamour wrote:
| 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 wrote:
| > 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-
| cas...
| afiori wrote:
| My personal gripe with OAuth is that the simple case can be
| implemented with like 2 redirects and 2 curls, but docs are
| often incomprehensibly complicated by dozens of layers of
| abstractions, services, extensions, enterprise account
| management and such.
| xupybd wrote:
| https://www.keycloak.org/ is pretty great too, if you need a
| little more.
| pestaa wrote:
| What do you mean a little more? More like several truckloads
| more. :) Keycloak is great, but it's a beast.
| xupybd wrote:
| 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 wrote:
| Keycloak is a lot less than some other OAuth servers though.
| xupybd wrote:
| What's it missing?
| harrisi wrote:
| https://youtu.be/mKKx8uXw5ak
| vivzkestrel wrote:
| How does this compare to supertokens 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 wrote:
| OpenAuthJs is literally a hono app.
| thayne wrote:
| 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 wrote:
| 2024 and we still are not sure how to implement auth. Webdev is
| fantastic.
| apitman wrote:
| 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?
___________________________________________________________________
(page generated 2024-12-18 23:02 UTC)