[donatj]

> there are far more secure and efficient ways of then verifying what the user is allowed to do, such as calling the IAM directly from the backend service or by implementing a more complex permissions service.

Making another call over the network for auth is by definition vastly less efficient by several orders vs having been handed the information in the first place. The bottleneck of a centralized permission service is actually what pushed us to JWT in the first place.

Using JWTs to authenticate the user allows actual decentralization of your endpoints. We have services that speak directly to nothing else in the ecosystem and it’s a major win.

The security argument is valid to a small extent, but I’ll trust a well salted SHA256 with my life until I’m told otherwise.

[mswehli]

Depends on where the permissions logic is stored, but to add information such as the example of can user a access the data of company x, then the IAM provider has to make a call back to the service where this information is stored. Its unlikely you'd want to store logic like that within the IAM provider, nor is it necessarily possible. But if you are relying on the IAM provider for user permissions, then you still have the bottleneck of a centralised permission service, its just now your IAM provider. The only scenario i can think of where its more efficent, is in role based authentication.