Ich entwickle eine Anwendung mit Play 2.0 und Scala , die einige REST - API verfügbar macht. Diese APIs werden von verschiedenen Anwendungen (Web, Mobile oder Desktop) verwendet. Daher scheint das OAuth-Protokoll (OAuth2) am besten geeignet zu sein.
Ich würde auch zunächst einen externen OAuth-Provider wie Facebook verwenden.
Meine Frage ist: Was ist der genaue Ablauf, um den einzelnen REST -Aufruf zu autorisieren? Was muss ich bei jedem Anruf auf der Serverseite erwarten und was sollte ich mit dem externen Anbieter überprüfen?
Mit OAuth1 wusste ich, dass der Client das Token mit der gesamten signierten Anforderung gesendet hat, aber mit Oauth2 denke ich nicht so, ich stelle mir vor, dass ein Token nicht als vertrauenswürdig eingestuft wird und daher glaube ich nicht, dass dies der Fluss ist.
Sie können ein Modul namens SecureSocial verwenden.
https://github.com/jaliss/securesocial/
Dieses ist sehr verfeinert und viele Leute in der Play-Community scheinen dieses Modul zu kennen/zu verwenden.
Für die Autorisierung kann nützlich sein . https://github.com/schaloner/deadbolt-2/
Für das Ende der Arbeit mit Scala: https://github.com/t2v/play20-auth
Ich habe Apache Amber auf Play2 Scala portiert, hier ist der Link: https://github.com/cleanyong/oauth2play2scala
Der Grund für die Portierung von Apache Amber ist:
Wenn Sie den oauth2-Server auf Ihrer Site einrichten möchten, können Sie meinen Port verwenden. Es hat ein Dokument.
Grundsätzlich ist der Standardfluss der folgende:
Wenn Sie mehr Details wünschen, fragen Sie einfach :-)
OAuth ist ein Autorisierungsprotokoll. Wenn Sie sich eine Authentifizierungslösung ansehen, ist dies möglicherweise nicht die Authentifizierung.
Ihre Frage ist, dass der Benutzer der API verschiedene Anwendungen haben wird. Dies führte zu 2 Szenarien,
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)
Um OAuth Eco-System zu unterstützen, benötigen Sie ein Schlüsselverwaltungssystem. Zu,
jetzt zum Endpunkt kommen, müssten Sie freilegen,
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
Ansonsten wäre die einfachste/robusteste Lösung http://apigee.com
Sie können das vorhandene OAuth-Ökosystem von Apigee verwenden.
Ich habe es nicht selbst ausprobiert, aber wie wäre es mit tuxdna module .
OAuth2 Server mit Play! 2.0 Framework
Ich hoffe das hilft
Sie können versuchen, diese Vorlage für ein Spiel zu verwenden, bei dem der OAuth 2-Anbieter mit Deadbolt ..__ kombiniert wird. Der OAuth-Bereich ist dem Berechtigungs- und Rollenkonzept von Deadbolt zugeordnet .. _ Er verwendet Redis zum Speichern von Zugriffstoken und verfällt nach Ablauf der Zeit automatisch Sie konfigurieren.
Ich hatte das gleiche Problem, was ich getan habe (ich glaube, es ist nicht die beste Lösung), die Methoden des REST -Servers innerhalb eines "@ Security.Authenticated (Secure.class)" anzuordnen und zu verwenden ein Session-Cookie (der auch in einer Hash-Tabelle im Backend registriert wurde). Das Sitzungs-Cookie wurde nach der Benutzeranmeldung generiert
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...
}
und
package controllers;
import ...;
public class Secure extends Security.Authenticator {
@Override
public String getUserId(Http.Context context) {
return context.session().get("user_id");
}
...
}
Hoffe das hilft