ImplicitAudienceValidatingTokenServices manquant dans le nouveau okta-spring-boot 2.1.1

Question

J'ai mis à jour nos applications Spring Boot en passant de okta-spring-boot-starter v0.61 à v2.1.1.

Les microservices sont maintenant toujours en mouvement :

p.a.OAuth2AuthenticationProcessingFilter : Authentication request failed: error="invalid_token", error_description="Invalid access token:  ... TOKEN OMITTED

Le NOUVEAU (v2.1.1) OAuth2AuthenticationManager est câblé avec une instance de org.springframework.security.oauth2.provider.token.DefaultTokenServices qui a un hashmap vide et provoque une exception (car OAuth2AuthenticationManager renvoie null) de tokenServices.loadAuthentication(token)

L'implémentation OLD (v0.61) utilisait une instance de com.okta.spring.oauth.implicit.ImplicitAudienceValidatingTokenServices

Ceci était créé automatiquement dans l'ancien code à l'intérieur ResourceServerConfig

ImplicitAudienceValidatingTokenServices a maintenant disparu de okta-spring-boot, tout comme Configuration des ressources . Je ne vois pas très bien comment je pourrais activer le même comportement dans Okta Spring Boot Starter v2.1.1.

Une idée de la configuration/des propriétés qui me manquent pour rétablir l'ancien comportement ? Je ne pense pas qu'Okta prenne en charge la "validation à distance des jetons" (je ne suis pas sûr de l'expression technique exacte). La validation locale est suffisante pour nos besoins.

Answer 1

Beaucoup de choses ont changé entre ces versions. Le plus important est le support OAuth de Spring Security (sur lequel repose la librairie Okta). Assurez-vous que vous n'avez pas l'ancienne librairie Spring Sec dans votre classpath. spring-security-oauth . Le site Guide de migration connexe pourrait vous aider aussi (en fonction de ce que vous faites).

A partir de là, il y a deux choses à configurer :

1. Vos propriétés de configuration (qui doivent rester les mêmes) okta.oauth2.*
2. Configurer le serveur de ressources.

Pour le dernier, il ne reste plus qu'à nous faire le nouveau API Spring Security pour configurer un serveur de ressources :

import com.okta.spring.boot.oauth.Okta;
import org.springframework.http.HttpMethod;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;

@EnableWebSecurity
public class OAuth2ResourceServerSecurityConfiguration extends WebSecurityConfigurerAdapter {

    @Override
    protected void configure(HttpSecurity http) throws Exception {

        http.authorizeRequests()
            // all requests are authenticated
            .anyRequest().authenticated()
            .and()
            .oauth2ResourceServer().jwt(); // replace .jwt() with .opaqueToken() for Opaque Token case

        // Send a 401 message to the browser (w/o this, you'll see a blank page)
        // this is optional, and only needed if people are accessing your API manually through a browser
        Okta.configureResourceServer401ResponseBody(http);
    }
}

Vous pouvez voir un exemple complet ici : https://github.com/okta/samples-java-spring/blob/master/resource-server/src/main/java/com/okta/spring/example/ResourceServerExampleApplication.java (ajoutez simplement vos propriétés)

Les éléments spécifiques à Okta sont intégrés et configurés automatiquement, par exemple, la validation JWT spécifique à Okta (il n'existe pas encore de spécification officielle pour les jetons d'accès JWT).

De plus, pour la "validation de jeton à distance", elle est qualifiée d'"opaque" dans l'API Spring Sec, voir le commentaire dans le bloc de code de l'API Spring Sec. .opaueToken() .

Answer 2

Comme indiqué, j'ai pu résoudre le problème.

Avec l'exemple ci-dessus, j'en ai aussi trouvé un autre. Le premier était plus spécifique au général Spring : https://github.com/spring-projects/spring-security-samples/blob/main/servlet/spring-boot/java/oauth2/resource-server/hello-security/src/main/java/example/OAuth2ResourceServerSecurityConfiguration.java

Comme j'utilise okta-spring-boot, j'ai utilisé l'exemple de Brian : https://github.com/okta/samples-java-spring/blob/master/resource-server/src/main/java/com/okta/spring/example/ResourceServerExampleApplication.java

La première chose que j'ai faite est d'ajouter deux nouvelles propriétés pour Spring Boot. Cela prête à confusion car je crois que les noms des mêmes propriétés ont changé très subtilement au moins une fois au cours des différentes versions de Spring. Il existe des exemples avec des noms différents qui apparaîtront sur Google et ne seront pas immédiatement perceptibles comme différents. Ces exemples sont corrects pour Spring Boot 2.5.4 et Spring Core 5.3.9 :

spring.security.oauth2.resourceserver.jwt.issuer-uri: https://your domain.okta.com/oauth2/your_auth_server_id (peut avoir besoin de /default selon la façon dont votre application est configurée)

spring.security.oauth2.resourceserver.jwt.jwk-set-uri: url_above/v1/keys

J'ai dû supprimer @EnableResourceServer et ajouter (en me basant sur l'exemple Okta ci-dessus) l'annotation @EnableGlobalMethodSecurity(prePostEnabled = true, secureEnabled = true)

Dans mon cas, nous avions une implémentation de ResourceServerConfigurerAdapter que j'ai mise à jour pour étendre WebSecurityConfigurerAdapter et utiliser l'API pour créer le serveur de ressources : .and().oauth2ResourceServer().jwt() ;

Je dois encore effectuer des tests supplémentaires et je veux comprendre les options de EnableGlobalMethodSecurity, mais pour le moment, mes points d'extrémité REST acceptent à nouveau correctement les jetons Bearer.