Olá @nayra,
Acredito que esse tópico ficou um pouco confuso no livro e é algo que poderá ser melhorado em uma próxima edição. Vamos ver se consigo deixar um pouco mais claro esse assunto por aqui:
O OpenID Connect (OIDC) é construído em cima do OAuth 2.0. Ou seja, Identity Provider (IP) que está em conformidade com o OIDC, já herda algumas características do OAuth 2.0. Até o momento da escrita do livro, a especificação do OIDC estabelecia o uso dos grant types authorization_code e implicit.
O Google, por fornecer um serviço de autenticação em conformidade com o OIDC, também funciona como Authorization Server (tanto que ele retorna Access Token e ID Token). O OIDC serve p/ resolver especificamente o problema de autenticação.
No exemplo do livro, note que ao alterar a aplicação bookserver para permitir autenticação via OIDC, isso não causa impacto direto p/ aplicações que são client de bookserver. Nesse caso, a aplicação bookserver ainda continua até mesmo funcionando como Resource Server & Authorization Server, porém ela cuida da autorização de acessos no seu próprio nível (esse talvez seja mais uma das coisas que contribuem para uma certa confusão nesse capítulo).
Quando se utiliza o OpendID Connect, é mais recomendado utilizar um solução de mercado como a do google, aws…? Ou ferramentas como OKTA ou Keycloak ?
Durante a escrita do livro eu tinha conhecimento apenas do Google, Microsoft e WSO2 (Outra empresa que fornece um produto para Identity Federation, Authorization e etc). Existem muitas empresas e até mesmo ferramentas Open Source como você citou no caso do Keycloak que podem te ajudar a manter um servidor de autorização ou IP. Isso vai depender muito do seu projeto. Já trabalhei em projeto onde ter um Authorization Server rodando com Spring foi mais que suficiente. Entretanto, dependendo da escala do seu produto pode ser mais interessante contar com um serviço que garanta disponibilidade com SLAs e etc.
Atualmente, o projeto Spring Security OAuth2 está deprecated conforme pode ser visto em https://spring.io/projects/spring-security-oauth e no GitHub do projeto tem um guia bacana para migrar sua aplicação para a versão mais nova do Spring Security https://github.com/spring-projects/spring-security/wiki/OAuth-2.0-Migration-Guide.
Apesar das mudanças no Spring Security, os conceitos apresentados no livro continuam válidos (apenas atenção para o Implicit Flow que não é mais recomendado e um draft já existe para discutir esse assunto em https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15).
Um ponto interessante a respeito de Servidores de Autorização é que na última versão do Spring Security, chegaram a considerar a remoção do suporte a implementação de Authorization Server, dada a vasta quantidade de projetos/serviços já existentes no mercado. Mas no fim das contas eles mantiveram a ideia de fornecer meios para a criação de Authorization Server e que foi implementado em um projeto dedicado chamado Spring Authorization Server: https://spring.io/blog/2020/04/15/announcing-the-spring-authorization-server.
Bom, espero que essa mensagem possa deixar o assunto um pouco mais claro.
Fico feliz que o livro esclareceu algumas dúvidas sobre o framework OAuth2 e agradeço sua dúvida que me dá a oportunidade de compartilhar alguns updates sobre o assunto aqui.
Bons estudos.