Erarbeitung einer API-Strategie für einen Krypto-Finanzdienstleister - Bachelorarbeit
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Erarbeitung einer API-Strategie für einen Krypto-Finanzdienstleister Bachelorarbeit Gianni Rüegg gianni.rueegg@stud.hslu.ch Hochschule Luzern Departement Informatik BSc Wirtschaftsinformatik Experten: Prof. Dr. Tim Weingärtner Dr. Thomas Weigold 3. Januar, 2022
Hochschule Luzern Department Informatik Bachelorarbeit an der Hochschule Luzern – Informatik Titel: Erarbeitung einer API-Strategie für einen Krypto-Finanzdienstleister Student: Gianni Rüegg Studiengang: BSc Wirtschaftsinformatik Abschlussjahr: 2022 Betreuungsperson: Prof. Dr. Tim Weingärtner Experte: Dr. Thomas Weigold Auftraggeber: Markus Perdrizat Codierung / Klassifizierung der Arbeit: ☒ Öffentlich (Normalfall) ☐ Vertraulich Eidesstattliche Erklärung Ich erkläre hiermit, dass ich die vorliegende Arbeit selbständig und ohne unerlaubte fremde Hilfe angefertigt habe, alle verwendeten Quellen, Literatur und andere Hilfsmittel angegeben ha be, wörtlich oder inhaltlich entnommene Stellen als solche kenntlich gemacht habe das Vertraulichkeitsinteresse des Auftraggebers wahren und die Urheberrechtsbestimmungen der Hochschule Luzern respektieren werde. Ort / Datum, Unterschrift _____________________________________________________ Seite 2 von 70
Hochschule Luzern Department Informatik Abgabe der Arbeit auf der Portfolio Datenbank: Bestätigungsvisum Studentin/Student Ich bestätige, dass ich die Bachelorarbeit korrekt gemäss Merkblatt auf der Portfolio Datenbank abgelegt habe. Die Verantwortlichkeit sowie die Berechtigungen habe ich abgegeben, so dass ich keine Änderungen mehr vornehmen kann oder weitere Dateien hochladen kann. Ort / Datum, Unterschrift _____________________________________________________ Verdankung Vielen Dank an Dr. Prof. Tim Weingärtner für die Unterstützung und spannenden Diskussionen während der Arbeit. Ein weiterer Dank geht an den Auftraggeber, Markus Perdrizat, der mich immer wieder mit hilfreichen Feedbacks unterstützt und weitergebracht hat. Ebenfalls danke ich Thomas Rüegg und Martin Dolder für die sorgfältige Korrektur der Arbeit. Ausschliesslich bei Abgabe in gedruckter Form: Eingangsvisum durch das Sekretariat auszufüllen Rotkreuz, den ____________________ Visum: ____________________ Hinweis: Die Bachelorarbeit wurde von keinem Dozierenden nachbearbeitet. Veröffentlichungen (auch auszugsweise) sind ohne das Einverständnis der Studiengangleitung der Hochschule Luzern – Informatik nicht erlaubt. Copyright © 2022 Hochschule Luzern – Informatik Alle Rechte vorbehalten. Kein Teil dieser Arbeit darf ohne die schriftliche Genehmigung der Studiengangleitung der Hochschule Luzern – Informatik in irgendeiner Form reproduziert oder in eine von Maschinen verwendete Sprache übertragen werden. Seite 3 von 70
Hochschule Luzern Department Informatik Abstract Die noch junge Krypto-Finanzbranche ist schnelllebig und entwickelt sich in hohem Tempo weiter. Mit der steigenden Nutzerzahl von Kryptowährungen werden auch die Anforderungen an Dienstleister in diesem Bereich immer grösser. Bitcoin Suisse ist ein führender Krypto- Finanzdienstleister in der Schweiz und bietet heute ihren Kunden verschiedene Services wie Brokerage, Staking, Custody, Lending oder Payments an. Um neue Kundensegmente, wie etwa Banken oder Vermögensverwalter, mit diesen Krypto-Dienstleistungen zu bedienen, sollen neue Kanäle zur Datenübermittlung bereitgestellt werden. Die Arbeit verfolgt das Ziel, eine API - Strategie zu entwickeln, die dem Unternehmen das Wachstum im B2B- und B2B2C-Bereich ermöglicht. Dabei soll ein Strategiedokument erstellt werden, welches Vorgaben und Standards definiert, was Bitcoin Suisse in Zukunft bei der Entwicklung von externen APIs beachten sollte. Das Dokument soll sowohl organisatorische wie auch technische Aspekte der API-Entwicklung abdecken und intern als Leitfaden für verantwortliche Personen dienen. Das Strategiedokument soll dabei Produkt-agnostisch und sowohl für bestehende wie auch zukünftige Produkte gültig sein. Das Ergebnis der Arbeit ist ein mehr als zwanzig Seiten langes Strategiedokument für Bitcoin Suisse. Es wurde sowohl vom Auftraggeber als auch ersten Stakeholdern validiert und Feedback eingeholt. Die wichtigsten Punkte bezüglich der Entwicklung von externen APIs sind darin beschrieben. Die Entscheidungen darin wurden mehrheitlich aus Erkenntnissen der Literaturrecherche, externen Interviews und Fachdiskussionen mit Stakeholdern getroffen. Das Dokument enthält ebenfalls die Hypothese für die drei Punkte Brokerage, Staking und Custody, wo konkrete Empfehlungen für die nächsten Schritte beschrieben werden. Für die Trading API wurde eine Gap-Analyse durchgeführt, welche als direkte Handlungsempfehlung für das Team vorgeschlagen wurde. Nebst dem Strategiedokument wurden dem Unternehmen eine vollständige Customer Jour ney Map mit zwei Personas (Software-Architekt und Product Manager) abgegeben. Sie beschreibt die wichtigsten Nutzungsphasen, beginnend mit der «Wahrnehmung» bis hin zur «Auflösung der Partnerschaft», welche eine Kundin/ein Kunde während der Produktnutzung durchläuft. Zusätzlich wurde ein Prototyp entwickelt: eine Webapplikation, die die OpenAPI-Spezifikation einer Dummy-API anzeigt. Die Spezifikation wird automatisch generiert und vom Frontend konsumiert. In der Dokumentation sind die verfügbaren Endpoints zu sehen, entsprechende Request/Response Models werden angezeigt und welche HTTP-Status-Codes ein Endpoint zurückgibt. Seite 4 von 70
Hochschule Luzern Department Informatik Inhaltsverzeichnis 1 Einleitung .................................................................................................................... 7 1.1 Problemstellung .......................................................................................................... 7 1.2 Fragestellungen ........................................................................................................... 7 1.3 Ziel .............................................................................................................................. 7 1.4 Relevanz ...................................................................................................................... 8 1.5 Abgrenzung ................................................................................................................. 8 2 Stand der Forschung ..................................................................................................... 9 2.1 Product Mindset.......................................................................................................... 9 2.1.1 Business Ziele definieren ................................................................................. 9 2.1.2 Das API-Produkt-Team ................................................................................... 10 2.2 Die drei Säulen einer erfolgreichen API-Strategie ...................................................... 11 2.2.1 Outside-in-Ansatz .......................................................................................... 11 2.2.2 Time to Market.............................................................................................. 12 2.2.3 Iterative Weiterentwicklung .......................................................................... 13 2.3 KPIs definieren und etablieren .................................................................................. 13 2.4 Security ..................................................................................................................... 15 2.4.1 Häufige Sicherheitslücken und Schwachstellen .............................................. 16 2.4.2 Best Practises für API-Security ....................................................................... 17 2.5 Authentifizierung und Autorisierung ......................................................................... 18 2.5.1 OAuth 2.0 mit OpenID Connect ..................................................................... 18 2.5.2 Basic Authentication ...................................................................................... 19 2.5.3 Bearer Authentication ................................................................................... 19 2.6 Technologie ............................................................................................................... 20 2.6.1 REST .............................................................................................................. 20 2.6.2 WebSockets ................................................................................................... 20 2.7 Performance ............................................................................................................. 21 2.7.1 Caching ......................................................................................................... 21 2.7.2 Skalierung ..................................................................................................... 21 2.7.3 Performance trifft auf Security ...................................................................... 23 2.8 Dokumentation und Zugänglichkeit ........................................................................... 23 2.8.1 Manuelle Dokumentation .............................................................................. 23 2.8.2 Automatisierte Dokumentation ..................................................................... 23 2.9 Versionierung ............................................................................................................ 24 3 Stand der Technik bei Bitcoin Suisse ............................................................................ 26 3.1 Produkte ................................................................................................................... 26 3.2 Externe APIs .............................................................................................................. 26 3.3 Eingesetzte Technologiestandards ............................................................................. 27 3.4 Dokumentation ......................................................................................................... 27 3.5 Organisationsstruktur................................................................................................ 27 3.6 Demo / Sandbox Umgebung ...................................................................................... 27 4 Ideen und Konzepte .................................................................................................... 28 4.1 Blueprint ................................................................................................................... 28 4.2 Customer Journey Map mit Personas ........................................................................ 28 4.3 Gap-Analyse .............................................................................................................. 28 4.4 Hypothese ................................................................................................................. 28 4.5 Prototyp für eine API-Dokumentation ....................................................................... 29 5 Methoden .................................................................................................................. 29 5.1 Vorgehen .................................................................................................................. 29 5.2 Literaturrecherche .................................................................................................... 31 5.3 Interviews ................................................................................................................. 31 5.4 Workshops ................................................................................................................ 31 Seite 5 von 70
Hochschule Luzern Department Informatik 5.5 Konkurrenzanalyse .................................................................................................... 32 6 Realisierung ............................................................................................................... 33 6.1 Aufnahme der Kundenbedürfnisse durch Interviews ................................................. 33 6.2 Erarbeitung des Blueprints ........................................................................................ 34 6.2.1 Vision und Ziele ............................................................................................. 34 6.2.2 Organisation und Verantwortung .................................................................. 35 6.2.3 Beginn mit MVPs ........................................................................................... 35 6.2.4 API-Guidelines ............................................................................................... 36 6.3 Hypothese ................................................................................................................. 40 6.3.1 Trading .......................................................................................................... 41 6.3.2 Staking .......................................................................................................... 41 6.3.3 Custody ......................................................................................................... 42 6.4 Ausarbeitung der Customer Journey Map .................................................................. 43 6.4.1 Erstellung der Personas ................................................................................. 43 6.4.2 Definition der Phasen .................................................................................... 45 6.4.3 Beschreibung der Phasen .............................................................................. 46 6.4.4 Customer Journey Map.................................................................................. 47 6.5 Gap-Analyse .............................................................................................................. 48 6.6 Entwicklung des Prototypen ...................................................................................... 49 6.6.1 Evaluation des Tools ...................................................................................... 49 6.6.2 Entwicklung der Web-Applikation .................................................................. 49 6.6.3 Entwicklung der Dummy-API ......................................................................... 50 6.6.4 Dokumentation ausbauen ............................................................................. 51 6.6.5 Reflexion zum Prototyp ................................................................................. 52 6.6.6 Abbildung Entwickler-Portal .......................................................................... 53 7 Evaluation und Validation ........................................................................................... 54 7.1 Interne Validierung ................................................................................................... 54 7.2 Externe Validierung ................................................................................................... 55 7.3 Zusammenfassung ..................................................................................................... 56 8 Ausblick ..................................................................................................................... 56 9 Anhänge .................................................................................................................... 57 9.1 Aufgabenstellung ...................................................................................................... 57 9.2 Interviews ................................................................................................................. 58 9.2.1 Genereller Fragebogen .................................................................................. 58 9.2.2 Einführung..................................................................................................... 58 9.2.3 Interview 1 (Kundenbedürfnisse) ................................................................... 59 9.2.4 Interview 2 (Kundenbedürfnisse) ................................................................... 60 9.2.5 Interview 3 (Kundenbedürfnisse) ................................................................... 61 9.2.6 Interview 4 (Validierung) ............................................................................... 63 9.3 Zeitplan ..................................................................................................................... 65 9.4 Prototyp .................................................................................................................... 66 9.5 Customer Journey Map & Personas ........................................................................... 66 9.6 Rate Limiting – Beispiel ............................................................................................. 66 10 Abbildungsverzeichnis ................................................................................................ 68 11 Tabellenverzeichnis .................................................................................................... 68 12 Literaturverzeichnis .................................................................................................... 68 Seite 6 von 70
Hochschule Luzern Department Informatik 1 Einleitung 1.1 Problemstellung Unternehmen, die schon länger operativ tätig sind, blicken oft auf Jahre mit grossen Veränderungen zurück. Dies trifft vor allem auf Unternehmen zu, welche in der noch jungen Krypto-Finanzbranche tätig sind. 2009 entstand mit dem Bitcoin auch die Krypto-Finanzbranche. Die Massenadaption fand aber erst einige Jahre später, ab 2017, mit dem Aufkommen vieler weiterer Kryptowährungen statt. Durch die Schnelllebigkeit dieser noch jungen Branche ist eine ständige Anpassung notwendig. Mit der steigenden Nutzerzahl von Kryptowährungen sind auch die Anforderungen an die entsprechenden Dienstleister stark gestiegen. Bitcoin Suisse (BTCS) ist seit 2013 auf dem Markt tätig und bietet verschiedenste Dienstleistungen im Bereich der Kryptowährungen an. Dazu gehören Prime Brokerage, Staking, Pay, Lending und Custody für Privatkunden und institutionelle Kunden in der Schweiz und weltweit. Diese Dienstleistungen sind heute auf Privatkunden ausgelegt und wurden ausgehend von einem persönlichen Beratungsansatz und viel manueller Arbeit entwickelt. Durch das anschliessende Wachstum kamen später eine Online-Plattform und eine Mobile App dazu. Diese ermöglichen es den Kunden, die Dienstleistungen im Self-Service zu beziehen. BTCS möchte im B2B-Bereich stark wachsen und dazu ihre Dienstleistungen an institutionelle Kunden über APIs1 zugänglich machen. Obwohl heute schon viele interne APIs eingesetzt werden, gibt es keine globale Firmenstrategie in Bezug auf externe APIs. 1.2 Fragestellungen Um die obige Problemstellung zu behandeln, befasst sich diese Arbeit mit folgenden Fragestellungen: ▪ Welche Kundenbedürfnisse bestehen im Markt in Bezug auf externe APIs? ▪ Wie kann der Einstieg in die Nutzung unserer APIs für externe Entwickler möglichst einfach gestaltet werden? ▪ Wie kann sichergestellt werden, dass unsere APIs aktuellen Sicherheitsstandards folgen? ▪ Wie kann erreicht werden, dass verschiedene APIs über mehrere Produkte hinweg konsistent bleiben und die Bedürfnisse der einzelnen Produkt-Teams abdecken? 1.3 Ziel In dieser Arbeit wird aufgezeigt, wie ein etabliertes Unternehmen im Bereich API eine neue strategische Richtung einschlagen kann. Ziel dabei ist es, den Prozess und die Methodik zu reflektieren, die für das Erreichen einer erfolgreichen API-Strategie notwendig sind. Die Arbeit soll die wichtigsten Erkenntnisse aus der Forschung und Literatur widerspiegeln, welche als grosse Stütze für eine passende API-Strategie dienen können. 11 https://en.wikipedia.org/wiki/API Seite 7 von 70
Hochschule Luzern Department Informatik 1.4 Relevanz Um die Jahrtausendwende begann sich die API-Economy zu bilden. Heute führende Unternehmen wie Salesforce oder eBay begannen ihren Nutzern und Kunden APIs anzubieten. 2002 gründete Amazon das Cloud-Unternehmen Amazon Web Services, das zu den führenden Cloud- Unternehmen gehört. Mit dem Aufkommen der Soziale Medien wie Facebook oder Twitter einige Jahre später, unterstützten auch sie die Verbreitung von APIs mit der Bereitstellung von Schnittstellen, die erste Interaktionen mit ihren Plattformen ermöglichten (Lane, 2019). Knapp zwei Dekaden später, sind gemäss Akamai API-Aufrufe für 83% des globalen Internetverkehrs zuständig2. Dieses Wachstum spiegelt sich auch in erfolgreichen Unternehmen wider. So hat das API-First3-Unternehmen «Stripe» kürzlich in einer Serie-H-Finanzierung weitere USD 600 Millionen eingenommen und wird neu mit einem Marktwert von USD 95 Milliarden bewertet4. Das für das Unternehmen in Zukunft auch der Krypto- Finanzmarkt von strategischer Bedeutung ist, zeigt eine Nachrichtenmeldung, in der Stripe den Aufbau eines neuen Krypto-Teams für ihre Payments-Lösung ankündigt5. Abbildung 1: Bewertung von Stripe, Source: crunchbase.com Folglich soll diese Arbeit aufzeigen, auf welche Art und Weise ein Einstieg in diese Welt gelingen könnte. Die Erkenntnisse der Arbeit sollen für andere Unternehmen einen möglichen Lösungsweg für ein ähnliches Ziel aufzeigen. Dadurch sollen viele FinTechs oder auch etablierte Finanzanbieter in der Schweiz profitieren können. 1.5 Abgrenzung Diese Arbeit fokussiert auf die Beschreibung und Ausarbeitung der API-Strategie. Eine effektive Umsetzung dieser Strategie erfolgt zu einem späteren Zeitpunkt. Es werden keine APIs entwickelt, da dies den Rahmen der Arbeit sprengen würde. Da die Strategie auf bestehende Produkte und Dienstleistungen abzielt, ist die Definition eines Erlösmodells nicht Teil dieser Arbeit. Entsprechende Erlösmodelle wurden schon zu einem früheren Zeitpunkt definiert und sollen in dieser Form übernommen werden. Die aus der Strategie zu entstehenden APIs dienen als zusätzlichen Kanal und müssen nicht eigenständig monetarisiert werden. Wie in der Problemstellung beschrieben, setzt BTCS schon heute viele verschiedene interne APIs ein. Die Definition einer Strategie für diese internen APIs ist nicht Teil dieser Arbeit. Sie fokussiert sich komplett auf externe APIs. 2 https://www.akamai.com/newsroom/press-release/state-of-the-internet-security-retail-attacks-and-api-traffic 3 https://swagger.io/resources/articles/adopting-an-api-first-approach/ 4 https://news.crunchbase.com/news/under-the-hood-a-closer-look-at-stripe-the-most-highly-valued-venture-backed-private- company-in-the-us/ 5 https://cointelegraph.com/news/stripe-builds-new-crypto-team-for-payments-three-years-after-dropping-bitcoin Seite 8 von 70
Hochschule Luzern Department Informatik 2 Stand der Forschung In diesem Abschnitt wird beschrieben, welche Vorgehensweisen und Themenbereiche für eine erfolgreiche API-Strategie von Bedeutung sind. 2.1 Product Mindset Spricht man von einer API (Application Programmable Interface), handelt es sich um ein technisches Werkzeug, wie Software miteinander kommuniziert und Daten ausgetauscht werden können. Obwohl dies eine technische Komponente darstellt, wäre es falsch, diese nur als solche zu betrachten (Apigee, 2018). Vielmehr sollte eine API ein konkretes Produkt darstellen, welches eine bestimmte Dienstleistung erbringt. Dies kann sowohl intern wie auch extern sein: ▪ Intern: Die eigenen Entwickler verwenden diese API, um eine Applikation oder einen Service für interne Prozesse abzubilden. ▪ Extern: Kunden benutzen die API, um ein Produkt oder Service in ihre Systeme zu integrieren, ohne dabei mit einer Weboberfläche zu interagieren. In beiden Fällen hat die konsumierende Partei gewisse Bedürfnisse und muss über die Funktionsweise der API informiert werden. Um an dieser Stelle ein gutes Benutzererlebnis zu schaffen und die Kundenbedürfnisse abzudecken, sollte eine API als ein Produkt angesehen werden. Unternehmen, die ihre APIs als Produkt behandeln, haben typischerweise ein erfolgreicheres API- Programm (Apigee, 2018). Anstatt die API in einem einmaligen Projekt zu entwickeln, wird ein voller Product Life Cycle definiert und es werden Langzeit-Roadmaps erstellt. Dabei wird die API immer weiterentwickelt und an neue Businessanforderungen angepasst. Dadurch wird die Produktivität von internen und externen Entwicklern gesteigert und der potenzielle Mehrwert einer API wahrscheinlicher erreicht. Ein wichtiger Teil eines Product Mindset ist das Design der API (Apigee, 2018). Das Design kann eine grosse Auswirkung auf die später Benutzung haben und entscheidet auch über die Erweiterbarkeit in der Zukunft. Würde eine API nur als einmaliges Projekt angesehen werden, so würden allenfalls die Dokumentation, Versionierungskonzepte oder Sicherheitsaspekte aussen vorgelassen werden. Häufig werden APIs so designt, dass sie bestimmte Projektanforderungen erfüllen. Dies könnte dazu führen, dass die API an vielen Stellen angepasst werden müsste, um zukünftige Use Cases zu unterstützen. 2.1.1 Business Ziele definieren Erfolgreiche APIs verfolgen idealerweise bestimmte Business Ziele. Bevor eine API entwickelt wird, sollten einige Fragen beantwortet werden (Jacobsen, Brail, & Woods, 2011): ▪ Was ist der Businessnutzen dieser API? ▪ Was wollen wir damit erreichen und welches Problem lösen wir? ▪ Welche Opportunitäten ergeben sich dabei? Geeignete Business Ziele allein genügen aber nicht. So muss eine gemeinsame Vision für die API geschaffen werden. Es sollte von Anfang an definiert werden, was das Endziel der API ist (Jacobsen, Brail, & Woods, 2011). Für Bitcoin Suisse könnte folgendes Statement ein Beispiel für ein Vision sein: «In drei Jahren wollen wir durch unsere APIs der führende Anbieter von Krypto- Finanzdienstleistungen im B2B-Bereich sein». Solche Aussagen schaffen gemeinsames Verständnis und man arbeitet auf dasselbe Ziel hin. Auch andere fundamentale Fragen sind frühzeitig zu klären. Welche nächsten Schritte müssen wir tätigen, um unsere Ziele erreichen zu können (Jacobsen, Brail, & Woods, 2011)? Woran wird der Erfolg des Produktes gemessen? Seite 9 von 70
Hochschule Luzern Department Informatik Je nach Betrachtungsweise könnten dies unterschiedliche Kriterien sein. So kann die API einen Erfolg sein, wenn … ▪ … dadurch mehr Umsatz erzielt wird. ▪ … viele Entwickler und Kunden sie einsetzen. ▪ … sie stabil läuft und wenig Ausfälle aufweist. ▪ … dadurch mehr Menschen auf der Welt den Zugang zu Kryptowährungen ermöglicht. Je früher also ein gemeinsames Verständnis über diese Punkte geschaffen wird, desto unwahrscheinlicher sind spätere Konflikte oder Überraschungen. 2.1.2 Das API-Produkt-Team Nachdem eine Vision entstanden ist, ist es die Aufgabe des Product Managers die Vorteile der API an Entwickler, Kunden und Business Stakeholders verständlich zu machen. Wenn es anschliessend um die Umsetzung geht, sollte diese in einem Team mit unterschiedlichen Rollen stattfinden (RedHat, 2019). Der Product Manager ist für die Strategie und die Erreichung der Business Ziele verantwortlich. Es gibt Software-Architekten, die technologische Best Practices und Standards vorgeben. Diese werden anschliessend von Entwicklern umgesetzt und von einem Betriebsteam betrieben. Auch (Apigee, 2018) sieht diese Rollen als Notwendigkeit an und ergänzt das API-Team noch durch weitere Personen: • Der API-Evangelist vertritt die Konsumenten der API und muss daher auch die genauen Bedürfnisse der Entwickler kennen. Er hat die Verantwortung für die Dokumentation und stellt sicher, dass genügend Informationen zur Nutzung der API vorhanden sind. Der API- Evangelist kümmert sich um interne und externe Entwickler und nimmt damit oft auch die Rolle des Community Managers ein. • Der API-Champion ist das Gegenstück zum API-Evangelist und stellt sicher, dass der Informationsaustausch zu Business und Management stattfindet. Er hat ein technisches Verständnis und ermittelt durch Auswertung den Mehrwert der API, welcher direkten Einfluss auf die Businessziele hat. Werden mehrere APIs über eine Organisation entwickelt, sollte nicht einfach das Team vergrössert, sondern die Anzahl an API-Teams erhöht werden (Gartner, 2021). Dabei entsteht ein zusätzliches Team, das API-Platform-Team, welches für die API-Strategie zuständig ist und produktübergreifende Standards definiert: Abbildung 2: API Platform Team, eigene Darstellung adaptiert von (Gartner, 2021) Seite 10 von 70
Hochschule Luzern Department Informatik 2.2 Die drei Säulen einer erfolgreichen API-Strategie Ein erfolgreiches API-Produkt wird durch eine ausgereifte API-Strategie getrieben. Nebst dem Product Mindset stellen für (Apigee, 2018) drei Punkte die wichtigsten Säulen einer API-Strategie dar: Eine erfolgreiche Strategie setzt den Kundenfokus an vorderster Stelle und deckt durch eine Outside-in-Vorgehensweise die Kundenbedürfnisse optimal ab. Durch MVPs soll eine niedrige Time-to-Market erreicht werden und das Produkt soll durch ständiges Feedback Sammeln und Lernen in Iterationen fortlaufend weiterentwickelt werden. 2.2.1 Outside-in-Ansatz Der Outside-in-Ansatz stellt die Kunden ins Zentrum. Die API-Strategie wird von Daten und nicht von internen Annahmen getrieben. Dadurch werden gezielt Kundenbedürfnisse erfüllt, da die zu lösenden Paint Points der Kunden schon identifiziert wurden. So wird gezielt daraufhin gearbeitet, diese Kundenprobleme zu lösen – immer mit der Benutzerfreundlichkeit im Fokus. Das Gegenteil wäre ein Inside-out-Ansatz. Dieser wird von der Überzeugung geleitet, dass die inneren Stärken und Fähigkeiten eines Unternehmens zum Erfolg des Produktes führen (Ozeritskaya, 2015). Häufig wird dabei auf bereits verfügbare IT-Ressourcen zurückgegriffen oder es werden Annahmen über Kundenverhalten und -bedürfnisse getroffen. Abbildung 3: Inside-out vs. Outside-in, eigene Darstellung adaptiert von (Halldórsson, 2018) Vergleicht man die beiden Ansätze, liegt der wesentliche Unterschied bei der Abstrahierung der internen Systemlandschaft. Da diese grundsätzlich für einen Kunden nicht relevant sind, fokussiert sich der Outside-in-Ansatz also auf die Kundenbedürfnisse. «Oft neigen wir dazu, unsere Daten zu nehmen und sie unseren Partnern oder Kunden zur Verfügung zu stellen. Im einfachsten Fall ist dieser Ansatz kaum mehr als ein RESTful 6-Wrapper für bestehende Datenbanktabellen. Das Problem ist, dass dies schnell zu APIs führen kann, die geschwätzig (zu viele API-Aufrufe für ein einfaches Ergebnis), aufgebläht (übermäßige Datenmenge) oder verwirrend (erfordert Insiderwissen über ihre Geschäftslogik) sind. Bei einem Outside-in-Paradigma wird das API-Design auf die Anwendungsfälle der Verbraucher ausgelegt und nicht auf die Struktur der Daten im eigenen System» (jeofoyster, 2017). 6 https://en.wikipedia.org/wiki/Representational_state_transfer Seite 11 von 70
Hochschule Luzern Department Informatik Die beste Art dem Risiko eines Inside-out-Mindsets entgegenzuwirken, sei, direkt mit Kunden zu sprechen (Olsen, 2015). Durch die Aufnahme der Kundenbedürfnisse können klare Probleme identifiziert und beschrieben werden. Anschliessend formulieren Product Teams ihre Hypothesen und bitten um Kundenfeedback zu frühen Designideen, um diese zu validieren. 2.2.2 Time to Market Als zweite Säule steht die Entwicklung von Minimum Viable Products (MVPs 7), um die Zeit bis zur Markteinführung zu reduzieren (Apigee, 2018). Anschliessend kann das Produkt weiterentwickelt werden, sobald weiteres Kundenfeedback eintrifft. Es soll nicht das Ziel sein, ein ganzes Produkt zu designen und zu entwickeln, welches die kompletten Businessnutzen von Beginn weg abdeckt. Dies würde zu lange dauern und ein zu hohes Risiko darstellen (Olsen, 2015). Oft ist es so, dass der komplette Nutzen eines Produktes zu Beginn gar noch nicht erkennbar ist und neue Use Cases erst zu einem späteren Zeitpunkt folgen. Diese Vorgehensweise ermöglicht es Unternehmen, mit mehreren Ideen zu experimentieren und anschliessend, sobald erste Daten vorhanden sind, die vielversprechenden Bereiche der API weiter auszubauen und andere vielleicht nicht weiter zu betreiben (Apigee, 2018). Kosteneinsparungen sind ein weiterer Faktor eines MVPs. Man verringert das Risiko, initial etwas «Falsches» zu bauen, was gar nicht den Anforderungen der Kunden entspricht. Würde man von Beginn an das ganze Produkt fertigentwickeln, könnte es sein, dass man grosse Teile des Produktes nochmals neu entwickeln müsste und dadurch viel Zeit und Geld verliert. Ein weiterer Vorteil eines MVPs ist die Validierung der Nachfrage am Markt (Clearbridge Mobile, o. D.). So kann es zwar sein, dass man mit seinem Produkt die richtigen Bedürfnisse stillt, es aber schon einen Konkurrenten gibt, der die Kundebedürfnisse des Marktes bereits abdeckt. Minimum Viable Products sind auch ein guter Zeitpunkt, um über Priorisierung zu sprechen. Schliesslich hat man sich dazu entschieden, nicht alle Features anzubieten und gewisse Bedürfnisse bewusst nicht abzudecken. Wie aber kann die Entscheidung getroffen werden, welches die richtigen Funktionalitäten für den MVP sind und welche zu einem späteren Zeitpunkt umgesetzt werden sollen? Ein Ansatz wäre, die aufgenommen Kundenbedürfnisse in konkrete Features aufzuteilen. Diese könnten dann nach dem Mehrwert, den sie für den Kunden generieren, entsprechend priorisiert werden. Dieser Schritt mache zwar Sinn, sollte jedoch gemäss in einem zweiten Durchgang auch der Aufwand berücksichtigt werden (Olsen, 2015). Bis anhin wurde nur der Mehrwert für die Kunden berücksichtigt, nicht jedoch den Entwicklungsaufwand für die einzelnen Features. Dieser kann durch die Berechnung des Returns on Investments (ROI) miteinbezogen werden. − ä = = Obwohl diese Formel oft für finanzielle Investitionen und mit monetären Beträgen (z. B. CHF) verwendet wird, kann sie auch für die Produktentwicklung eingesetzt werden. Dort wird die Investition nicht in Geld angegeben, sondern in Entwickleraufwand in Tagen oder Wochen. Die Rentabilität wird als generierten Mehrwert angegeben. Durch die Eingabe dieser Werte kann so der ROI pro Feature oder Idee berechnet werden und kann anschliessend für die Priorisierung verwendet werden. Eine reine Priorisierung nach ROI macht aber eher wenig Sinn, da die Kunden einen gewissen Funktionsumfang im MVP erwarten. Es kann sein, dass dabei einige Features mit niedrigem ROI vorkommen. Diese Berechnung dient also als Unterstützung und nicht als strikte Vorgabe für eine Priorisierung. 7 https://en.wikipedia.org/wiki/Minimum_viable_product Seite 12 von 70
Hochschule Luzern Department Informatik 2.2.3 Iterative Weiterentwicklung In der dritten Säule der API-Strategie wird die Weiterentwicklung des API-Produkts durch Iterationen beschrieben (Apigee, 2018). Damit ist gemeint, dass das Produkt ständig den gleichen Prozess durchläuft. Es werden neue Hypothesen aufgestellt, neue Designs erstellt, User-Tests durchgeführt und daraus Schlüsse gezogen. Abbildung 4: Iterative and Incremental development model, Source: (Kakarla, 2019) 2.3 KPIs definieren und etablieren In Kapitel 2.1.1 haben wir uns gewissen Fragen gestellt. Die API soll ein Business-Ziel erreichen. Die API soll ein Problem lösen. Wie erkennen wir aber nun, ob wir unsere Ziele erreicht haben und ob die API wirklich ein Problem gelöst hat? Genau hier kommen Key Performance Indicators (KPIs) oder Leistungskennzahlen zum Zug. Diese helfen uns, anhand von Daten zu messen, ob unser Produkt erfolgreich ist oder nicht. Gemäss (APImetrics, 2021) hat die Definition von KPIs eine grosse Auswirkung auf das Produkt, die Benutzer und Partner. Was könnten aber potenzielle API KPIs darstellen? Hergeleitet werden nachfolgend einige davon beschrieben (Moesif, 2021): Uptime Die Uptime ist sicher eine der grundlegendsten Metriken. Sie beschreibt, wie erreichbar oder verfügbar ein Service ist. Es wird gemessen, wie viele Stunden oder Tage ein Service pro Jahr ausgefallen ist. Hat eine API eine Uptime von 99%, so war sie während einem Jahr für 3.65 Tage nicht verfügbar. Eine höhere Uptime von 99.9% würde nur noch einen Ausfall von 8.8 Stunden pro Jahr erlauben. Populäre APIs wie zum Beispiel die Google Maps API oder die Google Search API erreichen sogar regelmässig eine Uptime von 100% (TechCrunch, 2011). LMAX Digital, ein führender Institutional Crypto Currency Exchange, hat bei institutionellen Marktteilnehmern eine Umfrage durchgeführt. Auf die Frage, welches die drei wichtigsten Faktoren bei der Auswahl eines Handelspartners für Kryptowährungen seien, antworteten knapp 70% mit «Verlässlichkeit der Technologie wie z. B. Verfügbarkeit» (Arcane Research, 2021). Es war die häufigste Antwort von allen, was zeigt, dass eine hohe Uptime eine wichtige Komponente des Produktes sein sollte. Anzahl von Requests / Benutzung Zu wissen, wie häufig eine API verwendet wird, ist ebenfalls eine grundlegende Metrik. Anhand dieser Zahl können viele weitere Produktbereiche verbessert werden. Liegt die Benutzung unter den Erwartungen, könnte es einen spezifischen Grund dafür geben. Ist die Funktionsweise nicht Seite 13 von 70
Hochschule Luzern Department Informatik genügend beschrieben? Ist die Performance nicht gut genug und Kunden meiden deswegen die Nutzung der API? Auch im Fall einer häufigen Nutzung hilft die Anzahl der Requests, Entscheidungen zu treffen. Steigt die Zahl stetig an, muss irgendwann das Thema Skalierung in Betracht bezogen werden. So können Ausfälle oder Performance-Einbussen frühzeitig vermieden werden. Fehlerhafte Requests Nicht nur die Anzahl der Requests, sondern auch die fehlerhaften Requests sind zu beachten. Dies erlaubt eine Analyse der verschiedenen Funktionalitäten der API. Es kann gemessen werden, ob immer die gleichen Endpoints fehlschlagen. So können Fehler identifiziert und behoben werden. Auch kann gemessen werden, ob die Fehler auf der Nutzer- oder Anbieterseite liegen. Treten häufig Nutzerfehler am gleichen Ort auf, könnte dies ein Indikator für eine ungenügende Dokumentation oder Inkonsistenz der Datentypen oder Schemas sein. In diesem Fall müsste vielleicht das Design der API überdacht werden. Umsatzvolumen über API Ein wichtiger Indikator für die Erreichung der Business-Ziele ist die Messung des Umsatzvolumens über die API. Da jede API gewisse Business-Ziele verfolgt und angenommen wird, dass eines davon die Umsatzsteigerung ist, ist diese Metrik essenziell. Rückwirkend kann gemessen werden, ob das Produkt die gewünschten Ziele erreicht hat oder nicht. Dies kann eine hilfreiche Stütze sein, um das Produkt zu verbessern. Konnten die Ziele nicht erreicht werden, sollten in weiteren Iterationen neue Massnahmen definiert werden. Auch kann diese Messung für Entscheidungen verwendet werden, um zum Beispiel bestimmte Bereiche der API nicht mehr weiterzuentwickeln. Der beste Kunde Zu wissen, welches der beste Kunde ist, bringt viele Vorteile mit sich. Dabei geht es nicht nur darum, wer die API am häufigsten nutzt, sondern auch mit welchem Kunden man am meisten Umsatz generiert. Dies ermöglicht einem die Priorisierung der Weiterentwicklung. Vielnutzer der API können eine Quelle von wertvollem Feedback und Verbesserungsvorschlägen sein. Auch kann dadurch ein besonderer Fokus auf den Support für die wichtigsten Kunden gelegt werden. API-Calls pro Business-Transaktion Diese Zahl beschreibt, wie häufig ein Kunde verschiedene Endpoints aufrufen muss, bis er eine Business-Transaktion tätigen kann. Diese Metrik widerspiegelt also direkt das Design der API. Wenn Kunden immer viele verschiedene Aufrufe tätigen müssen, um die nötigen Daten zu aggregieren, könnte dies auf ungeeignete Endpoints hinweisen. Schlussendlich sollten die Endpoints so designt sein, dass der Kunde möglichst schnell sein Ziel erreicht. Daher sollten die API-Calls pro Business-Transaktion möglichst tief sein. CPU- und Speichernutzung Diese Metrik hat eine direkte Korrelation mit der Metrik #2 und ist einer der wichtigsten Angaben in Bezug auf die Performance der API. Gibt es keine oder nur wenige Requests, ist auch die CPU- und Speichernutzung tief. Ist die Nutzung jedoch ständig am Limit, kann dies ein Hinweis auf Überlastung sein und die Ressourcen müssen nach oben skaliert werden. Auch kann ständige Überlastung auf Applikationsfehler hindeuten, wo Endlosschleifen oder andere rechenintensive Fehler auftreten. Diese beiden Daten sollten also in ein Monitoring aufgenommen werden und bei entsprechendem Überschreiten eines Schwellenwertes einen Alarm auslösen. So können Ausfälle vorzeitig vermieden werden. User & Developer Experience Die höchste Uptime und das beste Design nützen nur wenig, wenn die Benutzerfreundlichkeit der API ungenügend ist. Eine spannende Metrik in diesem Bereich ist durchschnittliche Antwortzeit von Requests. Eine tiefe Latenz und schnelle Verarbeitungszeiten sind eine der wichtigsten Seite 14 von 70
Hochschule Luzern Department Informatik Kundenbedürfnisse, wenn es sich um Finanztransaktionen handelt (Arcane Research, 2021). Wenn bestimmte Endpoints ständig hohe Antwortzeiten aufweisen, kann dies an schlechter Netzwerkinfrastruktur oder an ungünstigem API-Design liegen. Deshalb sollte ein Fokus auf Performance gelegt werden und man sollte sich schon zu Beginn darüber Gedanken machen. Eine zweite spannende Metrik bei der Benutzerfreundlichkeit ist die «Time To First Hello World (TTFHW)». Sie gibt an, wie lange es dauert, bis ein Entwickler einen ersten Prototypen erstellt hat, vom Zeitpunkt der Entdeckung der API. Idealerweise sollte diese Spanne so kurz wie möglich sein und auf folgende Schritte des Entwicklers sollte geachtet werden: 1. Registrierung um API nutzen können 2. Dokumentation lesen 3. Funktionsbeispiele der API einsehen 4. Erste Aufrufe mit der API tätigen Je schneller also diese Schritte durchlaufen werden können, desto besser ist das Nutzererlebnis und es wird die Wahrscheinlichkeit einer späteren Nutzung gesteigert. 2.4 Security Sobald man beginnt, externe APIs anzubieten, ist Security eines der wichtigsten Themen einer API- Strategie überhaupt. Aus dem jährlichen Report «State of the Internet» von (Akamai, 2020) ist zu entnehmen, dass ein wachsender Trend entsteht, wo Cyberkriminelle öffentliche API-Plattformen von Finanzdienstleistungen ins Visier nehmen. Von Dezember 2017 bis November 2019 beobachtete Akamai 85,42 Milliarden Credential Stuffing Attacks 8. Fast 20 %, also 16.55 Milliarden, richteten sich gegen Hostnamen, die eindeutig als API-Endpunkte identifiziert wurden. Davon waren 473.5 Millionen Angriffe auf Organisationen in der Finanzdienstleistungsbranche. Diese wachsende Bedrohung spiegelt sich auch bei den Anforderungen für eine API-Integration wider. Eine Umfrage von (Postman, 2021) zeigt auf, dass Security der wichtigste Faktor bei eine API-Integration ist. Gleichauf mit Performance haben mehr als 2/3 der Befragten diese zwei Punkte als die wichtigsten angegeben: Abbildung 5: Berücksichtigte Faktoren bei API-Integration, Source: (Postman, 2021) Umso essenzieller ist es also, die API-Security schon von zu Beginn an als eine der wichtigsten Komponenten zu betrachten. 8 https://en.wikipedia.org/wiki/Credential_stuffing Seite 15 von 70
Hochschule Luzern Department Informatik 2.4.1 Häufige Sicherheitslücken und Schwachstellen (OWASP, 2019) hat eine Top 10 der häufigsten Sicherheitslücken veröffentlicht: • API1:2019 Broken Object Level Authorization API-Endpoints ermöglichen den Zugriff auf Ressourcen oder Objekte mit eindeutigen Identifikatoren. Diese Ressourcen sollten mit der entsprechenden Authentifizierung geschützt sein, dass auch nur die berechtigten Benutzer Zugriff darauf haben. • API2:2019 Broken User Authentication Die Endpoints für die Authentifizierung müssen besonders behandelt werden, da sie allen zur Verfügung stehen. Fehlerhafte Implementation oder fehlende Mechanismen zur Vorbeugung von Credential Stuffing oder Brute Force Attacks können zu grossem Schaden führen. • API3:2019 Excessive Data Exposure Häufig werden zu viele Attribute eines Objektes veröffentlicht. Es sollten nur diejenigen veröffentlicht werden, die vom API-Client wirklich benötigt werden. • API4:2019 Lack of Resources & Rate Limiting Der Zugriff auf die Anzahl der Ressourcen sollte limitiert werden. Ebenso die Anzahl der Aufrufe, die gemacht werden können. Ansonsten könnte dies zu einer Denial of Service (DoS) führen. • API5:2019 Broken Function Level Authorization Obwohl ein Benutzer authentifiziert ist, sollte er auch nur die Aktionen ausführen dürfen, die seiner Rolle gerecht werden. Normale Benutzer dürfen keine Admin-Funktionen durchführen. Auch das Ausführen von sensitiven Aktionen wie einem DELETE sollte nicht durch das einfache Austauschen eines HTTP Verbs von GET auf DELETE möglich sein. • API6:2019 Mass Assignment Werden vom API-Client gelieferte Daten (z. B JSON) automatisch auf Datenmodelle gemappt, ohne diese zu validieren, kann ein Mass Assignment entstehen. Daher sollten alle Daten zuerst nach den gewünschten Attributen validiert werden. • API7:2019 Security Misconfiguration Fehlerhafte Konfiguration entsteht häufig durch die Übernahme von unsicheren Standardeinstellungen, falsche HTTP-Headers, unnötige HTTP-Methoden, fehlende Unterbindung von CORS oder Fehlermeldungen mit sensitiven Daten. • API8:2019 Injection Diese Fehler, wie z. B. SQL-Injection treten dann auf, wenn nicht vertrauenswürdige Daten an den Interpreter geschickt und damit ausgehebelt werden. Dadurch können unerlaubte Aktionen ausgeführt werden. • API9:2019 Improper Assets Management APIs tendieren mehr Endpoints zu veröffentlichen als normale Webapplikation. Daher ist eine genau und aktuelle Dokumentation sehr wichtig. API-Versionierung tragen auch dazu bei, dass keine Probleme bei veralteten Endpoints auftreten. • API10:2019 Insufficient Logging & Monitoring Mangelndes Logging oder Monitoring kann dazu führen, dass Schwachstellen oder Angriffe unbemerkt bleiben. Sicherheitsverletzungen werden oft erst nach mehr als 200 Tagen festgestellt und von externen Parteien anstatt von Prozessen aufgedeckt. Seite 16 von 70
Hochschule Luzern Department Informatik 2.4.2 Best Practises für API-Security Um obenstehende oder andere Sicherheitslücken und Schwachstellen zu vermeiden, gibt es einige Best Practises in Bezug auf API-Security. 2.4.2.1 Rate Limiting DoS-Attacken oder fehlerhafte Clients der API können zu Ausfällen führen. Werden Cloud-Provider wie Azure, AWS oder Cloudflare verwendet, erhält man einen Schutz vor DoS-Attacken schon von Haus aus. Trotzdem macht es jedoch Sinn, die Anzahl an erlaubten Requests zu limitieren, um die Performance der API zu schützen (RedHat, 2019). Eine entsprechende Implementation ist dabei gar nicht so aufwändig. Es gibt entsprechende Libraries, wie z. B. AspNetCoreRateLimit 9 für das .NET Framework, die das Schützen von Endpoints erlauben. Ein Beispiel ist dem Anhang zu entnehmen. 2.4.2.2 API-Gateway Ein API-Gateway fungiert als Zwischenstufe zwischen den API-Clients und den verschiedenen Backend-APIs. Dabei wird der ganze Traffic über den API-Gateway geroutet und ist damit der einzige Einstiegspunkt. Dies hat den Vorteil, dass nicht alle Endpoints der verschiedenen Backend- APIs exponiert werden müssen, sondern können in einer einheitlichen Form gegen aussen präsentiert werden. Die Requests werden dann an den entsprechenden Service weitergeleitet. In diesem Fall verhält sich der API-Gateway als Proxy für die darunterliegenden Services. Abbildung 6: API Gateway, der Requests an Services weiterleitet, eigene Darstellung Als zentrale Schnittstelle gegen aussen übernimmt der API-Gateway noch weitere Aufgaben: So kann ein API-Gateway auch für die Authentifizierung eingesetzt werden (Thomas Bush, 2019). Damit müssen sich Clients, die Daten von verschiedenen Services beziehen, nur einmal authentifizieren. Zusätzlich wird sichergestellt, dass über alle Services der gleiche Authentifizierungsstandard verwendet wird. Eine weitere Funktion des API Gateway kann auch die Validierung des Inputs sein. So wird bei einem API-Aufruf überprüft, ob der Request alle nötigen Informationen liefert und das richtige Format einhaltet. Dies bevor der eigentliche Service die Daten erhält und versucht sie zu verarbeiten. Da der API-Gateway die zentrale Eintrittsstelle darstellt, ist er optimal geeignet, gewisse Metriken zu sammeln. Es kann gesammelt werden, welcher Benutzer wie viele Requests und an welche Services absendet. Dadurch kann die Datenerhebung für einige KPIs von Kapitel 2.3 abgedeckt werden. 9 https://github.com/stefanprodan/AspNetCoreRateLimit Seite 17 von 70
Hochschule Luzern Department Informatik Trotz vielen Vorteilen bringt die Verwendung eines API-Gateways auch einige Nachteile mit sich: Dadurch, dass der API-Gateway der zentrale Einstiegspunkt darstellt, ist er auch ein Single Point of Failure10. Es entsteht eine Lernkurve, bis hochverfügbare APIs zur Verfügung stehen. Die Konfigurierung der einzelnen APIs, bis sie sauber in den API Gateway integriert sind, bringt zusätzliche Komplexität mit und bedeutet mehr Aufwand für die Entwickler bei der Orchestrierung (Dashbird, o. D.). 2.4.2.3 Verschlüsslung Ein weiterer essenzieller Teil der API-Security ist die Verschlüsslung. Sämtlicher Austausch zwischen internen und externen Services sollte mittels TSL11 verschlüsselt werden (Debbie Walkowski, 2020). TLS-Verschlüsslung wird HTTP unterstützt und kann somit bei allen REST APIs eingesetzt werden. Durch diese Massnahme ist es einem Angreifer nicht möglich, die abgefangenen Daten von einem Request zu lesen oder zu manipulieren. Zur Entschlüsselung wird nämlich die richtige Signatur benötigt, die nur der Client kennt. 2.5 Authentifizierung und Autorisierung Oft werden Authentifizierung und Autorisierung einander gleichgestellt, obwohl sie eine unterschiedliche Bedeutung haben. Die beiden Begriffe beantworten unterschiedliche Fragestellungen: 1. Welcher Nutzer benutzt die API? (Authentifizierung) 2. Welche Rechte hat der Nutzer der API? (Autorisierung) Bei der Authentifizierung wird überprüft, welcher API-Client einen Aufruf tätigt und ob es sich dabei auch wirklich um diesen Client hält. Bei der Autorisierung wird geprüft, welche Rechte der API-Client besitzt und ob diese für die Ausführung der angefragten Aktion auch ausreichen. Um solche Authentifizierungs- und Autorisierungsflows umzusetzen, gibt es viele verschiedene Methoden und Frameworks. Einige der gängigsten werden nachfolgend beschrieben. 2.5.1 OAuth 2.0 mit OpenID Connect Im RFC 674912 wird OAuth 2.0 als Autorisierungs-Framework beschrieben, welches es einem Benutzer ermöglicht, einer Website oder Anwendung eine Drittanbieters Zugriff auf seine geschützten Ressourcen zu gewähren, ohne dass er dabei seine Anmeldedaten oder sogar seine Identität preisgeben muss. Im Alltag wird dieses Protokoll oft mit Aktionen wie «Sign in with Google» oder «Sign in with Apple» verwendet. Die Trennung zwischen Authorization- und Resource-Server ist dabei einer der grössten Vorteile. Nachstehende Grafik veranschaulicht den Ablauf mittels OAuth 2.0. 10 https://en.wikipedia.org/wiki/Single_point_of_failure 11 https://en.wikipedia.org/wiki/Transport_Layer_Security 12 https://datatracker.ietf.org/doc/html/rfc6749 Seite 18 von 70
Hochschule Luzern Department Informatik Abbildung 7: OAuth 2.0 Flow, Source: (Oracle, 2018) Als Ergänzung zu diesem Autorisierungs-Flow bildet OpenID Connect (OIDC) eine zusätzliche Authentifizierungsschicht, die auf dem OAuth 2.0 Framework aufbaut. Es verifiziert Nutzer, indem es grundlegende Profilinformationen erhält und diese bei einem Authentifizierungsserver überprüft (OpenID Foundation, 2021). 2.5.2 Basic Authentication Basic Authentication kommt einer klassischen Authentifizierung mittels Username und Passwort am nächsten. Es ist Teil des HTTP-Protokolls und zählt zu den einfachsten Authentifizierung- Schemas. Der API-Client sendet dabei einen HTTP-Header «Authorization» mittels kodiertem Username und Passwort bei jedem Request mit. Da diese Kodierung (base64) sehr einfach dekodierbar ist, sollte Basic Authentication immer nur in Kombination mit HTTPS/SSL verwendet werden (Swagger, 2021). Ansonsten könnten Username und Passwort abgegriffen werden. 2.5.3 Bearer Authentication Bearer Authentication ist ein HTTP-Authentifizierungsschema, welches Sicherheits-Tokens namens Bearer Tokens verwendet (Swagger, 2021). Der Bearer Token ist ein String, der vom Server nach einem Login-Request generiert wird. Wie bei Basic Authentication, wird dieser Token bei jedem Request in dem «Authorization»-Header mitgeschickt. Bearer Authentication ist als Teil von OAuth 2.0 entstanden und wird in RFC 6750 13 beschrieben. Bearer Authentication besitzt den gleichen Nachteil wie Basic Authentication, indem es nur in Kombination mit HTTPS/SSL verwendet werden sollte. Der String/Token ist nicht verschlüsselt und enthält sensitive Informationen. 13 https://datatracker.ietf.org/doc/html/rfc6750 Seite 19 von 70
Sie können auch lesen
