Обеспечение защиты REST API от платформы Play и OAuth2
Я разрабатываю приложение с Play 2.0 и Scala, которое предоставляет некоторый REST API. Эти API-интерфейсы будут использоваться различными приложениями, сетями, мобильными или настольными компьютерами, поэтому протокол OAuth (OAuth2) представляется наиболее подходящим.
Также я бы сначала использовал внешний поставщик OAuth, такой как Facebook.
Мой вопрос: каков точный поток для авторизации индивидуального вызова REST? Что я должен ожидать на стороне сервера для каждого вызова и что я должен проверить с внешним провайдером?
С OAuth1 я знал, что клиент отправил токен со всем подписанным запросом, но с Oauth2 я думаю, что это не так, я думаю, что если токен не подписан, ему не доверяют, и поэтому я не думаю, что это поток.
Ответы
Ответ 1
Вы можете использовать модуль SecureSocial.
https://github.com/jaliss/securesocial/
Этот вариант довольно утончен, и многие люди в сообществе Play, похоже, знают/используют этот модуль.
Для авторизации может быть полезно.
https://github.com/schaloner/deadbolt-2/
В конце концов scala материал,
https://github.com/t2v/play20-auth
Ответ 2
Я поместил Apache Amber в Play2 Scala, вот ссылка:
https://github.com/cleanyong/oauth2play2scala
Причиной переноса Apache Amber является:
- он был протестирован
- лучше, чем дома.
- он подходит для Play2 Scala API
- простой в использовании
- не навязчивый
Если вы хотите настроить сервер oauth2 на своем сайте, вы можете попробовать использовать мой порт. У него есть документ.
Ответ 3
В принципе, стандартный поток следующий:
- по каждому запросу, проверьте файл cookie ( "сеанс" на диалекте Play!), если он содержит идентификатор
- если нет, попросите пользователя пройти аутентификацию у поставщика (Facebook или что-то еще)
- Если все в порядке, поставщик вернет идентификатор, сохранит этот идентификатор в вашей системе сохранения (регистрации) и в текущем файле cookie/session
- в следующих запросах проверьте, существует ли идентификатор в cookie/сеансе и соответствует существующему пользователю в вашей системе сохранения.
- Чтобы "выйти из системы", просто очистите файл cookie/сеанс
Если вы хотите получить более подробную информацию, просто спросите: -)
Ответ 4
OAuth - это протокол авторизации, поэтому, если вы смотрите на решение аутентификации, это может и не быть.
Вы сомневаетесь, что потребитель API будет различным приложением. Это приводит к 2 сценариям,
1. Where there is no end user involved (grant_type: client_credential)
2. Where end-user can consume these APIs on multiple Application (Owned by your Org) (grant_type: implicit/password)
3. Where end-user can consume these APIs via third Party Applications.(authrization_code)
Для поддержки OAuth Eco-System вам нужна система управления ключами.
To,
- Создать ключ/секрет для приложений.
- Создание AccessToken/Refresh_token/authorization_code
теперь приближается к конечной точке, которую вам нужно будет выставить,
3-Legged OAuth
GET /authorize authorize{entry point/ initiate oauth}
Sample Call: http://YourAPIService.com/authorize?response_type=code&client_id=GG1IbStzH45ajx9cEeILqjFt&scope=READ&redirect_uri=www.google.com
GET /login login (Call Page for login App, 302 redirected from /authorize)
Sample Call: http://YourAPIService.com/v1/oauth20/login?response_type=code&client_id=GG1IbStzH45ajx9cEeILqjFt&scope=READ&redirect_uri=www.google.com
POST /dologin consentPage http://YourAPIService.com/dologin
Submit the credential, On success, render the application page
POST /grantpermission consentSubmission http://YourAPIService.com/grantpermission
Permission has been granted/declined. Send a 302 to generate authorization_code
GET /code AuthorizationCode {To generate auth code}
Sample Call: http://YourAPIService.com/code?client_id=GG1IbStzH45ajx9cEeILqjFt&response_type=code&[email protected]&redirect_uri=www.google.com
POST /token GenerateAccessToken http://YourAPIService.com/token
Sample call: http://kohls-test.mars.apigee.net/v1/oauth20/token
Header: Authorization: Basic R0cxSWJTdHpINDVhang5Y0VlSUxxalFj its generated with apps Api Key & Secret.
Payload:
grant_type=authorization_code&scope=x&redirect_uri=www.google.com&code=abc123
В противном случае простейшим/надежным решением было бы,
http://apigee.com
Вы можете использовать существующую экосистему OAuth Apigee.
Ответ 5
Я сам не пробовал, но как насчет модуля tuxdna.
Как и в github repo, он говорит:
Сервер OAuth2, использующий Play! 2.0 Framework
Я надеюсь, что это поможет
Ответ 6
У меня была та же проблема, что я сделал (я полагаю, это не лучшее решение), чтобы разместить методы сервера REST внутри "@Security.Authenticated(Secure.class)" и использовать session cookie (который также был зарегистрирован внутри таблицы Hash в бэкэнд). Файл cookie сеанса был создан после входа пользователя
I post code:
package controllers;
import ...;
@Security.Authenticated(Secured.class)
public class ExampleController extends Controller {
public static String currentUserEmail() {
... return json after checking that 'session("id")' exists in the loggedin users hash table...
}
и
package controllers;
import ...;
public class Secure extends Security.Authenticator {
@Override
public String getUserId(Http.Context context) {
return context.session().get("user_id");
}
...
}
Надеюсь, что это поможет
Ответ 7
Вы можете попробовать использовать этот шаблон для игры, который объединяет поставщика OAuth 2 с Deadbolt.
Область OAuth соответствует концепции разрешения и роли Deadbolt.
Он использует Redis для хранения токенов доступа, и они истекают автоматически после установленного периода времени.
https://github.com/lglossman/scala-oauth2-deadbolt-redis