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

• Сервер (Server) - место, где хранятся данные пользователя. Под словом данные следует понимать не только идентификационные обозначения пользователя, но и его любые прочие ресурсы (напр. сообщения, аудиозаписи и т.п.). Иными словами, это провайдер ресурсов и авторизации (Resource and Authorization Provider);
• Пользователь (User) - владелец вышеобозначенных ресурсов (Resource Owner);
• Клиент (также известный как Приложение) - сторонний сайт/сервис/приложение (3rd Party).

• Авторизация (Authorize) - пользователь авторизует клиента (сайт/приложение) ;
• Токен (Token) - в ответ сервер дает клиенту токен на доступ к ресурсам пользователя;
• Ресурс (Resource/API) - клиент посылает токен обратно и получает ресурсы пользователя.

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 - список дополнительных полей профилей, которые необходимо вернуть (через запятую) В случае, если он пустой, то выдаются поля, выдаваемые сервером по умолчанию.
Сервер сверяет access_token и отдает данные:
{"id":"1","email":"e-m@il.ru","name":"Вася Пупкин"}

• authorize - первичная авторизация (получение кода)
• token - получение токена на доступ к ресурсам
• api - получение данных по API