Иной
Принцип работы OAuth 2.0
Для начала рассмотрим основополагающий принцип протокола:
"Никогда не требовать Ваших пользователей производить авторизацию на сторонних сайтах и давать им доступ к API с помощью пароля."
Чтобы понять этот принцип, рассмотрим его на примере.
Допустим, у Вас есть сайт, на котором зарегистрировался пользователь. А есть сторонний сервис, который предлагает заманчивые возможности на Вашем сайте этому пользователю и для этого требует ввести его логин и пароль от Вашего сайта.
В лучшем случае, если такой сервис честный и действительно дает эти возможности. Но этот сервис могут взломать и получить все логины и пароли пользователей от Вашего сайта. Но есть и другой вариант: фишинговый сайт, который просто собирает эти логины и пароли доверчивых пользователей.
И для того, чтобы всего этого избежать, и был создан протокол OAuth 2.0.

Давайте разберемся с основными терминами и определениями протокола:
Всё происходит в 3 шага:

А теперь рассмотрим авторизацию на типичном примере
  1. Пользователь переходит по ссылке клиента, направляя его на сервер в точку Авторизация (Authorize) с необходимыми ему параметрами:
    https://server.tld/oauth/authorize.php?
    response_type=code&
    client_id=app_id&
    redirect_uri=http://localhost/clientoauth/receivecode.php&
    state=xyz&
    scope=profile+email
    Разберем параметры:
    • response_type - (обяз.) способ авторизации (code - авторизация с помощью авторизационного кода сервера, token - авторизация с помощью авторизационного кода клиента или code+token - оба);
    • client_id - (обяз.) идентификатор/имя клиента/приложения;
    • redirect_uri - (обяз.) URI для редиректа на файл клиента для получения параметра code;
    • state - (обяз.) свободный возвращаемый параметр, который может использоваться клиентом для защиты от CSRF и для удобства;
    • scope - запрашиваемые разрешения (разделённых пробелом или запятой). В случае, если он пустой, то выдаются права, выдаваемые сервером по умолчанию.
  2. Пользователь дает подтверждение на авторизацию клиента на стороне сервера;
  3. Сервер производит редирект на указанный ранее в параметре redirect_uri файл c параметрами code и state (тот, что был передан в 1-м пункте)
    http://localhost/clientoauth/receivecode.php?
    code=9876543210&
    state=xyz
    В случае возникновения ошибки браузер пользователя будет перенаправлен с кодом и описанием ошибки:
    http://localhost/clientoauth/receivecode.php?
    error=invalid_request&
    error_description=Invalid+display+parameter
  4. Клиент проверяет наличие параметра code, впоследствии чего клиент отправляет POST запрос на сервер в точку Токен (Token) с параметрами:
    https://server.tld/oauth/token.php?
    client_id=app_id&
    client_secret=app_secret&
    code=9876543210&
    redirect_uri=http://localhost/clientoauth/receivecode.php&
    grant_type=authorization_code
    • grant_type - тип авторизации (в данном случае всегда используется authorization_code);
    • code - (обяз.) отправляем полученный ранее code;
    • client_id - (обяз.) идентификатор/имя клиента;
    • client_secret - (обяз.) секретный ключ клиента, соответвующий информации на сервере о клиенте;
    • redirect_uri - (обяз.) снова тот же redirect_uri.
  5. Сервер сверяет все данные и отдает access_token в формате JSON:
    {"access_token":"ffeeddccbbaa99887766554433221100"}
    В случае ошибки будут переданы параметры error и error_description
    {"error":"invalid_grant","error_description":"Code is expired."}
  6. Далее после успешной авторизации можно работать с ресурсами, в т.ч. осуществлять запросы к API, отправляя в запросе обратно access_token.
    https://server.tld/oauth/api.php?
    access_token=ffeeddccbbaa99887766554433221100&
    format=json&
    fields=id,email
    • access_token - (обяз.) токен доступа, соответвующий информации на сервере о пользователе;
    • format - формат данных XML или JSON (по умолчанию)
    • fields - список дополнительных полей профилей, которые необходимо вернуть (через запятую) В случае, если он пустой, то выдаются поля, выдаваемые сервером по умолчанию.
  7. Сервер сверяет access_token и отдает данные:
    {"id":"1","email":"e-m@il.ru","name":"Вася Пупкин"}
В случае ошибок, в зависимости от их типа, они отображаются либо на стороне сервера в JSON формате, либо передаются по redirect_uri с GET параметрами error и error_description, содержащими название и описание ошибки соответственно.

Основные рабочие файлы сервера:
Галактика
Галактика
Социальная сеть - приложение