21–30 of 76 posts
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?
Earlier quoted context omitted.
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.
https://www.keycloak.org/ is pretty great too, if you need a little more.
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.
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)
Earlier quoted context omitted.
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.
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.
Earlier quoted context omitted.
Less secure that HttpOnly cookies, which are not accessible by third-party JavaScript. LocalStorage also doesn't have automatic expiration.
Tradeoff is all the edge cases of cookies, CSRF etc. It's not a simple "cookies are better"
if you're doing things not from same-site, I'd posit you're doing something I want blocked anyways.
> 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…
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…
Auth0 has an option where you can use your own database for identities