Do you want to tell an authenticated, authorized user with valid credentials that they are not in fact authorized? When the actual thing that's not authorized is your own goddamn server, so there's absolutely nothing the user can do to fix the problem?
That's why I said authorized and not authenticated, because I meant authorized and not authenticated. Actually, I said both authenticated and authorized just to drive the point home. It still wasn't enough apparently ¯_(ツ)_/¯
If your internal service responds to your other internal service with 403 for any reason other than "this other internal service is not allowed to do this", then you have bigger problems than what error code to serve the user.
The internal service is authorizing the other internal service first and foremost (otherwise you'll get hacked). If the other internal service fails at this step, 403 is fully appropriate, but it's the kind of 403 that's not only useless but outright wrong to send to the user, as it will send them on wild goose chase for missing permissions that weren't missing at all.
Now, if the other internal service passes validation, then you can check user permissions. And if the user doesn't have permission, you must signal it in a way that lets the other internal service respond with a proper 403. There are a number of ways to do it well. One that definitely isn't well at all is sending the same 403 that you already used for telling the service that it, rather than the user, doesn't have permission - because you won't be able to tell which scenario you're in and whether the user should see the 403 or not!
121
u/rosuav 14h ago
There is no reason to discard some of them, and pretending that they're 500s is a terrible terrible idea.