web-dev-qa-db-fra.com

Sécuriser REST Cadre API sur Play et OAuth2

Je développe une application avec Play 2.0 et Scala qui expose des API REST. Ces API seront utilisées par différentes applications, Web, mobiles ou ordinateurs de bureau. Le protocole OAuth (OAuth2) semble donc le plus approprié.

De plus, j'utiliserais initialement un fournisseur OAuth externe tel que Facebook.

Ma question est la suivante: quel est le flux exact pour autoriser l'appel individuel REST? À quoi dois-je m'attendre côté serveur pour chaque appel et que dois-je vérifier auprès du fournisseur externe? 

Avec OAuth1, je savais que le client avait envoyé le jeton avec toutes les demandes signées, mais avec Oauth2, je pense que non, j'imagine que si un jeton n'est pas signé, il n'est pas approuvé et, par conséquent, je ne pense pas que ce soit le flux.

scalaoauthplayframeworkoauth-2.0playframework-2.0
40
Marco

Vous pouvez utiliser un module appelé SecureSocial.

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

Celui-ci est assez raffiné et beaucoup de personnes dans la communauté Play semblent être au courant/utiliser ce module.

Une autorisation peut être utile https://github.com/schaloner/deadbolt-2/

Pour tout ce qui concerne la scala, https://github.com/t2v/play20-auth

17
Rakesh Waghela

J'ai porté Apache Amber sur Play2 Scala, voici le lien: https://github.com/cleanyong/oauth2play2scala

La raison de porter Apache Amber est:

  1. il a été testé
  2. mieux que fait maison
  3. il convient à Play2 Scala API
  4. facile à utiliser
  5. pas intrusif

Si vous souhaitez configurer le serveur oauth2 sur votre site, vous pouvez utiliser mon port. Il a un document.

16
Clean Yong

Fondamentalement, le flux standard est le suivant:

  1. à chaque demande, vérifiez dans le cookie ("session" dans le dialecte Play!) s'il contient un identifiant
  2. sinon, demander à l'utilisateur de s'authentifier auprès du fournisseur (Facebook ou autre chose)
  3. Si ok, le fournisseur retournera un identifiant, sauvegardera cet identifiant dans votre système de persistance (enregistrement) et dans le cookie/session en cours.
  4. lors des prochaines requêtes, vérifiez si l'id existe dans le cookie/session et correspond à un utilisateur existant dans votre système de persistance
  5. Pour vous "déconnecter", effacez simplement le cookie/session

Si vous voulez plus de détails, il suffit de demander :-)

7
ndeverge

OAuth est un protocole d'autorisation. Par conséquent, si vous envisagez une solution d'authentification, il se peut que ce ne soit pas le cas. 

Votre question dit que le consommateur de l’API aura diverses applications. Cela a conduit à 2 scénarios, 

 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)

Pour prendre en charge OAuth Eco-System, vous avez besoin d’un système de gestion de clés. À, 

  1. Générer clé/secret pour les applications. 
  2. Génération de AccessToken/Refresh_token/autorisation_code 

maintenant sur le point final, vous devez exposer, 

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

Sinon, la solution la plus simple/robuste serait, http://apigee.com

Vous pouvez utiliser l'écosystème OAuth existant d'Apigee.

4
Abhishek Tyagi

Je n'ai pas essayé moi-même, mais que diriez-vous de tuxdna module .

Serveur OAuth2 utilisant Play! 2.0 cadre

J'espère que ça aide

1
mosid

Vous pouvez essayer d’utiliser ce modèle de jeu associant le fournisseur OAuth 2 à Deadbolt . La portée de OAuth correspond au droit et au concept de rôle Deadbolt . Il utilise Redis pour stocker les jetons d’accès, qui expirent automatiquement après la période. vous configurez.

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

0
Leandro Glossman

J'ai eu le même problème, ce que j'ai fait (je suppose que ce n'est pas la meilleure solution) était de placer les méthodes du serveur REST dans un "@ Security.Authenticated (Secure.class)" un cookie de session (qui était également enregistré dans une table de hachage dans le backend). Le cookie de session a été généré après la connexion de l'utilisateur.

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

}

et

package controllers;

import ...;

public class Secure extends Security.Authenticator {

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

J'espère que cela t'aides 

0
xyz