Fala Felipe, tudo bem ?
1) É perfeitamente comum e uma boa prática desenvolver o backend 100% em webservice e desenvolver aplicações a parte (Ex. react angular, android) só para consumi-los ?
Aqui depende muito! Depende da sua aplicação, do tamanho da sua aplicação, da densidade e complexidade das suas Views e das informações que sua app apresenta ao usuário final, etc, etc.
Se sua app tem Views simples que recebem/apresentam informações que são fáceis de serem gerenciadas, que enviam/recebem poucas informações ou trabalham em um fluxo/interação de páginas simples, você ainda (na minha opinião), deveria utilizar uma arquitetura mais simples, fazendo com que sua app - backend - manipule templates gerando páginas seja com Thymeleaf, JSP ou qualquer outra tecnologias desse tipo) - Aqui você ganha facilidade e rapidez no desenvolvimento, já que só precisa ter o domínio dessa engine de templates, seu backend se integra em geral de forma simples e direta com elas. Por outro lado, tem mais trabalho se quiser fazer suas lógicas atenderem clientes que não sejam navegadores (dados que essas engines em geral funcionam renderizando html), você vai precisar adicionar suporte a media types diferentes e dependendo da ferramenta que estiver utilizando pode não ser tão simples.
Já se sua app, tem interações mais complexas entre componentes visuais, ou trafega (trafegaria) muitas informações a cada requisição (onde você gostaria de manter o estado da tela entre chamadas ao seu server), se você gostaria de ter uma UX mais próxima de uma aplicação desktop nativa mesmo rodando na web (Single Page Applications - você pode pensar em um Gmail, ou Google Inbox da vida), você deveria utilizar essa arquitetura (Split Architecture) separando em duas stacks independentes o front-end e o back-end. - Aqui a arquitetura fica mais complexa, porém mais completa, podendo contar com os pontos fortes de cada stack, sua equipe de front em geral tem total liberdade pra empregar as melhores praticas pra desenvolver o codigo da UI do seu software de maneira independente dos detalhes de qq ferramenta que te ajuda a pré-renderizar paginas no backend. No back, você consegue fazer seu serviço ser consumido via http tanto pela sua aplicação front (React, Vue, Angular, etc) tanto por qualquer outro sistema (um cliente mobile nativo em Android ou iOS, ou mesmo outros serviços implementados em qq linguagem que queira se integrar ao seu) de forma fácil. Por essa última questão é que tem se dado maior uso na minha opinião. Seu serviço é consumível por vários clientes diferentes.
2) Já que podemos acessar o serviço só pela url, como é feita a segurança para impedir o acesso de qualquer um?
Em geral, como sua aplicação (serviço, back) é consumível por qualquer cliente, e não somente pelos populares clientes web (browsers) que eram utilizados como meio de acesso pelo cliente final, temos uma grande mudança.
Antes eu abria meu browser, chamava o site/app pelo endereço, logava, tinha uma sessão aberta no servidor me atendendo e guardava no meu browser o id dessa sessão pra validar minha próxima chamada.
Com um web service isso já tem mudado. Cada vez mais a app backend tem aberto mão de manter seus dados (sessão) dado que o volume de clientes é (na maioria das vezes) maior e mais diverso. Em geral a app recebe dados de autenticação num primeiro momento, e ao invés de manter aberta uma sessão guardando os detalhes desse cliente, ela entrega um dado ao cliente (token) que pode ser guardado pra na próxima chamada ser reenviado garantindo a autenticidade da comunicação. Por sua vez a app nas próximas chamadas verifica a presença desse token (pode ser feito num filter mesmo, pensou certo) e se ele estiver presente verifica sua validade (se representa um usuário válido, se não expirou ou algo do tipo, vê se este cliente pode acessar a informação que está requisitando) e executa o que deve ser feito, caso não tenha ela rejeita a comunicação avisando ao cliente que ele deveria se autenticar. Você delega ao cliente manter essa informação e a verifica a cada comunicação.
Você poderia implementar na mão, mas é muito comum uso de frameworks pra isso. O que eu costumo usar é o Spring Security pra fazer isso, recomendo dar uma olhada.
Enfim, espero ter ajudado no pensamento.
Abraço!
