OAuth mit Amazon/Alexa: Wie kann ich mir ein Access- und RefreshToken besorgen?

Hi,

vorab: Ich bin dabei einen eigenen Alexa-Skill schreiben - funktioniert auch super. Da das Ding später auch Andere nutzen sollen - benötige ich eine Methode auf dem Server den entsprechenden User ausfindig zu machen.

Über Amazon/Alexa ist das offenkundig über OAuth 2.0 vorgesehen, womit ich mich nun schon sehr lange rumschlage.

Grundsätzlich: Ich arbeite mit MVC5 unter .NET 4.6.1, gehostet wird das Ding auf einem IIS.

Meine nicht funktionierende Anwendung läuft folgendermaßen:
a) Hab über den AccountController eine neue Seite - extra für Alexa-Benutzer angelegt, bei der die sich anmelden und gleichzeitig einige Alexa-Parameter behalten werden. Funktioniert: User meldet sich (ggf) an, es erfolgt eine Abfrage, ob Alexa vertraut werden kann, es erfolgt ein Redirect mitsamt einem Code, den Alexa auch akzeptiert --> alles klar

Im Anschluss an vorgenannte Redirect, versucht Alexa sich mit dem von mir generierten Code einen Access- und einen Refresh-Token zu besorgen:

Erster Versuch:
via app.UseOAuthAuthorizationServer und etwas Config war nun mein erster Versuch - leider funktioniert hier gar nichts, weil diese MiddleWare scheinbar davon ausgeht, dass alle Parameter als QueryParameter verfügbar sind. Dummerweise schickt Alexa die als FormParameter.

Zweiter Versuch:
Durch viel Kleinarbeit und Kopiererei von Microsoft.Owin... hab ich nun einen SelfOAuthAuthorizationServer geschrieben, der die Parameter aus dem FormBody holt,
client_id validiert, redirect_uri validiert, code validiert (klappt alles soweit) - und schlussendlich soll eine Standardantwort erstellt werden.

Nur, dass die Standardantwort ein Redirect auf "redirect_uri" ist - ich aber theoretisch wenn ich den OAuth-Ablauf korrekt verstanden habe - eigentlich mit einer Reponse antworten müsste, die einen Access- und einen Refresh-Token bereitstellt.

Meine Fragen:
Ist das so unpraktisch? Mache ich was komplett falsch?
Falls ja: Gibt es irgendwo ein vollständiges Tutorial? Ich finde leider überall nur Brocken.
Falls nein: Jemand eine Idee, wie ich als Antwort ein gültiges paar Token ausgeben könnte?

Vielen Dank

Liebe Grüße

Es ist soweit korrekt, dass Katana/Owin den access_token per default über den Query String holt.
Aber es ist nicht notwendig, dass man gleich die ganze Middleware neu schreiben muss, sondern man schreibt einfach einen eigenen Provider und gibt diesen an die Middleware.
Retrieving bearer tokens from alternative locations in Katana/OWIN

Spätestens, wenn man auf die Idee kommt, eine standardisierte Authorisierungsmiddleware neu zu schreiben, würde ich überlegen, ob nicht auf dem Holzweg bin.
Zudem ist der Quellcode ja offen, da sieht man ja, dass man einfach nen eigenen Provider einkippen kann (übrigens auch anhand von IntelliSense) 😉

Hallo Abt,

ich glaub der Link von dir passt nicht - soweit war ich ja noch gar nicht - ich wollte ja erst mal soweit kommen, dass überhaupt ein Token erstellt wird...

Habe zwischenzeitlich noch eine bessere Lösung gefunden - Für alle mit dem selben Anliegen (in Hinsicht auf Alexa):

Ein eigener OAuth-Provider ist gar nicht nötig, man registriert den Skill (z.B.) bei Amazon-Login - lässt den Skill dort seinen Token abholen - der Skill schickt dann brav bei jedem Request seinen Token mit - und man selbst kann mit dem Token dann intern z.B. die Mail-Adresse abfragen um Accounts im Hintergrund zu verbinden.
Wird auf folgender Seite beschrieben:
https://developer.amazon.com/blogs/post/Tx3CX1ETRZZ2NPC/Alexa-Account-Linking-5-Steps-to-Seamlessly-Link-Your-Alexa-Skill-with-Login-wit

Im Endeffekt war es ohnehin keine gescheite Idee einen eigenen OAuth-Server aufzustellen, wenn's auch viel einfacher geht.

LG

PS:

Was ASP.NET Core 2.0 angeht - wann genau kommt das denn?

Bin von .NET Core bislang noch nicht wirklich überzeugt - was ich bislang gesehen habe waren viele Breaking Changes dabei, die schon allerhand Turorials und Beispielcode wertlos gemacht haben... Eigentlich ein Zeichen, dass man ein solches Framework noch ein bisschen wachsen lassen sollte.

LG

Und was genau hindert Dich dran, ASP.NET Core mit .NET Framework statt .NET Core zu verwenden?
Wohl doch nicht soo genau angeschaut, wa? 😉

ASP.NET Core 1.0 kann sowohl mit .NET Core wie auch mit .NET Framework verwendet werden - und zwar schon lang und von Anfang an.
.NET Core 1.0 ist fertig, 2.0 steht in den Startlöchern, das eine Menge mehr an Schnittstellen abdeckt.
ASP.NET Core 2.0 kommt wohl im April und bekommt auch ein paar neue Features.

Breaking Changes gibt es eigentlich keine, außer man verwendet Schnittstellen, die es eben in .NET Core gibt. Aber das ist die Natur der Sache bei einer Cross-Plattform-Technologie.
Der .NET Standard ist dazu da, dass es in allen Plattformen, die .NET Standard implementieren, keine Breaking Changes gibt.

Wer .NET Core - vor allem im Webbereich - ignoriert, wird einen Fehler begehen 😉
Gerade wer Performance will kommt um .NET Core nicht drum herum. Das .NET Framework ist nicht besonders geeignet für das moderne, schnelle Web, weshalb es eben auch .NET Core gibt.

Wie ich sehe, hier ist in Sachen Wissenstransfer noch viel Arbeit vor uns... 😉

ASP.NET Core 2.0 kommt wohl im April und bekommt auch ein paar neue Features.

Die offizielle Roadmap sagt was anderes. (Q3/17) Was stimmt nun?

LaTino

Wahrscheinlich stimmt die Roadmap und ich hab die Preview in Erinnerung gehabt.