[Epic] OAuth-Scopes vereinfachen
Warum machen wir das?
Statt den bisherigen OAuth-Scopes sollen künftig eindeutige URLs genutzt werden. Hintergrund ist die Nutzung eines OAuth-Servers für unterschiedliche APIs. Das Vorgehen ist hier beschrieben: https://www.connect2id.com/products/server/docs/guides/oauth-scopes
Im Rahmen dieses Epics sollen OAuth-Scopes, die nicht dem allgemeinen URl-Schema entsprechen, durch konforme ersetzt werden. Außerdem wollen wir bei den komplexen "send:..."-Scopes die (bisher nicht genutzte) Hierarchie des Scopes radikal zurückbauen und einen einzigen, konstanten Scope für das Senden verwenden.
Konkrete Anpassungen
-
read:statistics,https://schema.fitko.de/fit-connect/oauth/scopes/read:statistics=>https://schema.fitko.de/fit-connect/oauth/scopes/read-statistics. Diese Änderung ist unproblematisch, weil unsere internen OAuth-Clients bereits mit dem neuen Scope ausgestattet sind und die Scopes auch in keiner API-Dokumentation auftauchen. Es genügt, im ZSD die alten Scopes zu ignorieren und nur noch den neuen zu akzeptieren. -
send:region:DE<suffix>=>https://schema.fitko.de/fit-connect/oauth/scopes/send-submissions. Diese Änderung ist problematisch, weil alle Onlinedienste diese Scopes verwenden und möglicherweise sogar explizit anfragen. Deshalb wird ein drei-phasiger Rollout benötigt (neuen Scope zusätzlich akzeptieren, neuen Scope setzen, alten Code abbauen), sowie eine Kompatibilitätsschicht bei expliziten Anfragen alter Scopes. -
create:destination,https://schema.fitko.de/fit-connect/oauth/scopes/create:destination,https://schema.fitko.de/fit-connect/oauth/scopes/self-service-portal-api/create:destination=> ersatzlos streichen. Stattdessen sollhttps://schema.fitko.de/fit-connect/oauth/scopes/manage-destinationsauch zum Anlegen von Destinations berechtigen, sofern in der ZSD-Datenbank dascan_create_destinations-Flag gesetzt ist. Die ersten beiden Scopes gibt es bereits schon nicht mehr in der OAuth-Datenbank. Beim dritten ist zu beachten, dass wir auch hier eine Kompatibilitäts-Schicht für explizite Anfragen brauchen.
Vorgehen
Um zu Verhindern, dass ZSD und SSP Roadmaps feingranular abgestimmt werden müssen und koordinierte Releases erfolgen müssen, teilen wir die Migration in drei Phasen auf. Diese drei Stories können weitgehend unabhängig voneinander implementiert und released werden; es ist nur wichtig, dass die Release-Reihenfolge eingehalten wird.