Querschnittsaspekte wie die Authentifizierung und Autorisierung von Nutzern stellen Entwickler von Microservices vor neue Herausforderungen. Wie wird sichergestellt, dass nur berechtigte Personen Zugriff auf die Microservices haben? Dezentrale Implementierungen in jedem Microservice sind nicht sinnvoll. Also muss eine zentrale Instanz diese übergreifende Aufgabe erledigen.
Deiche für die Inseln
Microservices-Architekturen bestehen aus vielen kleinen Service-Inseln, die jeweils spezifische fachliche Anforderungen umsetzen. Querschnittsanforderungen u.a. auch Security-Aspekte, scheinen da nicht richtig reinzupassen. Bei genauerer Betrachtung dieser Anforderungen kommen verschiedene Fragen auf: Soll jeder einzelne Microservice jeden Aufrufer, sei es ein Anwender oder ein anderer Microservice, authentifizieren, d. h. den Nachweis der Identität überprüfen? Wer prüft eigentlich die Berechtigung (Autorisierung) des Aufrufers, der auf eine Ressource zugreift? Wo werden die Berechtigungen verwaltet? Wenn jeder Microservice selbst Authentifizierung und Autorisierung umsetzt, könnte schnell ein Chaos entstehen. Viele verschiedene Implementierungen zur Authentifizierung steigern den Entwicklungsaufwand und den Testaufwand. Ein nachträglicher Wechsel des Authentifizierungsverfahrens z. B. von einer anwendungsinternen Benutzerdatenbank auf eine Active Directory-Anbindung wirkt sich auf die gesamte Microservices-Landschaft aus. Sicherheitsprobleme sind aufgrund der vielen Implementierungen von Authentifizierung und Autorisierung vorprogrammiert.Beispiel-Szenario
Wie Authentifizierung und Autorisierung in einer Microservices-Architektur umgesetzt werden können, wird in dieser Blogpost-Serie am Beispiel einer Webshop-Anwendung gezeigt. Der Webshop teilt sich im Wesentlichen in einen öffentlich zugänglichen Bereich und einen abgesicherten Bereich auf. Im öffentlichen Bereich sucht der Benutzer nach Produkten und liest die Bewertungen zu diesen Produkten. Die Microservices, die nur nach vorheriger Authentifizierung und Autorisierung zugänglich sind, bieten Dienste rund um Kunden, Aufträge, Produkte und Bewertungen.Zusammenhang der Microservices
Die Architektur des Webshops sieht vier Microservices vor, die über ein API Gateway von außen zugänglich sind (siehe Abb. 1). Das Muster des API Gateways wird in Microservices-Architekturen häufig verwendet, um z. B. unterschiedlichen Clients (mobile App oder Desktop-Anwendungen) passende APIs zur Verfügung zu stellen. Zudem ist es der einzige Eintrittspunkt in die Microservices-Architektur von extern. Das Einkaufssystem ruft den "Produktservice" über das API Gateway zur Bestandsaktualisierung auf. Als User Agent kommt eine Single Page Application (SPA) zum Einsatz.
Abb. 1 Architektur des Webshops
Eingesetzter Technologie-Stack
Die technische Umsetzung dieser Architektur basiert auf dem Spring-Framework. Zur Unterstützung bei der Authentifizierung und Autorisierung wird ein eigener OAuth 2.0-Server betrieben. Auch wenn OAuth 2.0 (nachfolgend kurz OAuth genannt) primär zur Delegation von Berechtigungen gedacht ist, lassen sich darüber Benutzer authentifizieren und deren Autorisation überprüfen. Die Microservices benötigen zur Überprüfung der Authentifizierung und Autorisierung ebenfalls OAuth-Mechanismen. Sowohl der OAuth-Server als auch die Microservices verwenden dafür jeweils das "spring-security-oauth2-autoconfigure" Paket. Als API Gateway kommt Zuul von Netflix zum Einsatz ("spring-cloud-starter-netflix-zuul").Listing 1 zeigt das grundlegende Dependency-Management der in diesem Blogpost verwendeten Bibliotheken für Maven. Dabei wird das Dependency-Management von Spring Boot über die Parent-Beziehung importiert. Darüber hinaus werden das Dependency-Management von Spring Cloud importiert sowie die zusätzlichen Dependencies für die OAuth-Implementierung festgelegt.
Listing 1: Dependency-Management der verwendeten Bibliotheken
OAuth 2.0
Was es ist
OAuth 2.0 ist eine Spezifikation eines Frameworks zur Delegation von Zugriffen. Es ermöglicht z. B. einer Person, einem Dienst A Zugriff auf die eigenen Daten bei Dienst B zu gewähren. Dafür vertraut die Person Dienst A weder Benutzername noch Passwort an, sondern stimmt der Nutzung nur zu. Diese Zustimmung kann die Person im Nachhinein entziehen, ohne das eigene Passwort ändern zu müssen. Primär ist OAuth kein Protokoll zur Authentifizierung oder Autorisierung, sondern ein Protokoll zur Delegation von Zugriffen.Akteure
OAuth unterscheidet vier verschiedene Akteure:- Der Resource Owner kann anderen Diensten oder Personen in seinem Namen Zugriff auf die eigenen Daten gewähren. Über den sogenannten Scope kann die Zustimmung auf bestimmte Daten begrenzt sein.
- Auf dem Resource Server liegen die geschützten Daten. Bei einer Anfrage überprüft der Resource Server beim Authorization Server, ob der Resource Owner seine Zustimmung zum Zugriff auf die Daten gegeben hat. Zudem überprüft der Resource Server, ob der Resource-Owner-Vertreter überhaupt autorisiert ist, auf die Daten zuzugreifen.
- Der Client greift im Namen des Resource Owner auf die Daten des Resource Servers zu.
- Der Authorization Server stellt dem Client nach der Zustimmung durch den Resource Owner ein Token zum Zugriff auf den Resource Server aus. Der Resource Server fragt zudem beim Authorization Server nach, ob der Resource Owner überhaupt berechtigt ist, auf die Resource zuzugreifen.
Token
Damit ein Resource Owner einem Client die Zustimmung, in seinem Namen zu agieren, aussprechen kann, werden gemäß OAuth-Protokoll verschiedene Token erstellt und ausgetauscht. Die Token dienen als Berechtigungsnachweis. Folgende Token sieht der OAuth-Standard vor:- Ein Access Token wird zum Zugriff auf die Ressource auf dem Resource Server benötigt. Der Resource Server überprüft die Gültigkeit des Access Tokens beim Authorization Server. Nach einer festgelegten Zeit ab Ausstellung ist ein Access Token nicht mehr gültig.
- Ein Refresh Token kann vom Client genutzt werden, um für ein abgelaufenes Access Token ein neues Access Token vom Authorization Server zu erhalten.
Authorization Grants
OAuth sieht die folgenden vier Authorization Grants vor, die die unterschiedlichen Abläufe repräsentieren, wie ein Client ein Access Token vom Authorization Server erlangt.- Beim Einsatz eines Authorization Code authentifiziert sich der Resource Owner am Authorization Server und stimmt der angefragten Berechtigung (Scope) durch den Client zu. Über den User Agent wird ein Authorization Code an den Client geschickt. Der Client selbst authentifiziert sich dann mit seinen eigenen Credentials gegenüber dem Authorization Server und fragt für den Authorization Code ein Access Token ab.
- Der Implicit Grant bietet einen vereinfachten Ablauf für Browser-basierte Clients, wie z.B. Single Page Applications. Eine Authentifizierung des Clients gegenüber dem Authorization Server ist nicht vorgesehen, da Authentifizierungsdaten im Client nicht sicher aufbewahrt werden können. Der Einsatz eines Authorization Code bietet deshalb keinen Vorteil, sodass der Client nach erfolgreicher Authentifizierung und Zustimmung des Resource Owner (Benutzer) ein Access Token direkt erhält.
- Für die Verwendung des Resource Owner Password Credential Grant muss ein Vertrauensverhältnis zwischen Resource Owner und Client bestehen. Der Client erhält dabei vom Resource Owner Benutzername und Passwort, um sich am Authorization Server anzumelden und direkt ein Access Token abzufragen. Den Scope, d. h. den Umfang der Berechtigungen, kann der Client dabei selbst wählen.
- Der Client Credential Grant-Typ wird verwendet, wenn der Client im eigenen Namen agiert. In diesem Fall ist der Client selbst Resource Owner.
Realisierung der Authentifizierung
Einsatz eines API Gateways
Bevor die Autorisierung der Anfrage eines Benutzers geprüft werden kann, muss sich der Benutzer authentifizieren. Die Authentifizierung in jedem Microservice zu implementieren, führt jedoch zu den anfangs genannten Problemen. Besser ist es deshalb, dies an zentraler Stelle im API Gateway zu erledigen.Alle Anfragen an die Microservices erfolgen dabei durch das vorgeschaltete API Gateway. Dadurch kann die Authentifizierung zentral am API Gateway erfolgen. Eine Implementierung der Authentifizierung in den einzelnen Microservices ist somit nicht notwendig. Somit wird nicht nur der Entwicklungsaufwand reduziert, vielmehr wird die Implementierung der einzelnen Microservices auf die jeweilige Fachlichkeit fokussiert. Darüber hinaus kann die Authentifizierung bei Bedarf später an zentraler Stelle erweitert oder gegen andere Verfahren ausgetauscht werden.
Die Realisierung im gewählten Technologie-Stack erfolgt über die Spring-Integration von Netflix Zuul: Spring Cloud Netflix.
Spring Cloud Netflix ZUUL vs. Spring Cloud Gateway
Die Integration von Netflix ZUUL in Spring Cloud in Form des Moduls spring-cloud-netflix-zuul ist mit Erscheinen des Greenwich-Releases von Spring Cloud im Wartungsmodus und erhält damit keine Weiterentwicklung im Sinne neuer Features. Kritische Fehler, Sicherheitsfehler und kleinere Pull-Requests werden im Rahmen des Wartungsmodus weiterhin bearbeitet. Dieser Support soll für mindestens ein Jahr ab Release-Datum fortgesetzt werden. Als Ersatz gibt es das neue Projekt Spring Cloud Gateway, welches auf dem Projekt Reactor aufsetzt. Die vorgestellten Konzepte sind jedoch auch auf andere API Gateways wie Spring Gateway übertragbar.Die notwendigen Spring-Abhängigkeiten für das API Gateway sind in Listing 2 dargestellt.
Listing 2: Maven-Dependencies des API Gateways
Um Zuul als Proxy für eingehende Requests zu verwenden, ist lediglich die Annotation @EnableZuulProxy notwendig:
Listing 3: Aktivieren des ZUUL Proxy via Spring-Annotation
Die eigentliche Konfiguration von Zuul erfolgt über die reguläre Spring-Konfiguration. Listing 4 zeigt diese Konfiguration. Im gegebenen Beispiel wird eine Route mit der Identifikation product festgelegt. Dabei werden alle Anfragen, welche mit /product beginnen, auf die URL https://localhost:8002 weitergeleitet. Eine Anfrage am API Gateway für https://localhost:8000/product/search wird vom API Gateway somit intern an https://localhost:8002/search weitergeleitet.
Listing 4: Konfiguration des API Gateways
Service Discovery
Im hier dargestellten Beispiel erfolgt die Konfiguration der Ziel-URL statisch. Im praktischen Einsatz kann es sinnvoll sein, die Ziel-URLs durch eine Service-Discovery zu ermitteln. Dabei registrieren sich alle relevanten Services mit ihrer URL unter einer Service-Identifikation an der Service-Discovery. Am API Gateway wird dann nicht die konkrete Ziel-URL, sondern lediglich die gewünschte Service-Identifikation konfiguriert. Die Ziel-URL wird vom API Gateway bei Bedarf an der Service-Discovery mit der konfigurierten Service-Identifikation ermittelt. Im Kontext von Spring Cloud Netflix würde Eureka als Service-Discovery infrage kommen. Da die Verwendung einer Service-Discovery jedoch nicht im Fokus dieses Blogposts liegt, wurde auf deren Verwendung für dieses Beispiel verzichtet.
Verwendeter Grant-Type
Die Auswahl des geeigneten Authorization Grant-Typen hängt wesentlich von den Rahmenbedingungen der Anwendung und der Microservices-Architektur ab. Die Beispielanwendung Webshop sieht keine Einbindung externer Daten (z. B. von Google) vor. Benutzernamen, Passwörter und Berechtigungen werden in der geschlossenen Microservices-Architektur selbst verwaltet. Dafür kommt ein eigener OAuth-Server zum Einsatz. OAuth wird nur zwischen den Microservices, dem API Gateway und dem OAuth-Server verwendet. Nach außen bietet das API Gateway eine Schnittstelle an, die auch von Clients verwendet werden kann, die das OAuth-Protokoll nicht unterstützen. Unter diesen Rahmenbedingungen erfolgt die Bewertung der infrage kommenden Authorization Grants.
Der Authorization Code Grant und auch der Implicit Grant bieten den Vorteil, dass der Benutzer (Resource Owner) dem API Gateway seinen Benutzernamen und das Passwort nicht anvertrauen muss. Der Benutzer wird vom API Gateway zur Authentifizierung auf den OAuth-Server umgeleitet. Dieser kann das Authentifizierungsverfahren beliebig erweitern und neben Benutzernamen und Passwort z. B. auch eine Zweifaktorauthentifizierung erfordern. Die Restriktion, dass der OAuth Flow vom User Agent des Benutzers nicht unterstützt werden muss, hält dieser Grant-Typ nicht ein. Zudem liegt der Authorization Code bzw. das Access Token im User Agent vor, wodurch beachtenswerte Risiken entstehen (vgl. OAuth 2.0 Threat Model and Security Considerations und Proof Key for Code Exchange by OAuth Public Clients).
Der Grant-Typ Client Credential ist für diesen Kontext nicht geeignet, da bei diesem Grant-Typ nicht im Namen des Benutzers auf die Ressourcen zugegriffen wird. Eine dedizierte Überprüfung der Berechtigungen des Benutzers, welcher auf die API eines Microservice zugreift, kann somit nicht gewährleistet werden.
Der Resource Owner Password Credential Grant bietet im Kontext dieser Beispielanwendung einige Vorteile. Zunächst kann die Verwendung von OAuth vor der Außenwelt versteckt werden. D. h., weder SPA noch Drittsysteme wie das Einkaufssystem müssen OAuth unterstützen. Das API Gateway entkoppelt hier tatsächlich den User Agent von der Microservices-Architektur. Ein Redirect auf die Log-in-Seite des OAuth-Servers ist nicht erforderlich. Nachteilig ist, dass der Benutzer seinen Benutzernamen und sein Passwort dem API Gateway anvertrauen muss. Neutral verhält sich in diesem Szenario der Kontrollverlust des Benutzers über den vom API Gateway (Client) angefragten Scope. Wie später im Blogpost noch erläutert wird, kommt der im OAuth-Protokoll vorgesehene Scope in diesem Beispiel nicht zum Einsatz. Er könnte jedoch bei der Verwendung mehrerer API Gateways eingesetzt werden, um die Autorisierung im Microservice auch vom verwendeten API Gateway abhängig zu machen.
Unter Beachtung aller Vor- und Nachteile eignet sich der Grant-Typ Resource Owner Password Credential für dieses Anwendungsbeispiel am besten. Insbesondere der Aspekt, dass der Benutzer seine Credentials dem API Gateway anvertrauen muss, ist bei diesem Szenario weniger relevant. Würde es sich um eine monolithische Anwendung handeln, würden die Credentials klassisch der monolithischen Anwendung anstelle des API Gateways anvertraut.
Implementierung der Authentifizierung am API Gateway
Die Implementierung der Authentifizierung im API Gateway erfolgt mittels Spring Security. Dabei wird Spring Security für ein klassisches formbased Log-in konfiguriert. Listing 5 zeigt diese Konfiguration.Listing 5: Konfiguration von Spring Security im API Gateway
Aus Sicht der SPA erfolgt somit am API Gateway ein regulärer formbased Log-in, bei dessen Erfolg ein Session-Cookie ausgestellt wird. Erfolgt der Log-in aus der SPA unter Verwendung der Fetch API des Browsers, so kann es sinnvoll sein, nach einem erfolgreichen oder fehlgeschlagenen Log-in keinen Redirect auf eine Folgeseite durch Spring Security zu erhalten. Vielmehr soll in diesen Fällen jeweils lediglich ein passender HTTP Status-Code geliefert werden. Dieser kann in der SPA entsprechend ausgewertet werden. Gleiches gilt auch bei einem erfolgreichen Abmelden.
Neben dieser Konfiguration sollte für einen produktiven Einsatz das Session-Handling sowie ggf. weitere notwendige Aspekte wie z. B. die Verwendung eines CSRF-Tokens konfiguriert werden.
Eine Besonderheit ergibt sich im verwendeten Authentication Provider. Dabei kommt ein eigener Provider zum Einsatz, welcher die übergebenen Credentials in einen Request für den Authorization Server als Resource Owner Password Credential Grant umformt. Die dazu notwendige URL des Authorization Server sowie die Zugangsdaten des API Gateways als OAuth Client werden von einem eigenen Properties-Objekt Oauth2PasswordAuthenticationProperties bereitgestellt.
Der neue Provider implementiert das Spring Security Interface AuthenticationProvider. Durch das formbased Log-in werden diesem Provider die eingegebenen Credentials als UsernamePasswordAuthenticationToken von Spring Security zur Anmeldung übergeben. Damit der Provider für diesen Typ von Authentifizierungs-Information von Spring Security aufgerufen wird, muss die supports-Methode entsprechend implementiert werden. Listing 6 zeigt eine einfache Implementierung des neuen Providers.
Listing 6: Implementierung des Authentication Providers
Die eigentliche Arbeit erfolgt in der Implementierung der authenticate-Methode: Dort werden die über Spring Security zur Authentifizierung entgegengenommenen Benutzer-Credentials via Rest Template als OAuth-Request an den Authorization Server weitergeleitet. Die vom Server gelieferten Datenstrukturen müssen dabei nicht erneut als Klasse in Java implementiert werden. Vielmehr wird hier die mit spring-security-oauth2 gelieferte Datenstruktur OAuth2AccessToken verwendet. Mit dieser Bibliothek sind auch bereits entsprechende Deserializer verfügbar, welche den vom Authorization Server gelieferten JSON Payload in die benötigte Datenstruktur umwandeln. Ist der OAuth-Request erfolgreich, so wird eine OAuth2AccessTokenAuthentication zurückgeliefert und Spring Security damit die erfolgreiche Anmeldung signalisiert. Dabei handelt es sich ebenfalls um eine eigene Implementierung eines AbstractAuthenticationToken, welche das gelieferte OAuth Access Token für eine spätere Verwendung vorhält. Die hier zurückgelieferte Instanz wird von Spring Security in der bei der Anmeldung erstellten Session für eine spätere Verwendung vorgehalten. Listing 7 zeigt eine einfache Implementierung dieses Tokens.
Listing 7: Implementierung der OAuth2AccessTokenAuthenticationListing 8 zeigt einen exemplarischen HTTP-Request, mit welchem sich die SPA am API Gateway anmeldet.
Listing 8: HTTP Login am API Gateway
Durch den oben beschriebenen Authentication Provider würde daraus der in Listing 9 dargestellte HTTP-Request gegen den OAuth Authorization Server. Dabei wird auch deutlich, dass nicht nur die Kommunikation zwischen der SPA und dem API Gateway, sondern ebenfalls die Übertragung zwischen dem API Gateway und dem Authorization Server verschlüsselt erfolgen sollte.
Listing 9: OAuth Request am Authorization Server
Realisierung der Authentifizierung am Authorization Server
Die Authentifizierung am Authorization Server wird durch eine Spring-Implementierung realisiert. Dabei setzt die Implementierung auf Spring Security auf, kann jedoch durch sogenannte AuthorizationServerConfigurerAdapter angepasst werden. Wird der Authorization Server durch die Spring-Annotation @EnableAuthorizationServer aktiviert, so werden die benötigten HTTP Ressourcen automatisch zur Verfügung gestellt. Dabei handelt es sich per Default um die folgenden Pfade:- /oauth/token
- /oauth/check_token
- /oauth/token_key
Die beschriebenen Ressourcen werden automatisch durch Spring Security geschützt. Dazu ist jedoch anzumerken, dass für die bereitgestellten Ressourcen im Hintergrund eine dedizierte Security-Konfiguration erstellt wird. Diese kann auch nicht direkt, sondern nur über den eingangs genannten AuthorizationServerConfigurerAdapter rekonfiguriert werden. Wird zusätzlich eine Spring Security-Konfiguration auf regulärem Weg über einen WebSecurityConfigurerAdapter erstellt, so ist diese unabhängig von der Security-Konfiguration der OAuth-Ressourcen. Eine solche reguläre Konfiguration von Spring Security ist jedoch auch nicht notwendig: Sind eigene Ressourcen auch in diesem Microservice zu schützen, da z. B. die Ressourcen zur Benutzerverwaltung im gleichen Microservice mit abgebildet werden, so nimmt der Microservice neben der Rolle des OAuth Authorization Servers zusätzlich die Rolle eines OAuth Resource Servers ein. Beides kann parallel in einem Microservice konfiguriert werden. Auf die Konfiguration eines OAuth Resource Servers wird später im Blogpost im Kontext der Autorisierung eingegangen. Listing 10 zeigt eine exemplarische Implementierung eines AuthorizationServerConfigurerAdapter zur Konfiguration des OAuth Authorization Servers.
Listing 10: Implementierung der OAuth Authorization Server Konfiguration
In gewissem Umfang kann der Schutz der bereitgestellten Authorization Server Ressourcen durch den AuthorizationServerSecurityConfigurer angepasst werden: So kann z. B. der Zugriffsschutz auf die Ressource zur Prüfung von OAuth Access Token festgelegt werden. In diesem Beispiel benötigt ein OAuth Client das Recht CHECK_AUTH_TOKEN, um einen Token am Authorization Server validieren zu lassen. Dabei ist zu beachten, dass es sich hier um Rechte der OAuth-Clients handelt, welche unabhängig von den Rollen und Rechten der eigentlichen Benutzer behandelt werden.
Über den AuthorizationServerEndpointsConfigurer wird der Server im Allgemeinen konfiguriert: In unserem Beispiel wird für die Ablage der ausgestellten Access Token ein In-Memory Token-Store verwendet. Für einen produktiven Einsatz ist jedoch auch über einen JdbcTokenStore die Ablage in einer relationalen Datenbank möglich. Darüber hinaus muss dem Server ein Authentication Manager zugewiesen werden, welcher für die eigentliche Authentifizierung der Benutzer verwendet wird. Ohne diesen würde der Server die Verwendung des Resource Owner Password Credential Grants nicht aktivieren. Für die Konfiguration des Authentication Managers muss im Spring-Kontext mindestens ein UserDetailService bereitgestellt werden.
Authentication Manager
Wie der Authentication Manager konfiguriert wird, ist für die Konfiguration des Authorization Servers nur bedingt relevant, solange diesem eine Instanz zur Verfügung gestellt werden kann. Es hat sich jedoch gezeigt, dass es bei der Konfiguration des Authorization Servers und eines Authentication Managers schnell zu Problemen durch zyklische Abhängigkeiten kommen kann. Daher wird in diesem Beispiel ein von Spring Security automatisch erzeugter Authentication Manager verwendet, welcher dabei einen verfügbaren UserDetailService als Grundlage verwendet. In der Konfiguration des Authorization Servers kann dieser Authentication Manager aufgrund von zyklischen Abhängigkeiten jedoch auch nicht direkt injected werden. Vielmehr muss mit der AuthenticationConfiguration gearbeitet werden, von welcher bei Bedarf später der Authentication Manager bezogen werden kann. Darüber hinaus sollte die Konfiguration des UserDetailService aufgrund von Abhängigkeiten in der Objekt-Erstellung der Konfigurations-Klassen in einer gesonderten Konfiguration erfolgen.
Da sich neben den eigentlichen Anwendern auch die OAuth Clients authentifizieren müssen, ist ein zweiter Details-Service notwendig, welcher die Clients verwaltet. Dieser wird über den ClientDetailsServiceConfigurer konfiguriert. In diesem Beispiel handelt es sich ebenfalls wieder um eine In-Memory-Implementierung. Auch hier steht für den produktiven Einsatz eine JDBC-Implementierung für den Zugriff auf eine relationale Datenbank zur Verfügung. Im vorliegenden Beispiel werden das API Gateway sowie der Produkt-Service als exemplarischer Resource Server konfiguriert. Neben einer Client-Identifikation und einem Passwort wird für das API Gateway auch der Grant Type Resource Owner Password Credential erlaubt. Der Produkt-Service erhält zudem die Berechtigung, Access Token am Authorization Server zu prüfen.
Beide Client-Konfigurationen erhalten noch Scopes. Generell können Scopes in diesem Beispiel bei der Authentifizierung durch den API Gateway angefragt werden. In diesem Beispiel werden die hier konfigurierten Scopes für den Client vergeben. Wichtig ist in diesem Kontext, dass mindestens ein Scope verfügbar sein muss, da sonst die Authentifizierung nicht erfolgreich durchgeführt werden kann. Da in diesem Beispiel keine Scopes durch das API Gateway selber angefragt werden, wird durch den hier vergebenen Scope default sichergestellt, dass zumindest ein Scope immer vergeben wird.
Zusammenfassung und Ausblick
In diesem Blogpost haben wir unser Beispiel-Szenario vorgestellt und gesehen, wie die Authentifizierung an einem OAuth 2.0 Authorization Server erfolgt. Darüber hinaus haben wir gesehen, wie wir OAuth hinter einem API Gateway verbergen und in eine klassische formbased Authentifizierung übersetzen.Im folgenden Blogpost werden wir sehen, wie wir die Authentifizierung und Autorisierung an unserem Microservice auf Basis der hier erfolgten Authentifizierung durchführen.
Autoren
Andreas Hellmann ist als IT-Berater und Software-Architekt für die viadee IT-Unternehmensberatung tätig. Sein Schwerpunkt liegt in der Entwicklung von Enterprise-Anwendungen mit Java und Web-Technologien. Zudem engagiert er sich im Kompetenzbereich Security und vermittelt sein Wissen in Schulungen.
Michael Twelkemeier ist Senior-Berater bei der viadee. Sein Fokus liegt auf der Softwarearchitektur und der Entwicklung von Java/Spring-basierten Enterprise-Anwendungen. Darüber hinaus engagiert er sich im Kompetenzbereich Java.
zurück zur Blogübersicht
Diese Beiträge könnten Sie ebenfalls interessieren
Keinen Beitrag verpassen – viadee Blog abonnieren
