Clean architecture and Domain Driven Design - How to handle Permission

Authorization and authentication in clean architecture

Uncle Bob Thoughts

"Security is an application specific concern, it belongs to the interactors.  The controllers would access the current user's credentials and pass that information to the interactors.  The interactors would use an authorization service to ensure that their particular interaction was authorized.  The business objects wouldn't know anything about it"

PS 1: Link with conversation PS 2: Interactors are the Use Case layer of the Clean Architecture

Authorization and authentication in clean architecture

Ways of having authentication data retrieved:

• Normal web channel will probably have the session cookie with user_id in it.
• API web channel will probably have a header with access_token. And we can parse it and detect the author of the request.
• Console input is trickier. Probably we will have to explicitly set the author of the request when running a command: command --author_id=<ID>.
• Queued command (job) will also have some user_id data in it, which will set the caller id.

Most likely you will patch the data of the user authentication in a DTO to pass to the Use Case layer to decide if can continue or not.