Обеспечение защиты 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