Я добавлю здесь кое-что, что, как мне кажется, не ясно в приведенных выше ответах:

• авторизация-код-поток позволяет для окончательного access-token чтобы никогда не достичь и никогда не храниться на машине с браузером / app. Временный код авторизации выдается машине с браузером / приложением, которая затем отправляется на сервер. Затем сервер может обменять его на токен полного доступа и получить доступ к API и т. д. Пользователь с помощью браузер получает доступ к API только через сервер с маркером.
• неявный поток может включать только две стороны, и конечный маркер доступа хранится на клиенте в браузере/приложении. если этот браузер / приложение скомпрометировано, так это их auth-токен, который может быть опасным.

tl; dr Не используйте неявный поток, если вы не доверяете машине пользователей для хранения токенов, но вы do доверяйте своим серверам.

разница между ними заключается в том, что:

1. в неявном потоке токен возвращается непосредственно через URL-адрес перенаправления со знаком"#", и это используется в основном в клиентах javascript или мобильных приложениях, которые не имеют собственной серверной стороны, и клиенту не нужно предоставлять свой секрет в некоторых реализациях.

2. в потоке кода авторизации код возвращается с "?"для чтения на стороне сервера то сервер должен обеспечить секрет клиента на этот раз в URL-адрес маркера, чтобы получить маркер как объект json с сервера авторизации. Он используется в случае, если у вас есть сервер приложений, который может обрабатывать этот и хранить токен пользователя с его/ее профилем в своей собственной системе, и в основном используется для обычных мобильных приложений.

таким образом, это зависит от характера вашего клиентского приложения, который еще один безопасный "код авторизации" , поскольку он запрашивает Секрет на клиенте, и токен может быть отправлен между сервером авторизации и клиентское приложение на очень защищенном соединении, и поставщик авторизации может ограничить некоторых клиентов использовать только "код авторизации" и запретить неявное

неявное предоставление похоже на предоставление кода авторизации с двумя различными различиями.

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

во-вторых, вместо того, чтобы сервер авторизации возвращает код авторизации, который обменивается на маркер доступа, сервер авторизации возвращает доступ знак.

подробности здесь http://oauth2.thephpleague.com/authorization-server/which-grant/

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

Поток Кода Авторизации!!!

• если у вас есть сервер веб-приложений, который действует как клиент OAuth
• если вы хотите иметь длительный доступ
• если вы хотите иметь автономный доступ к данным
• когда вы несете ответственность за вызовы api, которые делает ваше приложение
• если вы не хотите, чтобы утечка вашего OAuth токен
• если вы не хотите, чтобы ваше приложение, чтобы запустить через поток авторизации каждый раз, когда ему нужен доступ к данным. Примечание: неявный поток предоставления не поддерживает токен обновления, поэтому, если срок действия токенов доступа сервера авторизации истекает регулярно, ваше приложение должно будет проходить через поток авторизации всякий раз, когда ему нужен доступ.

Неявный Поток Грантов!!!

• если у вас нет сервера веб-приложений для работы в качестве OAuth Клиент
• Если вам не нужен длительный доступ, то есть требуется только временный доступ к данным.
• если Вы доверяете браузеру, в котором работает ваше приложение, и существует ограниченное беспокойство о том, что маркер доступа будет просачиваться ненадежным пользователям.

неявный поток

преимущества

• проще всего реализовать

недостатки

• маркеры доступа, видимые в браузере
• происхождение токенов доступа не может быть определено
• срок действия токенов доступа не может истечь (по политике Google)

---

поток кода авторизации

преимущества

• самый безопасный
• маркеры доступа и обновления могут создаваться только в том случае, если известен общий секрет
• может быть улучшена с новыми функциями безопасности и UX, когда они становятся доступными

недостатки

• необходимо реализовать несколько конечных точек auth

цитата: https://developers.google.com/actions/develop/identity/oauth2-overview#supported_oauth_20_flows

с практической точки зрения (что я понял), основной причиной наличия потока кода Authz является:

1. поддержка токенов обновления (долгосрочный доступ приложений от имени пользователя), не поддерживается в неявном: см.:https://tools.ietf.org/html/rfc6749#section-4.2
2. поддержка страницы согласия, которая является местом, где владелец ресурса может контролировать, какой доступ предоставить (вид разрешений/страницы авторизации, которые вы видите в google). Же не там в скрытом виде . Смотрите раздел:https://tools.ietf.org/html/rfc6749#section-4.1, точка (B)

"сервер авторизации аутентифицирует владельца ресурса (через user-agent) и устанавливает, предоставляет ли владелец ресурса или отклоняет запрос клиента на доступ"

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

какой из них более безопасный и почему?

оба они безопасны, это зависит от среды, в которой вы его используете.

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

это просто. Ваш клиент не защищен. Давайте разберемся в деталях.

считайте, что вы разрабатываете применение в отношении Instagram API, Так что вы регистрируете свое приложение с Instagram и определения API's вам нужна. Instagram предоставит вам client_id и client_secrect

на вашем веб-сайте вы создали ссылку, которая говорит. "Приходите и используйте мое приложение". Нажав на это ваше веб-приложение должно сделать два звонки Instagram API.

First отправить запрос Instagram Authentication Server С ниже параметры.

1. `response_type` with the value `code`
2. `client_id` you have get from `Instagram`
3. `redirect_uri` this is a url on your server which do the second call
4. `scope` a space delimited list of scopes
5. `state` with a CSRF token. 

вы не посылаете client_secret, Вы не можете доверять клиенту (пользователю и / или его браузеру, которые пытаются использовать ваше приложение). Клиент может увидеть url или Java-скрипт и найти ваш client_secrect легко. Вот почему вам нужен еще один шаг.

вы получаете code и state. Элемент code здесь temporary и не сохраняется нигде.

то second вызов Instagram API (С вашего сервера)

 1. `grant_type` with the value of `authorization_code`
 2. `client_id` with the client identifier
 3. `client_secret` with the client secret
 4. `redirect_uri` with the same redirect URI the user was redirect back to
 5. `code` which we have already received.

поскольку вызов производится с нашего сервера, мы можем безопасно использовать client_secret ( что показывает, как мы находимся) с code который показывает, что пользователь выдал client_id для использования ресурса.

в ответ мы будем иметь access_token