Ильяс Галиев

Шаг 1, изучаем https://jwt.io/ - на настоящий момент стандарт для аутентификации.
Шаг 2. Каждое устройство должно иметь уникальный токен. Пользователь должен иметь возможность деавторизовать любое устройство. При смене пароля все токены автоматически стираются.

Организация хранения токена должна выглядеть примерно так:

tokens
- user_id
- device_id  - при авторизации через браузер можно подставить md5(User-Agent)
- device_name  - человеко-понятное имя девайса или название браузера
- token
- last_used
- expires_at

Про API, вместо передачи дополнительного параметра в запросе очень часто используют HTTP-заголовки.
Наличие множества токенов практически ничем не грозит, разве что небольшим увеличением размера данных.
Сброс токенов нужен по времени, по смене пароля, значительной смене географии (другая страна и т.п.), при нажатии кнопки Выход и по желанию пользователя (опции Выйти со всех устройств).

Есть два варианта хранения данных об авторизованном пользователе:
1) В куки (так по умолчанию используется в асп.нет): необходимые данные (claims) шифруются machineKey и отдаются пользователю в http-only куках, таким образом при каждом запросе на сервер они присылаются, расшифровываются и далее можно проверить в необходимых местах.
плюсы: полностью stateless, нет надобности обращаться к БД
минусы: при необходимости "выбить" сессию со стороны сервера нужно поднимать более сложную логику и хранить флаги в промежуточном хранилище (проверять что если для такого-то пользователя требуется завершить, то такие действия, иначе другие);
2) Ключ сессии: после успешной аутентификации авторизуем пользователя и claims храним на сервере в быстрой памяти или БД (key-value), где ключ - ключ сессии, значение - любые данные.
плюсы: есть полный контроль состоянием авторизации (как и возможность завершить сессию со стороны сервера, так и сменить пользователю роль(или другие параметры) "на лету")
минусы: организация доп. прослойки - кэша или хранение в БД (медленно), при перезапуске/падении сервиса сессии клиентам потребуется перелогиниться.

1
1.1 В куки писать или ключ сессии или шифрованные данные о пользователе, сессия - абстрактное понятие (это пара: ключ и данные), ключ должен быть защищенным, т.е. трудным к копированию (хотя бы зрительно трудно запомнить), уникальным (чтобы не возникло коллизий: двум разным пользователям выдался один и тот же ключ, т.е. это не должна быть хэш-функция от логина-пароля или IP или чего-то неуникального).
1.2 В асп.нет существуют атрибуты авторизации (в которых можно расставлять проверки на требование таковой, роль, конкретный пользователь), в общем смысле логика такова: поступил запрос на сервер, далее нужно посмотреть к какому ресурсу идёт обращение (защищенному или свободному), если ресурс защищен, то проверить куки (ключ сессии или шифрованные данные), расшифровать/получить данные о сессии из кэша и предпринять решение: пускаем или не пускаем (отдаём 401/403 или отдаем 200/404/...).
1.3 Завести на сервере (в кэше или БД) словарь , при алгоритме проверки сессии добавить условие проверки на наличие записи в словаре.
1.4 С нескольких - словаря не нужно.

2
2.1 Даже если пользователь входит через ВК всё равно нужно отдавать свои ключи сессий/шифрованные данные, а вот внутри данных уже хранить access_token от вк-шной сессии, так очень маленькая вероятность, что токен ВК утечет, а если утек ключ сессии, то действия будут ограничены только функционалом сайта.
2.2 После расшифровки куки или данных по ключу сессии делать доп запрос на сервер ВК с токеном, который сохранился при аутентификации (access_token), запрос простой, например получить имя пользователя, если ВК выдал что токен просрочен или ошибку, то сессию закрывать или куки с данными обнулять.

нет

Это так же невозможно, как для тебя невозможно перестать маяться дурью и изобретать идиотские способы решения примитивных задач.

подсказка: такая идея с заменой не приходила в голову ни одному из сотен тысяч разработчиков.
это значит, что ты опять зафантазировался, и придумал какую-то бредятину, для реализации которой понадобилось заменять теги у пхп.
Спустись с небес на землю и делай по-человечески.

Вероятно, вам нужен тип varchar или какой-то другой строковый. Потому что с точки зрения целых чисел 06661313 и 6661313 - одно и то же.

Не хочу чтобы скрипт обращался к базу данных

Это еще что за капризы?

правильно будет так:
$result = mysql_query("SELECT * FROM post WHERE id=1",$db);
if ($result)
while ($row = mysql_fetch_assoc($result))
echo $row['counter'];

Пробуйте оба и выбирайте самостоятельно. Я могу аргументированно уговорить выбрать любой из этих двух фреймворков, но вы так и будете мучаться «а не ошибся ли я» пока не попробуете оба.