WebDev

Работает у меня такая схема и в Ionic и в NativeScript.
В общем схема везде одинаковая.
Ionic:
На Laravel нужен Socialite, на клиенте что-то в соответствии с фреймворком. Я использовал ng2-ui-auth. Еще вам нужно установить плагин InAppBrowser.
Последовательность такая:
1. В своем приложении вы жмете на кнопку "Войти через GitHub"
2. Открывается InAppBrowser окно входа GitHub (в урле передается clientId вашего приложения и redirectUri, за это отвечает ng2-ui-auth).
2а. Обратите внимание что redirectUri из запроса должен быть идентичен Authorization callback URL в настройках вашего приложения на сайте GitHub (Settings / Developer settings / OAuth Apps) и в случае Cordova должен быть равен "localhost:3000".
3. GitHub авторизирует вас по логину/паролю, спросит разрешения передавать данные Приложению и редиректит страницу на redirectUri добавляя к нему токен.
4. ng2-ui-auth перехватывает обращение к localhost:3000 (это делается с помощью JS, тут нет никакого локального сервера), достает токен и пересылает его на конечный url (указывается для каждого провайдера в настройках ng2-ui-auth).
4а. Вот этот конечный url должен быть адресом вашего backend'а, а именно метода, который с помощью Socialite будет запрашивать данные пользователя у GitHub.
5. С помощь Socialite вы получаете данные о пользователе у GitHub. Создаете пользователя в Laravel, если его нет, и делаете любые другие необходимы действия.
6. Используя данные пользователя с помощью jwt-auth создаете jwt-токен и возвращаете его клиенту (в пункт 4).
7. На клиенте запоминаете jwt-токен и тот факт, что пользователь аутентифицирован. Из ответа можете достать email (если вы его передали) и где-нибудь отобразить.
Все!

С NativeScript все абсолютно аналогично (там на клиенте я использую nativescript-oauth2) за исключением одного: в NS нет webview, поэтому перехват redirectUri выглядит по-другому:
1. В Authorization callback URL на GitHub вы пишите что-то вроде blablabla://auth (вместо blablabla какая-то длинная уникальная строка - urlScheme).
2. Эта urlScheme также пописывается в настройках nativescript-oauth2 и в App_Resources/Android/src/main/AndroidManifest.xml в виде intent-filter

<intent-filter>
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
    <data android:scheme="blablabla" />
</intent-filter>

Приложение перехватывает обращение к этой уникальной urlScheme и дальше все продолжается согласно списка.

2. Передавать какой-то секретный ключ с сервера АПИ и проверять его на сервере статистики. Этот вариант мне кажется наиболее удобным, но в каком виде его хранить и как передавать?

Видится мне, что это самый разумный вариант. Список адресов - не слишком надёжен и не особо логичен.

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

Use client certificate authentication, Luke! Только колхозить подписание запросов не нужно, как рекомендует камрад Кирилл Горелов, достаточно просто TLS наладить. Заодно получите шифрованный канал данных. Если нативно сервер этого не умеет, можно на фронт поставить nginx (у вас же там наверняка какой-нибудь REST или что-нибудь такое, да?), который прекрасно умеет в аутентификацию по клиентским сертификатам.

Видимо как-то так?

'channels' => [
    'slack-critical' => [
        'driver' => 'slack',
        'url' => env('LOG_SLACK_CRITICAL_WEBHOOK_URL'),
        'username' => 'Laravel critical',
        'emoji' => ':boom:',
        'level' => 'critical',
    ],
    'slack-debug' => [
        'driver' => 'slack',
        'url' => env('LOG_SLACK_DEBUG_WEBHOOK_URL'),
        'username' => 'Laravel debug',
        'level' => 'debug',
    ],
],

Центральный показатель для бизнеса, а следовательно и руководителей, как людей представляющих интересы этого самого бизнеса - это коэффициент возврата инвестиций (ROI). Соответственно, сотрудник должен приносить компании больше денег, чем потребляет. Естественно, что чем выше разрыв между затратами и прибылью, тем лучше, поэтому фонд оплаты труда руководитель должен держать на том минимальном уровне, который гарантирует бесперебойную работу сотрудников. Один из факторов этой бесперебойности - низкая текучка. Сотрудников терять нежелательно. И чем ценнее для компании сотрудник, чем более он профессионален и/или чем больше на него завязано, тем дороже обходится его потеря. Натурально в деньгах. Придётся затратить больше, чем обычно, денег на поддержание работы без него. Придётся затратить деньги и время (те же деньги) на поиск, найм, введение в работу, возможно, обучение нового сотрудника. При этом он может оказаться совсем неподходящих и цикл придётся повторить. Или может оказаться просто хуже прошлого и эффективность отдела снизится. Поэтому, когда сотрудник приходит просить прибавку, руководитель оценивает может ли этот сотрудник уйти или только блефует, насколько легко его будет заменить, какой урон компании будет нанесён его уходом. Потом руководитель оценивает стоимость расширения ФОТ - есть ли резервы, какой сейчас ROI, будет ли больший ROI от реинвестиции этих средств во что-то другое? Если уход сотрудника будет стоить меньше, чем увеличение ФОТа, сотруднику откажут.

Естественно, всё описанное справедливо для случая, когда руководитель - профессиональный менеджер. А то часто на месте руководителя сидит человек руководствующийся эмоциями и мутными соображениями вычитанными в сомнительной бизнес-литературе.

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

try {
    User::create(['email' => $email]);
} catch (\Exception $e) {
    if ($e->getCode() == 23000 && $e instanceof QueryException) {
        //Тут я обрабатываю создание дубликата
    } else {
        throw $e;
    }
}

Расширение - это дополнительные модули в PHP, они реализуют конкретно в вашем случае работу с CURL и JSON.
Узнать подключенные модули
https://www.php.net/manual/ru/function.extension-l...
Список всех модулей
https://www.php.net/manual/ru/extensions.alphabeti...

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

Если бесит инспектор, то можете отключить это уведомление.

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

Я бы не использовал deleted_at как флаг, что сущность удалена - это больше справочная информация.
Завёл бы поле is_delete

Это возможно используя Business Manager + https://developers.facebook.com/docs/facebook-logi...

По умолчанию axios действительно отправляет application/json, а не application/x-www-form-urlencoded
Можете проверить, что именно отправляется в девтулс, например.

Возможно Laravel автоматичски разворачивает это все в "обычные" поля.
UPD: Похоже, что так и есть (тыц).
В "сыром" виде json был (в версии 4.2, например) доступен через Request::json->all(), затем это убрали из документации.

Возможно в будущем (или уже?) уберут и из кода. Проверять лень.

Второй вариант достаточно безопасен при правильной реализации, однако там есть много подводных камней. Достаточно подробно они и возможные атаки на клиентский OAuth разобраны в этой статье.

Хэш используется для предотвращения утечек токена наружу, например через Referer страницы.

нам на сайт с токеном в хэшэ

Любой прокси на пути от вас до сайта видит ваш запрос. Администратор этого прокси может запросто выдернуть ваш хеш, аннулировать ваш запрос и повторить от своего имени. Тогда он авторизуется под вашей учётной записью.

И еще интересно, почему он передается именно в хэшэ? Почему не гет параметром, например?

Скорее всего традиционно сложилось просто.

>>Зачем вообще существует второй вариант? Ведь любой узел (сисадмин, владелец точки wi-fi, провайдер, товарищ майор) может просто взять готовый токен и использовать его.

Данные передаётся по HTTPS! Следовательно токен не доступен промежуточным узлам, так как информация зашифрована.
Если рассматривать авторизацию через ВКонтакте токен известен толкьо: 1) ВКонтакте, 2) Сайту на который производится авторизация, 3) самому пользователю осуществляющему авторизацию
Все промежуточные провайдеры знают только что клиент по факту соединяется с некоторым IP адресом при использовании HTTPS протокола, и они не знают на какой url осуществляется запрос.