Como uma API deve usar a autenticação básica http

Quando uma API exige que um cliente se autentique, eu vi dois cenários diferentes usados e fico imaginando qual caso devo usar para a minha situação.

Exemplo 1. Uma API é oferecida por uma empresa para permitir que terceiros se autentiquem com um token e um segredo usando HTTP Basic.

Exemplo 2. Uma API aceita um nome de usuário e senha via HTTP Basic para autenticar um usuário final. Geralmente, eles recebem um token de volta para solicitações futuras.

Minha configuração: terei uma API JSON usada como back-end para um aplicativo móvel e da web. Parece uma boa prática para o aplicativo móvel e da Web enviar um token e um segredo para que apenas esses dois aplicativos possam acessar a API bloqueando qualquer outro terceiro.

Mas o aplicativo móvel e da web permite que os usuários efetuem login e enviem postagens, visualizem seus dados etc. Então, eu gostaria que eles acessassem via HTTP Basic, bem como em cada solicitação.

De alguma forma, uso uma combinação desses dois métodos ou apenas envio as credenciais do usuário final (nome de usuário e token) em cada solicitação? Se eu enviar apenas as credenciais do usuário final, eu as armazeno em um cookie no cliente?

api rest authentication

— Paul Sylling
fonte

Observe que os cookies não fazem parte do protocolo HTTP e são apenas um recurso comum do navegador. Portanto, se você não estiver implantando na Web, esqueça-os.

— Yam Marcovic 12/09

Se os cookies não forem recomendados, como / onde você armazena os creds para passar para a API?

— Paul Sylling

Os cookies são apenas uma maneira de os usuários do navegador armazenarem perfeitamente os tokens de sessão. Se você está interagindo com um desenvolvedor, isso não precisa ser contínuo. Você pode configurar um serviço de conexão pública que conceda "tickets", e os desenvolvedores poderão manter o ticket na memória ou onde quiserem. Observe que não tenho experiência prática em serviços da web e provavelmente existem soluções padrão para esse tipo de coisa.

— Yam Marcovic

O que você achou da minha pergunta sobre autenticação de usuário final e autenticação de API? Eu sou ainda não tem certeza sobre isso

— Paul Sylling

Respostas:

A autenticação básica HTTP requer que o nome de usuário e a senha sejam enviados a cada solicitação de recurso. O nome de usuário: senha é passado no cabeçalho da solicitação "Autorização", sequência codificada em base64, prefixada com "Básico". Se toda a sua comunicação http estiver criptografada (via ssl), as informações do cabeçalho da Autorização não poderão ser usadas com facilidade pelos invasores, pois é improvável que eles consigam obtê-la.

HTTP criptografado em SSL com autenticação básica deve ser suficiente.

— Nathan Pilling
fonte

você pode dar um exemplo disso? É o que eu preciso, apenas para a direita muito preso agora ...

— ganders

O Outh / OpenID pode funcionar junto com token / segredo?

Recentemente, contemplei o seguinte cenário:

Front-end de aplicativos da Web
API REST subjacente
Aplicativos para dispositivos móveis, acessando a API REST

Como um teste simples, eu pude:

Autenticar usuários por meio do aplicativo Web usando OAuth
A API REST autorizada via OAuth, resultando em um segredo sendo gerado e transmitido de volta ao cliente
O dispositivo móvel se autentica via OAuth e depois é autorizado pela API REST por meio do segredo

Isso permitiria que o aplicativo de dispositivo móvel se autenticasse com as mesmas credenciais do Front-end da Web (a mesma conta) e também autorizasse o acesso à API.

— Brendan Green
fonte

Portanto, no seu exemplo, apenas o usuário está se autenticando. Os clientes nos quais estão fazendo as chamadas para a API (aplicativo Web, aplicativo móvel) não estão autenticando quem eles são. Teoricamente, a API é pública e qualquer aplicação poderias enviar um nome de usuário e senha e, potencialmente, obter uma volta simbólica

— Paul Sylling

O usuário está autenticando através do aplicativo, e o aplicativo está fazendo as chamadas em nome do usuário. O processo de autenticação deriva o token, que o aplicativo passa adiante.

— Brendan Green