Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
Pessoal, sobre o JWT Json Web Token, tenho algumas dúvidas.
Atualmente faço uso de **$_SESSION** no **PHP** para autenticar e validar usuários e seus acessos à **API** e, *logins* no **site/admin**, dentre outras coisas.
Mas, estudando aqui sobre **API's**, percebi a grande utilização do **JWT** em conjunto com a **autenticação**.
1 => No form de login o usuário de identifica
2 => Se as credenciais existirem o usuário ganha o retorno **OK** e cria uma **$_SESSION** com as *credenciais*.
Mas isso é quando **Ambiente Admin e API** estão no mesmo *domínio*.
Quando estão em domínios diferentes está sendo usado o **JWT**.
Mas, aí vem a dúvida: É confiável para *níveis* de *acesso* e *autenticação*?
Andei pensando em umas coisas:
A) Enviar no **Token** o nível de acesso do usuário. Se é administrador, **API**, etc... Mas isso pode ser mudado pelo **man-in-the-middle**.
B) Então pensei em enviar via **SECRET**. Também não dá pois o segredo deve ser 1 para todo e qualquer acesso ficando impossível a verificação do **TOKEN** pela **API**
C) Pensei enviar via cabeçalho (**header**). Mas no caso, é a **API** quem gera o **Token**. Logo, não dá!
Será que não existe saída?
Terei mesmo que usar **$_SESSION** para nível de acesso e **JWT** para validação da *requisição*?
Será que estou tendo uma visão errada do **cenário**?
Alguém pode me ajudar a enxergar isso?
Meu sistema de **diretórios** é:site/admin //administrador da API
site/api // A própria API
Amigo, obrigado pelas respostas mas acho que o que eu quero não é nem mesmo viável!
O que eu pensei seria o seguinte:
A API precisa de um administrador para popular os dados. Mas o /admin não deve ficar em /api/admin. Esse deve ser o meu primeiro erro de pensamento. me corrija se estiver errado! Pois no caso, até o Administrador deverá usar endepoints.
Outro problema seria que, se eu envolvesse /admin, teria a seguinte árvore de diretórios
/admin
/api
Fazendo assim de /admin outra API que irá ter o mesmo sistema de autenticação salvo se eu colocar outro JWT nesta API /admin.
Isso porque o usuário da API é um cliente com credenciais de cliente e o usuário de /admim terá credenciais de administrador.
Imagino que se eu mantiver o mesmo JWT para ambos ambientes terei problemas com autorizações e o cliente comum acabará acessando o /admn se tentar.
Nesse caso, terei que fazer:
/admin => ambiente de administração da API. Se enpoints de Webservice.
/api => ambiente da própria API acesso somente com endpoinds impedindo acesso direto ao MySQL
Me corrija se eu estiver errado?
Tipo, até que ponto é mesmo necessário usar a SESSION para autenticação de usuário e JWT TOKEN para validação ao mesmo tempo!
Isso não está claro para mim!
>
7 horas atrás, Carcleo disse:
Imagino que se eu mantiver o mesmo JWT para ambos ambientes terei problemas com autorizações e o cliente comum acabará acessando o /admn se tentar.
Neste caso, entra o ACL "Regras de Acesso"
https://pt.wikipedia.org/wiki/Lista_de_controle_de_acesso
Mas as autorizações continuam pelo JWT, independente que se tenha um endpoint para Users Admin e outro para Users "comuns", vou dar um exemplo do meu endpoint users
Quando eu autentico no sistema, me retorna o seguinte resultado.
{
"data": {
"id": 1,
"username": "DUARTE",
"email": "example@outlook.com",
"email_verified_at": null,
"active": true,
"admin": true,
"last_login": "2020-04-21 00:44:42"
},
"meta": {
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9sb2NhbGhvc3Q6ODAwMFwvYXBpXC9hZG1pbmlzdHJhdGl2ZVwvYXV0aFwvbG9naW4iLCJpYXQiOjE1ODc0OTIxNDQsImV4cCI6MTU4NzQ5NTc0NCwibmJmIjoxNTg3NDkyMTQ0LCJqdGkiOiJUS1hRY3JRcmVxaUZqb0R0Iiwic3ViIjoxLCJwcnYiOiIyM2JkNWM4OTQ5ZjYwMGFkYjM5ZTcwMWM0MDA4NzJkYjdhNTk3NmY3In0.UeTE5E4eYZOO9S5wNWCU3I3nA1CZYfc3nxchn6_NE9k",
"token_type": "bearer",
"expires_in": 3600
}
}
A segunda chamada, envio o token de volta, "invalido este token, renovo e trago outro no corpo do json". E o ID do usuario envio via post e seleciono todos o meus dados do banco e as regras de acesso "ACL" e as mantenho em Local Storage no navegador, para uso da aplicação SPA.
{
"data": {
"id": 1,
"username": "WSDUARTE",
"email": "example@outlook.com",
"email_verified_at": null,
"active": true,
"admin": true,
"last_login": "2020-04-21 15:02:24",
"profiles": null,
"phones": [
{
"id": 1,
"user_id": 1,
"phone": "(24) 95922-7390"
}
],
"addresses": [],
"roles": [
{
"id": 1,
"name": "admin",
"label": "Administrator",
"standard": true,
"permissions": [
{
"id": 1,
"name": "browser",
"label": "Browser",
"standard": true,
},
{
"id": 2,
"name": "create",
"label": "Create",
"standard": true,
},
{
"id": 3,
"name": "list",
"label": "List",
"standard": false,
},
{
"id": 4,
"name": "edit",
"label": "Edit",
"standard": true,
},
{
"id": 5,
"name": "delete",
"label": "Delete",
"standard": true,
}
]
}
]
},
,
"meta": {
"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOlwvXC9sb2NhbGhvc3Q6ODAwMFwvYXBpXC9hZG1pbmlzdHJhdGl2ZVwvYXV0aFwvbG9naW4iLCJpYXQiOjE1ODc0OTIxNDQsImV4cCI6MTU4NzQ5NTc0NCwibmJmIjoxNTg3NDkyMTQ0LCJqdGkiOiJUS1hRY3JRcmVxaUZqb0R0Iiwic3ViIjoxLCJwcnYiOiIyM2JkNWM4OTQ5ZjYwMGFkYjM5ZTcwMWM0MDA4NzJkYjdhNTk3NmY3In0.UeTE5E4eYZOO9S5wNWCU3I3nA1CZYfc6sxchn6_8s9k",
"token_type": "bearer",
"expires_in": 604800
}
}
Há várias formas de se fazer isto, enviar o id no corpo do token, fora, pegar por id, sessão e comparar o que está no token, a lógica é esta e usar SSL.
PS. eu tenho aplicação php, que se comunica com Endpoints em Node, com a mesma secret.
Não há uma receita de bolo!
Obs.: Na duvida e use um Framework tipo o Lumen, e instala o pacote de JWT e já estara pronto para usar.
Mas ele vai pela mesma logica acima. Fiz uma com node.js ea mesma filosofia. Voce tem que saber a base de como tudo funciona.
>
12 horas atrás, Carcleo disse:
Mas, aí vem a dúvida: É confiável para níveis de acesso e autenticação?
JWT é uma autorização é não autenticação. A autenticação permanece normal, oque você gera é um token de autorização após o login em seu sistema.
>
12 horas atrás, Carcleo disse:
>
12 horas atrás, Carcleo disse:
B) Então pensei em enviar via SECRET. Também não dá pois o segredo deve ser 1 para todo e qualquer acesso ficando impossível a verificação do TOKEN pela API
A secret, deve ficar em seu servidor, é a chave que verificara se o token é valido ou não.
>
12 horas atrás, Carcleo disse:
C) Pensei enviar via cabeçalho (header). Mas no caso, é a API quem gera o Token. Logo, não dá!
https://www.sitepoint.com/php-authorization-jwt-json-web-tokens/