#oauth
#oauth
Вопрос:
Я разбираюсь в OAuth и всей концепции перенаправления для авторизации.
Имеет смысл, чтобы это делали сторонние приложения, однако как насчет «фактического» веб-сайта или приложения компании?
Например, веб-сайт / приложение Facebook не будут заставлять вас проходить через поток перенаправления для входа в систему, даже если они могут работать с OAuth API под капотом.
С точки зрения OAuth, казалось бы, для этих типов потребителей необходимо делать исключения. А именно, есть несколько избранных приложений, которые, по сути, авторизуются автоматически.
Имеет ли это смысл или я что-то упускаю?
Комментарии:
1. Некоторые части реализации OAuth 2.0 Facebook неверны. По крайней мере, Facebook обрабатывает
redirect_uriпараметр иscopeпараметр иначе, чем в RFC 6749 (OAuth 2.0). Таким образом, реализация Facebook не должна упоминаться в общем обсуждении OAuth 2.0.2. Вчера я просмотрел два приложения для photobucket. В значительной степени отражает точный опыт, о котором я спрашиваю здесь… Само приложение photobucket не перенаправляет вас на авторизацию чего-либо. Имя пользователя и пароль запускаются прямо через приложение при входе в систему. Но если вы посмотрите на PhotoFolio, стороннего пользователя PB, вы будете перенаправлены на аутентификацию / авторизацию.
Ответ №1:
Я не уверен, что правильно понял ваш вопрос, но, по сути, основная цель OAuth 2.0 — разрешить сторонним приложениям получать доступ к защищенным ресурсам владельцев ресурсов (= конечных пользователей) без передачи учетных данных владельцев ресурсов (ID и пароль) сторонним приложениям.
С точки зрения сервера Facebook официальный веб-сайт и приложение Facebook не являются сторонними приложениями. То есть все объекты (сервер, приложения и пользователи) принадлежат Facebook. Поэтому сервер Facebook и официальные приложения Facebook не должны использовать OAuth 2.0. Они могут общаться своим особым, пользовательским и загадочным способом, как им нравится.
Аналогично, с точки зрения сервера Photobucket, официальное приложение Photobucket не является сторонним приложением. Таким образом, приложению разрешено принимать учетные данные конечных пользователей непосредственно через компоненты пользовательского интерфейса приложения. С другой стороны, с точки зрения PhotoFolio, приложение Photobucket является сторонним приложением. Поскольку PhotoFolio хочет разрешить приложению Photbucket доступ к службе PhotoFolio, но не хочет, чтобы приложение Photobucket собирало учетные данные конечных пользователей PhotoFolio, PhotoFolio требует, чтобы приложение Photobucket использовало OAuth 2.0.
В потоках OAuth 2.0 (за исключением предоставления учетных данных пароля владельца ресурса) сторонние приложения не могут знать учетные данные конечных пользователей. В этом суть. Сторонние приложения, которые имеют право знать учетные данные конечных пользователей, не должны использовать OAuth 2.0.
Комментарии:
1. Я никогда не указывал OAuth 2. Вопрос относится к использованию OAuth в целом. Я хочу сказать, что хотелось бы повторно использовать API, а не создавать совершенно отдельный только для своих собственных приложений, поэтому, вероятно, есть некоторые хаки / настройки, связанные с тем, как использовать существующий oauth api для таких приложений.
2. Извините, но OAuth 1.0 и OAuth 2.0 сильно отличаются. Похоже, вы сможете получить информацию из «Предоставления учетных данных пароля владельца ресурса» OAuth 2.0 (RFC 6749). В потоке перенаправление не выполняется, и клиентское приложение обращается к конечной точке токена напрямую (без доступа к конечной точке авторизации). И конечная точка токена принимает параметры запроса «имя пользователя» и «пароль».
3. Это звучит очень полезно, я посмотрю на это!