По смыслу/назначению вопрос:

Вот есть, предположим, HH, у него там разные методы входа: mail.ru, G+, VK...
Смысл OAuth здесь ведь в том, чтобы как-нибудь авторизоваться через сторонний сервис? По сути здесь HH вообще всё взаимодействие со сторонним сервисом типа mail.ru ограничивает тем, что переобновляет токен.
НО, если я правильно понимаю, это не совсем то, ради чего был вообще придуман OAuth. Он был придуман для того, чтобы, например, HH мог извлечь из учётки на mail.ru что-то полезное: какой-нибудь список писем или просто хотя бы адрес электронной почты пользователя.

Т.е. идеологически OAuth - это прежде всего авторизация через внешние сервисы или что-то ещё?

Нет... OAuth - это только про защищенную авторизацию и возможность запрашивать что-либо через токен

Это типа чтобы ты мог у себя использовать другово провайдера аутентификации

И в большинстве случаев оно используется во всяких социалах, да.

Типа залогиньтесь у нас через Втентаклик

ммм... Вообще я это и сказал... Почему-то чуть позже именно это сообщение прилетело.

Там же приложение client_id какие-то полномочия даются

Полномочия (scopes) это для того чтобы попросить у провайдера доп инфу. Он запросит уже пользователя - хочет-ли он предоставлять эту инфу

А тут о каких полномочиях может идти речь, если вся цель - проверить, что у пользователя в принципе есть пароль?
Плюс тот же HH где-то узнаёт email и наверное ещё имя юзера, когда он входит через Vk какое-то

Ну вот один из скоупов - это email

А так в базовом варианте - да, не хранить у себя логины и пароли.

Под это еще подтягивают региональные законы (типа хранить инфу о пользователе только на серверах этой страны), ГДПР и прочее порно законотворщиков.

Ясно... Спасибо! А есть какие-то варианты Сервис-провайдеров на Perl для примера? А то тут как раз странная ситуация, когда нужно сервис-провайдера написать

Поискал пакеты - нет ничего такого. Может, плохо искал конечно. Есть примитивный вариант в Net::OAuth, но там это не реализация провайдера, а просто объекты, возвращающие URL'ы

Токен изначально передается не клиенту, а приложению или серверу.

Есть 2 вида аутентификации:
Серверная
Из приложения

В первом случае обычно используется, чтобы "войти с помощью vk, fb, github, etc", но иногда может включать и более широкий круг действий на сервере, к примеру забрать всех твоих друзей в зависимости от разрешений, которые запросит приложение/сервер.

У обоих вариантов процедура получения токена примерно такая:
Тебя в браузере редиректят на страницу аутентификации, где ты логиниться в систему, далее тебя редиректят обратно на сервер/приложение с access token-ом.
Т.е. токен получает именно приложение или сервер.

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

Все запросы делаются с указанием этого токена.

Я последний раз писал года 3 назад, поэтому плохо помню.

Но всякий раз когда писал, писал все с нуля.

Есть два типа OAuth.
OAuth v1
OAuth v2

Вот самая простая - это v2, потому что она по защищенному каналу работает (https).

Первой версии OAuth посложнее, там мороки больше с подписывагием запроса, нужно прямо внимательно читать доку, в каком порядке что положить для того, чтобы hmac сделать. У твиттера вроде такая.

OAuth v1 — когда я несколько лет назад смотрел, был только у твиттера, все перешли на в2 очень давно и охотно

но в2 при этом каждый понимает по своему, казлы

я писал авторизацию в2 для сервера под разных социалок