OAuth 2.0 Resources in Spring Security absichern

by ·Keine Kommentare

Sichern einer Anwendung mit Spring Security 5.0

1. Hinzufügen der Dependencies

"org.springframework.boot:spring-boot-starter-sercurity",
"org.springframework.security:spring-security-oauth2-resource-server"

Mit dem Hinzufügen der Dependency spring-boot-starter-sercurity werden automatisch alle Endpoints gesichert.

Es muss spring-security-oauth2-resource-server Libary eingebunden werden, damit die Anwendung mit JWT encoded Barear Token gesichert werden kann. Dieses muss deklariert werden, dann verwandelt sich die Anwendung in einen Resource Server. Wenn ein Authorization Header in einem Request vorhanden und in diesem Barear Schema und das Token vorhanden ist, dann wird das JWT geparst und festgestellt ob der Request authorisiert war oder nicht.

2. Anpassen der application.yaml

Die application.yaml muss angepasst werden. Es muss die URI angegeben werden wo der uaa Server läuft. Hier in diesem Beispiel läuft der Server auf dem Localhost auf Port 8090.

   security:
     oauth2:
       resourceserver:
         jwt:
           issuer-uri: http://localhost:8090/uaa/oauth/token

Beim Starten der Anwendung werden von der standarisierten URI http://localhost:8090/uaa/oauth/token/.well-known/openid-configuration weitere Konfigrationseinstellungen geladen. In den Konfigurationseinstellungen wird u.a. auch die URI für jwks-Token angegeben.

Über die URI (http://localhost:8090/uaa/token_keys) kann der PublicKey geladen werden, um z.B. die Signierung durch den Authorisationsserver zu überprüfen und ob das Token seit der Generierung im Server modifiziert worden ist.

Damit ist die minimale Konfiguration abgeschlossen, um die Anwendung in einen Resourceserver zu verwandeln.

Exkurs: JWT

JWT (jawt ausgesprochen) steht für JSON Web Token. Auf jwt.io gibt es einen Decoder der die beide Teile Header und Payload base64 decodiert und als JSON darstellt. Im Header wird der Algorythmus und der Typ (z.B. JWT) angegeben. In der Payload können die Attribute (hier Claims genannt) übertragen werden. JWT wird als Bearer Token im HTTP Authorization Header übertragen. Der Header und die Payload wird als Singnatur mit RSASHA256 angehangen.

UAA

OAuth Authorization Code FLow

Resource Owner –> Application –> Authorization Server –> Resource Server

  1. Der Resource Owner (Hier der Anwender) fragt bei der Application an.
  2. Die Application frag den Anwender nach den Rechten. Dieser gewährt der Anwendung diese.
  3. Die Authentifizierung und die Authorisierung werden an den Authorisationsserver geschickt.
  4. Der Authorisationsserver schickt der Anwendung einen Authorisationscode (OTC) zu. Dieser ist kurzlebig.
  5. Nun tauscht die Anwendung den OTC Code zusammen mit den Client Credentials (Das ist die Authentifizierung der Anwendung) mit dem Authorisationsserver für das Token aus.
  6. Der Authorisationsserver antwortet mit dem Token für die Anwendung.
  7. Nun kann die Anwendung mit dem Token auf den Resource Server nach einer Resource anfragen.
  8. Der Resource Server schickt nach Validierung des Tokens die angeforderte Resource an die Anwendung.

Das Token ist mächtig und daher verbleit es im Backend der Anwendung und wird somit geschützt. Sollte das Token offengelegt (geleakt) werden, so hat man den vollen Zugriff auf die API mit Rechten des Anwenders. Deshalb sollte die Gültigkeit des Token nur kurz sein und es regelmäßig aktualisiert werden.

OAuth Client Credentials Flow