Да нет ни каких движух в этом направлении, все по старому, по логическому верному пути — все зависит от поставленных задач!
Куки для обычных сайтов.
OAuth для авторизации через соц сети, и то, после перенаправления на ваш портал и обработки что чел авторизуется через сторонний сервис вы ему те же печеньки присваиваете. Писать для своего портала OAuth провайдер — а оно вам надо? В топ плане будете ли вы предоставлять api для работы с данными пользователя?
OpenID вроде уже ни кто не юзает, но он для авторизации через сторонний/ваш сайт без предоставления дополнительного API
По поводу bearer — это для RESTful API сайтов. Когда пишется один backend для веба и мобильных приложений. Тогда веб как и мобила подписывает любые запросы "bearer {token}". Ну и да, не стоит путать "{token}" и md5(user+pass). Сначала вы делаете авторизацию пользователя по login+pass, затем выдаете ему уникальный token (по сути тот же session_id, но не храните статус пользователя). А как вы его уже генерируете на сервере, дело 3-е. Но да, не стоит md5(login + pass) делать =)
Средний