brokenwren

Using a byte encoding for element types and numeric values over strings would likely dramatically reduce sizes. For example:

<z:rect x="0" y="0" width="10" height="10"/>

Could be binary encoded as something like:

00 00000000 00000000 00000110 00000110

(shape, x, y, width, height)

Total size of compress XML is probably 30-40 bytes. Final binary size is 16-18 bytes.

> what if your webhook doesn't get processed quickly enough?

I'm assuming you mean at the edges. This is possible, but if you are on the same backplane, highly unlikely since our solution is simply inserting an int into a Hash. Even if it isn't backplane, then you still can retry. Think of session caches as the same situation, so really no difference if you have a distributed cache for (A). Also, FusionAuth provides configurable timeouts and transactions for Webhooks. This covers most failure cases.

> What if your client breaks and stops being able to accept webhooks?

I'm assuming you mean "service" rather than "client" since we want the services to know a JWT has been revoked. I'd say this should hopefully mean that the service is also not accepting API requests. If it is, then you will have issues. However, this is a failure case no matter what. Similarly, the client breaks and stops validating the JWT in (A), you are in the same situation. Plus, FusionAuth provides transactional Webhooks, so you can retry and protect against failures.

> What if the webhook server stops firing or gets overloaded?

Since FusionAuth is the Webhook event generator and the IdP, if it stops, you got bigger issues. :)

In terms of overloading, we protect against event backlogs and failures pretty well. We can also shut the entire node down if needed to prevent any API calls. This is a bit brute force, but if you are in #3 for security, turning everything off is better than a breach.

1. The shorter the lifetime, the more JWTs and refreshes are needed. This includes the signing and verification, both of which can be heavy operations depending on key length.

2. Token introspection is a coupling hub and spoke. If every service needs to introspect every JWT, it will be coupled to the introspect API. While that isn't horrible in some cases, it can be a nightmare in others. Additionally, new services need to always remember to use this pattern. You can get around this with an API gateway though. In either case, the introspection API either needs to store all the JWTs (in memory or a database) to determine if they have been revoked, or use some other mechanism to determine revocation. If you have large numbers of JWTs valid at any time, this doesn't scale well.

3. This is basically the same as my approach. It sounds like you are using a distributed cache. I'm using Webhooks and multiple local caches. Basically the same thing if your Webhooks are written properly.

And it integrates with AAD and ADFS.

While Elastic can be a bit cumbersome, we have made bundles that make it simpler to deploy and manage. We have also worked hard to secure it.

I haven't used Cognito, but I work for FusionAuth (https://fusionauth.io) and we have a number of developers that have switched from Cognito to FusionAuth because we cover more of their use cases outside of plain authentication.

Not sure if you have had similar experience with Cognito being limited.

I agree 100%. You need to own your users and all of their data. Along those same lines, I wouldn't want my user data going into a multi-tenant, cloud-hosted solution like Okta. I'd much prefer to store everything on my own servers or use an on-premise solution like FusionAuth or KeyCloak.

The community for FusionAuth is growing quickly and it has an open issue tracker (https://github.com/FusionAuth/fusionauth-issues), good docs (https://fusionauth.io/docs/v1/tech/), and many open source projects as well (https://github.com/FusionAuth).

I'm one of the developers of FusionAuth, so you should give it a try and lot us know what you think.

Anyone using Janrain and concerned about this acquisition?

Passwordless login is an interesting topic and it seems like other companies are pushing it hard. When it is done via an app on your phone, it appears to be more secure than via SMS. Similarly, email based login is only as secure as someone's email. Both of these methods of authentication rely on third-parties to implement the security well, which is not always the case.

As for MFA, both SMS and code based MFA are good solutions. SMS is a little less secure because phones can be cloned. The new Webauthn specification looks interesting and hopefully that will improve web based authentication considerably. Finally, the best solution currently still seems to be MFA devices like USB sticks.

The main issue with MFA is that it can be cumbersome for users to setup. The simplest version is SMS, which requires very little knowledge to setup correctly. However, this is also the least secure.

Always tradeoffs with security unfortunately.

I think what you are talking about is "SMS password reset", which is a different beast. And it also sounds like you are talking about SMS based identity verification for customer service representatives. If you are only using SMS for identity verification in your CSR workflow, that is a broken workflow.

In FusionAuth (https://fusionauth.io), we implemented SMS MFA that only works after the user has successfully put in their password. Therefore, the attacker would need their password and a clone of their phone. While this is still possible, the threat surface is quite small.

Chief -> Top, big cheese, main dude (or dudette)

Technology -> Like computers and stuff

Officer -> Simple definition: "Officers are responsible for the management and day-to-day operations of the corporation." You know, like making decisions and helping the company be successful.

If you fit into that description, even if you don't have that specific title, you are acting as a CTO. Lots of VPs of Engineering fit into that title. So do lots of CEOs of software companies.