Как валидировать/верифицировать токен?

Да, вы абсолютно правы, так и поступаем за неимением ничего другого, но, подскажите, в будущем вы рассматриваете возможность не пользовательских сессий (как мы ранее писали, сервисных или технических), чтобы можно было получить токен программным путем без подтверждения разрешения на приложения, без создания каких-либо пользователей, а просто имея идентификатор и секретный ключ приложения? Это было бы очень круто, по аналоги с другими соц. сетями.

Как валидировать/верифицировать токен?

Ну никто и не заставляет делать автопродлеваемые сессии, которые дляться годами, для клиентов, их можно использовать для апи типа сервер-сервер. Насчет экспирации, то для этого и существуют сервисные запросы типа checkToken, чтобы проверить разрешения приложения и т.д.

Да, прошу прощения, в последнем вопросе имелось ввиду поле application_key из примера вашей доки, https://api.ok.ru/fb.do?application_key=CBAPFHGLEB... Проблема в том, что запрос users.getCurrentUser сессионный, и нашему серверу, чтобы с ним работать, надо пользоваться сессией клиента (например, пользователя приложения), что, согласитесь, не есть хорошо, а получить свою ссесию сервер не может, потому что ваши апи клиентские, и ориентированы на подтверждение пользователем разрешения на приложение (redirect_uri), чего REST-сервис сделать не может.

Как валидировать/верифицировать токен?

В принципе, можно, спасибо, но вообще очень странно, что сервер будет использовать клиентскую сессию, а не свою собственную, и чтобы проверить валидность токена, нам нужно дергать клиентский запрос (который, кстати, по этому токену и работает) с кучей не нужной в данной задаче информации, также не понятно почему у вас нет сервисных (технических) апи, а только клиентские, например, в этой задаче нам не нужны все эти данные (информация о пользователе), которые возвращает запрос users.getCurrentUser, а требуются сугубо технические, например, валиден ли токен/сессия, сколько он действителен, userId пользователя, идентификатор приложения для этого токена/сессии. Также интересен момент, если при формировании application_key подставить application_secret_key из другого приложения, не привязанного к проверяемому access_token, будет ли ошибка?