you need a event dispatcher or a proxy service that triggers the application

so you can have the authentication service triggered before every route is executed.

I've built a authentication service that takes the $app and does the oauth check. (it's a phalcon micro framework example)

public function auth(Micro $app) : bool
{
    $sessionSet = $this->sessionSet($app->request);

    if (!$sessionSet) {
        $app->response->redirect('/permission-denied');
        return false;
    }
    return true;

}

But I would go for the classic event dispatcher approach if possible

Edit:

class RequestProxy {

    /**
     * @var \Slimm\App
     */
    private $slimApp;

    public function __construct(\Slim\App $app) {
        $this->slimApp = $slimApp;
    }

    /**
     * method overloading 
                 * proxies all method calls through here if they don't exist in the class
     */
    public function __call($method, $parameters) {
        // add other code before execution here
        $this->slimApp->{$method}($parameters);
    }
}

this would be the easiest solution the flowchart contains a service locator which can be used for component injection and the config these are just generics.

this small proxy allows you to execute things before accessing the main route without having to duplicate code ..... it's using method overloading so basically every non defined method call will be piped to the slim app.

about the authentication

-> i send a token and a user in the HTTP header to check. The usual Man in the Middle attack is handled by having this hash(md5 of body + tokenhash + secret-salt)

so every request gets a unique Token and you need to know all three of them to manipulate the content.

I would use oauth if you don't know crypto sec. I did write my own small solution, but it's compliant with oauth -> just like writing 10 LOC instead of downloading 1MB of code to do the same job.

so the Request-Header contains

• token hash
• username
• api version (some prefer it in the url)

this will be checked as "login" they always have to be sent so the first request is basically getting you the salt. my system is a server to server api that's why i don't bother merging the token and the salt instantly to an extra hash to make it harder to access.

the response-header contains

• if you wanna have bidirectional security (same security hashing)
• possible new endpoints for methods if you wanna keep your client stateless

that's at least what I do.