scala - Asegurando la API REST en el marco de Play y OAuth2

playframework oauth-2.0

Question

Estoy desarrollando una aplicación con Play 2.0 y Scala que expone algunas API REST. Estas API serán utilizadas por diferentes aplicaciones, web, móvil o de escritorio, por lo que el protocolo OAuth (OAuth2) parece el más adecuado.

También usaría inicialmente un proveedor externo de OAuth como Facebook.

Mi pregunta es: ¿cuál es el flujo exacto para autorizar la llamada REST individual? ¿Qué debo esperar del servidor para cada llamada y qué debo consultar con el proveedor externo?

Con OAuth1 sabía que el cliente envió el token con toda la solicitud firmada, pero con Oauth2 creo que no, me imagino que si un token no está firmado no es de confianza y, por lo tanto, no creo que este sea el flujo.

Answer 1

Básicamente, el flujo estándar es el siguiente:

1. en cada solicitud, marque la cookie ("sesión" en el dialecto Play!) si contiene una identificación
2. si no, pídale al usuario que se autentique con el proveedor (Facebook o algo más)
3. Si está bien, el proveedor devolverá una identificación, la guardará en su sistema de persistencia (registro) y en la cookie / sesión actual
4. en las siguientes solicitudes, verifique si el ID existe en la cookie / sesión y corresponde a un usuario existente en su sistema de persistencia
5. Para "cerrar sesión", simplemente borre la cookie / sesión

Si quieres más detalles, solo pregunta :-)

Answer 2

OAuth es un protocolo de autorización, por lo que si está buscando una solución de autenticación, esta podría no ser la correcta.

Tu pregunta es que el consumidor de la API tendrá varias aplicaciones. Esto condujo a 2 escenarios,

 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)

Para admitir el OAuth Eco-System necesita un sistema de gestión de claves. A,

1. Generar clave / secreto para aplicaciones.
2. Generando AccessToken / Refresh_token / permission_code

ahora llegando al punto final tendrías que exponer,

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

De lo contrario, la solución más simple / robusta sería, http://apigee.com

Puede utilizar el ecosistema existente de OAuth de Apigee.

Answer 3

Podrías usar un módulo llamado SecureSocial.

https://github.com/jaliss/securesocial/

Este es bastante refinado y muchas personas en la comunidad de Play parecen conocer / usar este módulo.

Para la autorización podría ser útil. https://github.com/schaloner/deadbolt-2/

De extremo a extremo cosas de Scala, https://github.com/t2v/play20-auth

Answer 4

Porté Apache Amber a Play2 Scala, aquí está el enlace: https://github.com/cleanyong/oauth2play2scala

La razón para portar Apache Amber es:

1. ha sido probado
2. mejor que hecho en casa
3. encaja Play2 Scala API
4. fácil de usar
5. no intrusivo

Si desea configurar un servidor oauth2 en su sitio, puede intentar usar mi puerto. Tiene documento.

Answer 5

Puedes intentar usar esta plantilla para jugar que combina el proveedor OAuth 2 con Deadbolt. El alcance de OAuth se asigna al concepto de permisos y roles de Deadbolt. Utiliza Redis para almacenar tokens de acceso, y caducan automáticamente después del período de tiempo que configuró.

https://github.com/lglossman/scala-oauth2-deadbolt-redis

Answer 6

Tuve el mismo problema, lo que hice (supongo que no es la mejor solución) fue colocar los métodos del servidor REST, dentro de un "@ Security.Authenticated (Secure.class)", y usar una cookie de sesión ( que también se registró dentro de una tabla Hash en el backend). La cookie de sesión se generó después del inicio de sesión del usuario

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... 

}

y

package controllers;

import ...;

public class Secure extends Security.Authenticator {

    @Override
    public String getUserId(Http.Context context) {
        return context.session().get("user_id");
    }
...
}

Espero que esto ayude

Answer 7

Yo no lo intenté yo mismo, pero ¿qué hay de tuxdna módulo. Como en el repositorio de github dice:

Servidor OAuth2 utilizando Play! Marco 2.0

espero que esto ayude