Um Time de Tecnologia da Informação (TTI) de um tribunal de ...

Olá, aluno! Vamos analisar a questão e entender por que a alternativa correta é a B.

Alternativa Correta: B - fazer uso de Access Tokens para acesso a API RESTful

O protocolo OAuth2 é amplamente utilizado para delegar autorizações de forma segura na web. O principal elemento desse protocolo são os Access Tokens, que são credenciais temporárias utilizadas para acessar recursos protegidos pela API.

Ao implementar o uso do OAuth2 no novo aplicativo, os desenvolvedores devem usar Access Tokens para garantir que apenas usuários autenticados possam acessar a API RESTful. Esses tokens são gerados após a autenticação do usuário e têm validade limitada, o que aumenta a segurança da aplicação.

Agora, vamos entender por que as outras alternativas estão incorretas:

Alternativa A - aplicar Refresh Tokens não expiráveis

Os Refresh Tokens são usados para obter novos Access Tokens sem que o usuário precise se autenticar novamente, mas torná-los "não expiráveis" contraria os princípios de segurança, pois um token que nunca expira representa um grande risco em caso de comprometimento.

Alternativa C - considerar o Resource Owner como hospedeiro da API RESTful

O Resource Owner é o usuário que possui a conta e os dados protegidos, não o hospedeiro da API. O hospedeiro da API é o Resource Server, que gerencia e protege os dados acessíveis via API.

Alternativa D - utilizar um Token Endpoint para armazenar os autorizações de acesso

O Token Endpoint é um ponto de acesso no servidor de autorização onde os tokens são emitidos, mas ele não é utilizado para armazenar autorizações de acesso. Seu papel é gerar e retornar tokens após a autenticação e autorização.

Alternativa E - configurar o Resource Server como o responsável por gerar autorizações de acesso a API RESTful

No modelo OAuth2, o Resource Server gerencia os recursos protegidos, enquanto o Authorization Server é responsável por autenticar o usuário e emitir os tokens. Portanto, essa alternativa está incorreta.

Espero que essa análise tenha ajudado você a entender melhor o tema de segurança da informação e controles de segurança! Se tiver alguma dúvida, estarei à disposição para ajudar.

Gabarito: alternativa B

O OAuth 2 foi construído em cima de 4 papéis, sendo:

• Resource Owner - pessoa ou entidade que concede o acesso aos seus dados. Também chamado de dono do recurso.
• Client - é a aplicação que interage com o Resource Owner, como por exemplo o browser, falando no caso de uma aplicação web.
• Resource Server - a API que está exposta na internet e precisa de proteção dos dados. Para conseguir acesso ao seu conteúdo é necessário um token que é emitido pelo authorization server.
• Authorization Server - responsável por autenticar o usuário e emitir os tokens de acesso. É ele que possui as informações do resource owner (o usuário), autentica e interage com o usuário após a identificação do client.

O fluxo de autorização do OAuth2 funciona assim:

1. Solicitação de autorização Nessa primeira etapa o cliente (aplicação) solicita a autorização para acessar os recursos do servidor do usuário
2. Concessão de autorização Se o usuário autorizar a solicitação, a aplicação recebe uma concessão de autorização.
3. Concessão de autorização O cliente solicita um token de acesso ao servidor de autorização (API) através da autenticação da própria identidade e da concessão de autorização.
4. Token de acesso Se a identidade da aplicação está autenticada e a concessão de autorização for válida, o servidor de autorização (API) emite um token de acesso para a aplicação. O cliente já vai ter um token de acesso para gerenciar e a autorização nessa etapa já está completa.
5. Token de acesso Quando o cliente precisar solicitar um recurso ao servidor de recursos, basta apresentar o token de acesso.
6. Recurso protegido O servidor de recursos fornece o recurso para o cliente, caso o token de acesso dele for válido.
7. O servidor de autorização é responsável pelo SSO (Single Sign On), que centraliza as credenciais dos acessos dos usuários e faz a autenticação, gerencia as permissões dos usuários e emite os tokens de acesso.

(Fonte: https://www.treinaweb.com.br/blog/o-que-e-oauth-2)

Ou seja, o app mobile faz uso de access token para acessar a API do SAProc.

basicamente o recurso que voce usa para acessar um novo serviço sem ter que fazer cadastro. Aqueles botões de login com facebook ou Google que a maioria das aplicações possuem

a) O Refresh Token é expirável, geralmente possui um lifetime maior que o Access Token

b) GAB

c) Quem hospeda a API é o Resource Server

d) Não existe "Token Endpoint"

e) Quem gera as autorizações é o Authorization Server

Gabarito: B

b-

API tokens in the context of RESTful APIs are cryptographic keys or strings generated by the server and provided to clients for authentication and authorization purposes. These tokens are typically imbued with a certain degree of complexity through the utilization of advanced encryption algorithms, such as HMAC (Hash-based Message Authentication Code) or JWT (JSON Web Tokens), to obfuscate sensitive information and thwart unauthorized access.

API tokens serve as a digital representation of a client's identity or access rights, augmenting the security posture of the API by necessitating that any incoming requests from clients be accompanied by a valid token. This process is often part of a broader mechanism called Token-based Authentication, which mandates the inclusion of the token within the HTTP headers of the request, typically under the "Authorization" field, either as a Bearer token or in another format, depending on the specific authentication scheme employed.