OpenAUTH: Universal, standards-based auth provider

- 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'être 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...

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...

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.

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

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