https://www.keycloak.org/ is pretty great too, if you need a little more.
What do you mean a little more? More like several truckloads more. :) Keycloak is great, but it's a beast.
Keycloak is a lot less than some other OAuth servers though.
OpenAUTH: Universal, standards-based auth provider
41–50 of 76 posts
Re: OpenAUTH: Universal, standards-based auth provider
#42How 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?
Re: OpenAUTH: Universal, standards-based auth provider
#43Re: OpenAUTH: Universal, standards-based auth provider
#44Earlier quoted context omitted.
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.
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 in…
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.
Re: OpenAUTH: Universal, standards-based auth provider
#45I'm guessing this is for service providers and not identity providers. Just a suggestion, but that could be more clear in the description.
Re: OpenAUTH: Universal, standards-based auth provider
#46Cool 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 ap…
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 the…
> 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...
Re: OpenAUTH: Universal, standards-based auth provider
#47Earlier quoted context omitted.
Tradeoff is all the edge cases of cookies, CSRF etc. It's not a simple "cookies are better"
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…
> * 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.
Re: OpenAUTH: Universal, standards-based auth provider
#48Earlier quoted context omitted.
- 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 T…
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…
> we do, in fact, have secure implementations of SAML.
Do we?
I thought we only had implementations where with no currently known security problems.
Re: OpenAUTH: Universal, standards-based auth provider
#492024 and we still are not sure how to implement auth. Webdev is fantastic.
Re: OpenAUTH: Universal, standards-based auth provider
#50Earlier quoted context omitted.
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…
> we do, in fact, have secure implementations of SAML. Do we? I thought we only had implementations where with no currently known security problems.
> no currently known security problems
To be fair, that is the layman's definition of "secure"