Quais detalhes técnicos os programadores devem considerar ao desenvolver seu próprio serviço oAuth?

8

Quais detalhes técnicos os programadores devem considerar ao desenvolver seu próprio serviço oAuth?

Estão tentando descobrir diretrizes, mas a maioria dos oAuthartigos relacionados é discutida como um ponto de vista do consumidor ( ou seja, como consumir outros serviços ). Quero projetar meu próprio oAuthsistema com meu serviço de autorização e serviço de recursos. Que detalhes técnicos devo seguir?

— Sazzad Hissain Khan
fonte

1

O desenvolvimento de seu próprio serviço oAuth pode ser muito complexo. Depende do que você realmente deseja alcançar e de quais fluxos de autenticação você deseja oferecer suporte, por exemplo, concessão implícita, código de autorização etc. Se você usar um dos provedores de autenticação famosos como Azure AD, Cognito, Okta, Auth0.com, etc. de capuz. Eles não apenas fornecem a implementação do servidor, mas o SDK do cliente para a atualização automática do token, etc. Adotando a implementação completa Você precisa conhecer pelo menos os fluxos de autenticação, auth2.0, protocolo OpenID Connect, tokens, segurança e provavelmente outros bits que eu não conheço.

— Imran Arshad

Você já pensou em NÃO construí-lo? :) Brincando à parte, um serviço oAuth raramente faz parte da proposta de valor de uma empresa e, mais raramente, um fator diferenciador, o que implica que a maioria das empresas está melhor usando ou comprando uma solução pronta para uso. Isso não quer dizer, é claro, que não há casos válidos em que algo assim faria sentido nos negócios, mas isso deve ser claramente explicado.

— Savvas Kleanthous

1

@AKleanthus Atualizei o título. Eu acho que isso era enganador anteriormente.

— Sazzad Hissain Khan

4

Você provavelmente leu os RFCs, mas, caso não tenha, eles são o lugar que você deseja começar:

"Núcleo" oAuth 2.0 (RFCs 6749 e 6750 )
Chave de prova para troca de código (PKCE) (RFC 7636 )

A melhor orientação 'empacotada' para os implementadores oAuth (cliente ou não) está disponível no IETF Best Current Practices (BCPs). A maioria das pessoas sabe sobre IETF RFCs e (confusamente) BCPs são publicados como RFCs com um número RFC. Apesar disso, são práticas recomendadas e não especificações formais :

O processo BCP é semelhante ao dos padrões propostos. O BCP é enviado ao IESG para revisão, e o processo de revisão existente se aplica, incluindo uma "última chamada" na lista de correspondência de anúncios da IETF. No entanto, uma vez que o IESG tenha aprovado o documento, o processo termina e o documento é publicado. O documento resultante é visto como tendo a aprovação técnica da IETF, mas não é e não pode se tornar um padrão oficial da Internet.

BCPs que você deseja revisar:

Segurança oAuth (atualizada até a data de redação deste documento)
oAuth para aplicativos baseados em navegador (atualizados até o momento da redação deste documento).
oAuth para aplicativos nativos (publicado em 2017 como uma atualização para o "core" oAuth 2.0 RFC, ainda uma boa leitura)
Tokens da Web JSON para oAuth (atualizados)

Esses documentos são estruturados em termos de modelo de ameaça - cobrem ataques (ou "considerações de segurança" como um formato diluído) e contramedidas. Você pode estar procurando por um tipo de roteiro mais simples e talvez deva haver um como uma ferramenta educacional. As implementações de oAuth no mundo real devem ser desenvolvidas com uma evidência prima facie de um modelo de ameaça.

Como um samurai disse : ... a arte da espada não testada em batalha é como a arte de nadar dominada em terra.

— identigral
fonte

2

Também gostaria de saber por que você deseja desenvolver sua própria solução de autenticação.

Mas, deixando isso de lado, existe um projeto de código aberto que faz exatamente o que você pede - Identity Server . Você pode verificar o código-fonte ou bifurcá-lo e criar algo sobre ele.

Além disso, verifique a resposta "identigral" em vários documentos.

— eddyP23
fonte