Предоставление кода авторизации: предназначено для пользователей, которые хотят получить доступ к МОЕМУ приложению/API через стороннее приложение. Пример. Пользователь через Flicker хочет получить доступ к API-интерфейсу MY для печати фотографий. В этом случае Flicker выполнит все перенаправление и поток OAUTH2 с МОИМИ серверами. Предоставляется токен доступа, и стороннее приложение может использовать MY API по мере необходимости. Разработчику приложения необходимо зарегистрироваться, чтобы получить идентификатор и секрет клиента.
Неявно: То же, что и выше, за исключением мобильного/ у приложения нет внутреннего сервера для хранения секрета клиента. Мобильное приложение будет обрабатывать перенаправление и поток OAUTH2. Предоставляется токен доступа, и стороннее приложение может использовать MY API по мере необходимости. Токен обновления не поддерживается. Разработчику приложения необходимо будет зарегистрироваться, чтобы получить идентификатор клиента.
Предоставление учетных данных пароля владельца ресурса: В данном случае это МОЕ мобильное/веб-приложение, которое я распространяю среди своих пользователей через типичные магазины iTunes/Play. Пользователи используют МОЕ приложение исключительно для повседневных дел. МОЕ мобильное/веб-приложение запросит у пользователя имя пользователя/пароль и отправит их на МОЙ сервер, где оно пройдет аутентификацию, а затем предоставит токен доступа.
Предоставление учетных данных клиента. Этот случай используется приложением для выполнения внутренних межмашинных операций. То есть: МОЕ Приложение1 получило доступ к МОЕМУ Приложению2 где-то в задней части.
На данный момент я не планирую делиться своим API со сторонними организациями, и мои пользователи установят МОЕ приложение через iTunes/Google Play. Полагаю, что Пароль учетных данных мне сейчас подходит. В конце концов, если я захочу открыть свой API для остального мира, мне придется реализовать Предоставление кода авторизации
[list] [*][b]Предоставление кода авторизации:[/b] предназначено для пользователей, которые хотят получить доступ к МОЕМУ приложению/API через стороннее приложение. Пример. Пользователь через Flicker хочет получить доступ к API-интерфейсу MY для печати фотографий. В этом случае Flicker выполнит все перенаправление и поток OAUTH2 с МОИМИ серверами. Предоставляется токен доступа, и стороннее приложение может использовать MY API по мере необходимости. Разработчику приложения необходимо зарегистрироваться, чтобы получить идентификатор и секрет клиента. [*][b]Неявно:[/b] То же, что и выше, за исключением мобильного/ у приложения нет внутреннего сервера для хранения секрета клиента. Мобильное приложение будет обрабатывать перенаправление и поток OAUTH2. Предоставляется токен доступа, и стороннее приложение может использовать MY API по мере необходимости. Токен обновления не поддерживается. Разработчику приложения необходимо будет зарегистрироваться, чтобы получить идентификатор клиента. [*][b]Предоставление учетных данных пароля владельца ресурса:[/b] В данном случае это МОЕ мобильное/веб-приложение, которое я распространяю среди своих пользователей через типичные магазины iTunes/Play. Пользователи используют МОЕ приложение исключительно для повседневных дел. МОЕ мобильное/веб-приложение запросит у пользователя имя пользователя/пароль и отправит их на МОЙ сервер, где оно пройдет аутентификацию, а затем предоставит токен доступа. [*] [b]Предоставление учетных данных клиента[/b]. Этот случай используется приложением для выполнения внутренних межмашинных операций. То есть: МОЕ Приложение1 получило доступ к МОЕМУ Приложению2 где-то в задней части. [/list]
На данный момент я не планирую делиться своим API со сторонними организациями, и мои пользователи установят МОЕ приложение через iTunes/Google Play. Полагаю, что [b]Пароль учетных данных[/b] мне сейчас подходит. В конце концов, если я захочу открыть свой API для остального мира, мне придется реализовать [b]Предоставление кода авторизации[/b]
Как я искал по этой теме я наткнулся на эту ссылку: https://alexbilbie.com/guide-to-oauth-2-grants/, в которой есть хороший порядок принятия решений.
Мобильная версия