@Abt:
CORE
Klar, Core steht ganz oben auf meiner Liste, sobald ich das Ding unter Linux zum Laufen gebracht habe. 😉 Aktuell kämpfe ich genau damit. 😕 Aber Scott Hanselmann ist ja ein guter Vorreiter. Ich bin nur nicht so fit auf der Linux-Shell.
URL-CHECK
Na ja, eigentlich ist der ClientToken unsinnig. Wichtig ist allein die Identifizierung der URL, von der aus der Request aufgerufen wird. Der Token sollte eigentlich für einen Kunden stehen, somit allerdings auch diversen Daten und Einstellungen, so beispielsweise der eingesetzten URL für die Aufrufe meiner REST-API. - Mir geht es primär darum, verhindern zu können, dass unauthentifizierte URLs (Kunden) auf meine REST-API zugreifen können. Tokens lassen sich kopieren, aber ich vermute, dass es Wege gibt, die Remote-URL abzufragen.
USER-AUTH
API-User-Authentifizierung erfolgt durch einen UserToken. Daher absolut Standard-Prozedere. Wenn ich das mit der Kunden-URL hinbekommen würde, wäre ich auch mit oAuth zufrieden. - Mal sehen. Aber die User-Authentifizierung ist aktuell nicht das Problem. Sondern eben jener URL-Check.
REST-VALIDATE
Auch die Validierung sollte kein Problem darstellen. Da die REST-API nah an RESTfull orientiert sein soll und um keine Special-Methods oder logische Operatoren erweitert wird. 😃 Klar müssen alle Request-Attribute geprüft werden, aber das sollte einfach sein.
@emuuu:
Ich bin immer noch der Meinung, dass sich JWT (wird von ++IdentityServer4 ++verwendet) einfach zu klonen oder zu manipulieren ist, insofern eine der beiden Seiten clientseitig (bspw. JavaScript) verarbeitet wird. Na ja, ... ich bin grundsätzlich ein großer Fan von oAuth, hatte ich auch schon in PHP eingesetzt. Muss nur schauen, wie ich ein Script (bzw. alle Request aus einer bestimmten Remote-URL) identifiziere, ohne dass jemand einfach den Token kopieren kann. - Die User-Auth ist mir dann klar.
Prinzipiell finde ich, ist dieser ++IdentityServer4 ++genau das, was ich suche. Auch wegen dem Unterschied zwischen Kunde und Nutzer. - Komplizierter ist allerdings meine Business-Logik, denn Nutzer sind global und können auch auf verschiedenen Kundenseiten die Requests abfeuern, also egal über welche Kunden-URL. Kunden sind die, die den Service auf ihrer Website anbieten wollen. User sind unabhängig von den Kunden, daher global. Sie können sich also auf allen Kunden-URLs anmelden und den Service nutzen.
Rein fiktives Beispiel:
Stellt euch vor, es gibt eine Datenbank voll mit Kneipen, Restaurants usw... Der User hat einen Account bei eat-n-drink.com und kann dort auch seine Daten verwalten oder schauen, welche Kneipen ihn ansprechen (Ort, Getränke, Essen, Preise, Öffnungszeiten, Fotos, Bewertungen, etc...).
Dann gibt es ja noch die Vergleichsseiten (die sprießen ja derzeit aus jeder Richtung hervor), bspw. wohin-in-berlin.de oder dublin-afterwork.ie. Der "Kunde" (also bspw. wohin-in-berlin.de) kann auf alle für ihn relevanten Daten (Kneipen, Restaurants, Clubs usw...) zugreifen, sein Design/Frontend aber selber auswählen. - Erstmal egal ob nun ein registrierter Nutzer darauf zugreift oder nicht.
Wenn nun aber ein bereits registrierter User über wohin-in-berlin.de darauf zugreift (via Cookie oder Web Storage) oder - falls der Kunde es auf seiner Seite zulässt - sich direkt einloggt, kann der User nun auch sehen, welcher seiner Freunde bereits welche Kneipen besucht hat oder deren Bewertungen lesen, ggf. auch eigene Bewertungen verfassen. Quasi über wohin-in-berlin.de auf die REST-API von eat-n-drink.com darauf zuzugreifen.
Okay, das Beispiel hinkt ein wenig, da es hier sicherlich zu Datenschutz-Konflikten kommen würde (aber ich bin kein Jurist und es ist ein rein fiktives Beispiel, hätten auch Reisebüros und die API eines Fluglinien-Portals sein können). Trotzdem soll aber nun verhindert werden, dass was-geht-ab-in-berlin.x.gp jene REST-API benutzen kann, ohne bei mir einen Kunden-Account anzulegen, diverse Settings zu setzen und natürlich den AGBs zuzustimmen.