I really need to write more extensively about this, but I've dealt extensively with authorization as a topic.
The concepts are simple but the implementation can be very difficult.
Authorization and Business Logic are two entirely separate domains. You have to start there. They are orthogonal.
From that follows that requirements involving who you are get implemented in the authorization logic/service/etc, and other requirements get divided up into the appropriate domain logic/services/etc.
If there are requirements around access to emojis then that involves the authorization service.
Sometimes data needs to get duplicated across service boundaries and that's when you need application concepts like sagas to manage this. That's where the implementation starts to get difficult.
I’ve always wondered how authorization should be handled “properly”, as in, what is the end game that is capable of handling the problem at a scale seen at places like AWS? Are the validations and checks still integrated into a (middleware layer of the) service implementing the business logic? If so, how is all this governed, such that correct implementation of all authorization logic can easily be audited?
I would absolutely love to learn more about this, I feel like I’m unable to conceive an appropriate solution to these requirements.
The concepts are simple but the implementation can be very difficult.
Authorization and Business Logic are two entirely separate domains. You have to start there. They are orthogonal.
From that follows that requirements involving who you are get implemented in the authorization logic/service/etc, and other requirements get divided up into the appropriate domain logic/services/etc.
If there are requirements around access to emojis then that involves the authorization service.
Sometimes data needs to get duplicated across service boundaries and that's when you need application concepts like sagas to manage this. That's where the implementation starts to get difficult.