Lo primero a tener en cuenta es que Spring Security OAuth 2.4.0 oficialmente desprecia todas sus clases .
La segunda cosa es que según Spring Security - Matriz de características OAuth 2.0 - Preguntas frecuentes :
Ya no planeamos agregar soporte de Servidor de Autorización a Spring Security.
Una solución es usar un servidor de autorización OAuth2 como Gluu o Keycloak , pero dependiendo de su uso y del grado de personalización que haya realizado en su servidor de autorización, esto ciertamente no es sencillo.
Debido a las protestas de la comunidad de Spring, también existe la esperanza de que todavía se implemente un servidor de autorización en Spring Security. De acuerdo con Josh Cummings en Github :
Nos gustaría agradecer a todos por sus comentarios sobre la decisión de no admitir Authorization Server. Debido a estos comentarios y algunas discusiones internas, estamos volviendo a analizar esta decisión. Notificaremos a la comunidad sobre cualquier progreso.
Ver también: https://spring.io/blog/2019/11/14/spring-security-oauth-2-0-roadmap-update
== Actualización 5 de marzo de 2020 ==
Para responder a la pregunta de Joseph: "¿Algún problema si continuamos usándolo?": Por ahora, no hay problemas específicos, Spring Security OAuth todavía se mantiene, pero esto probablemente no será el caso en un futuro cercano. Citando la misma publicación de blog anterior :
La línea 2.3.x llegará a EOL en marzo de 2020. Apoyaremos la línea 2.4.x al menos un año después de alcanzar la paridad de características.
Con ese fin, con el lanzamiento de Spring Security 5.2, alentamos encarecidamente a los usuarios a comenzar a migrar sus aplicaciones heredadas de cliente y servidor de recursos OAuth 2.0 al nuevo soporte de Spring Security 5.2.
== Actualización 15 de abril de 2020 ==
Se anuncia un nuevo servidor de autorización Spring . Lo puedes encontrar en Github .
