Quick thoughs about user management:
As pointed by Stof, the OAuth provider might not have a way to retrieve a user's username. In that case, what should we do? We can consider the authentification process is over as soon as we have the access token, thus returning an authenticated token based on it and set the username either to the access token or to some predefined constant (the
NONE_PROVIDED as a temporary value for example).
Either way, we need an easy way for the developpers to hook into the authentication process and be able to fetch the user's data, possibly updating the security token. I'm not sure yet what's the best way to achieve that, but I feel the
UserProvider is the key here again.
So right now, the bundled
UserProvider just creates instances of
Knp\OAuthBundle\Security\Core\User\OAuthUser, but this is sufficient only if you don't plan on using ACLs or do advanced stuff with your users.
So the question is: what's the best way to support local user persistance? The problem is that if you use a
UserProvider that — for example — fetches user from the database, when a non-existent user logs in, the
UserProvider won't find it in the database, and thus will consider the authentification attempt a failure.
I have 3 leads to fix that right now:
SecurityEvent::INTERACTIVE_LOGINevent to hook up on the auth process and create the users on the fly and reinject the correct user into the security token
SuccessHandlerto achieve the exact same result
Actually, I think only the 3rd option is viable, since the event and the success handler happen too late in the process, but I'm not 100% sure yet. I also don't like the fact that a
UserProvider creates users, but I'm not sure we have a better solution here.
Last edited by geoffrey,