In my previous blog post I've explained the basics of authentication, authorization and how this is dealt with in
Symfony. Due to the size of the post, I've left out several important topics such as roles and voters; Both an equally
important part of authentication and authorization. A common misconception is that roles should be used to check
permissions. In fact, they should definitely not be used to check permissions directly!
One of the more complex parts of Symfony is probably the Security and everything that comes with it. It's not only
rather big, it's also quite flexible with lots of different concepts which often confuse developers. Often enough when
developers implement a security system for their website, they call it Authentication or Authorization yet often don't
exactly know what they are exactly supposed to call it.
One quote I always refer to is "if you can't explain it simply you don't understand it well enough" and I think it's
rather fitting for most cases. I think I've reached a point where I can explain it well enough, so bare with me!
A lot of developers come to
#symfony and ask how to implement a login or authentication system. It's quite common to
have a bunch of features which require authentication and authorization. While authentication is identifying your user,
authorization is granting permissions to this user.
One of the steps of implementing the security features of your application, involves creating an object to contain
your user information such as your username, email, password and user id. If you have followed the Symfony docs,
you will most likely have ended up with a
User entity implementing the
Symfony\Component\Security\Core\User\UserInterface. I would like to show you an alternative- decoupled- approach
which will prevent several issues within a Symfony application.