Spring Security Oauth2 — Episódio 3.1

Eu aqui novamente, again, one more time… E esse é o terceiro artigo da série, então se você não viu os anteriores, sugiro dar uma olhadinha, mas não se preoculpe que eu tento abordar de uma forma bem independente para que não cause dependências de conhecimento. (é baixo acomplamento na veia, até nos artigos :D kkk)

Nesse artigo vamos falar sobre AuthorizationServer utilizando jdbcTokenStore e o domínio dele. Então, bora lá! o/

Quando você adota o padrão oauth2, você estabelece que existe um autorizador e autenticador, alguém que autoriza e autentica o client e o resource owner (que usa o client) para consumir os resourcers server, esse cara é o AuthorizationServer.

O spring security já possue uma classe que é responsável por isso, é a AuthorizationServerCofigurerAdapter que implementa a interface AuthorizationServerConfigurer, nessa interface existem 3 métodos “configure” que podemos sobrescrever para configurarmos conforme nossa necessidade. Para isso nós criamos uma classe que extends AuthorizationServerConfigurerAdapter e sobrescrevemos eles. Na nossa classe, utilizamos as seguintes anotações “@Configuration” e “@EnableAuthorizationServer” que são responsáveis por indicar para o framework a responsabilidade de nossa classe e habilitar o mecanismo do AuthorizationServer.

Nesta classe, nós vamos configurar o AuthorizationServerEndpointsConfigurer pelo método configure que recebe ele.

Nele nós setamos o tokenStore responsável por fornecer o token.

O tokenEnhancer que recebe um TokenEnhancerChain que podemos customizar o nosso token.

O accessTokenConverter que é o responsável pela segurança de nossas chaves, aqui eu indico usar assimétrica, que são um par de chaves pública e privada.

O authenticationManager que é quem possue o authenticate e você pode customizar o processo de autenticação por ele.

O allowedTokenEndpointRequestMethods, aqui é uma questão de boa prática e bom senso na minha humilde opnião. Eu limito as chamadas para requisitar o token por meio do verbo POST. Na classe TokenEndpoint que fica no package endpoint você vai ver dois métodos: getAccessToken e postAccessToken, como os nomes sugerem ele expoe os verbos GET e POST para requisitarem o token, porém como pode ver, ao requisitar via GET ele dentro do getAccessToken chama o postAccessToken. Por isso, eu não uso o verbo GET e limito ao verbo POST.

O userDetailsService você vai “carregar” o user sobrescrevendo o loadUserByUsername. Aqui é importante frizar a segmentação. Existe um userService que pode ter suas regras de carregamento do user e que vai ser injetado o seu repository para recuperar do banco o seu user e existe o service que implementa o userDetailsService. Por quê eu separo ? Eu posso escrever sobre SOLID no futuro( se quiser, comenta abaixo), mas de forma simples é para não romper com o conceito de single responsability, permitir escalar, deixar o código mais flexível e com melhor legibilidade, além de melhorar a manutembilidade.

Agora vamos confirar o AuthorizationServerSecurityConfigurer. Setamos quem pode acessar a chave pública por meio do tokenKeyAccess e quem pode checkar um token por meio do checkTokenAccess. São importante, você não vai querer todo mundo requisitando esses serviços em especial o checkTokenAccess.

Aqui podemos customizar AuthenticationEntryPoint que possui o commence e nos permite customizar o response de erros por exemplo.

Agora vamos falar do ClientDetailsServiceConfigurer. Esse cara recebe passwordEncoder que você pode escolher quem vai encripar e fazer match das senhas. Eu sempre customizo… sugiro o mesmo. E recebe também DataSource que nesse caso é o do jdbcTemplate que injetamos.

E nosso ultimo bean é o DefaultTokenServices onde podemos configurá-lo passando um defaultToken ou apenas instanciar um novo defaultToken e o mais importante, vamos setar o tokenStore e o supportRefreshToken.

Uma vez criado e configurado nosso AuthorizationServer, como optamos por trabalhar com jdbcTokenStore, ele possue um domínio de tabelas para funcionar corretamente. Como este artigo já está muito grande, vou falar no próximo exclusivamente sobre esse domínio e suas classes.

É isso, vlw flw e bora pro próximo artigo que eu vou continuar lá :D o/