51–60 of 76 posts
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?
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!)
- 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…
What about secp256k1 / ES256K?
Earlier quoted context omitted.
"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.
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)
it used to be called authenticator! mixed it up unintentionally
> 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 provide…
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
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
but the flow between your apps and openauth will always be oauth
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!)
- 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…
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
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
> * 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.
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 relat…
Almost certain it is one of those presentations which got me on the BFF bandwagon. Really awesome speaker.
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.
Which, by the way, is a testament to how great the Auth0 brand is.