SAML e OAUTH

SAML

Security Assertion Markup Language

É um Padrão aberto que permite com que provedores de serviços e recursos de identidade passe credenciais de autorização para provedores de serviços. As transações geralmente usam XML. Atualmente na versão 2.0. Cada usuário efetua login uma única vez com o provedor de identificação e, em seguida, o provedor de identificação pode passar os atributos de SAML para o provedor de serviços, que solicita a autorização e a autenticação.

Exemplo: Comunidade Acadêmica Federada (CAFe) da RNP - O CAFe permite login único (SSO) em serviços acadêmicos, como Periódicos CAPES e conferências online.

Definidos em três papéis:

1. O principal (tipicamente um humano);

2. Provedor de Identidades (Identity Provider - IDP);

3. Provedor de Serviços (Service Provider - SP).

Em uma rotina básica de fluxo, tem-se que o Principal, portanto, acessa ou solicita os recursos ao Provedor de Serviços.
Esse então, precisa reconhecer o usuário a partir de sua autorização. Tal processo é feito com uma chamada do Provedor de Serviços ao Provedor de Identidades. Este último, solicita então ao Principal, que insira suas informações de Login e Senha, no mínimo, para ser reconhecido, e liberar acesso aos recursos.

dica

As bancas não costumam cobrar mais do que as informações acima.

OAUTH

Usa JSON, focado em AUTORIZAÇÃO, permitindo acessos limitados a recursos sem expor credenciais. (ex.: login com Google/Facebook).
É uma maneira segura de acessar recursos de terceiros. Atualmente está na versão 2.0.
Esse acesso é concedido mediante a apresentação de um token de acesso, em vez de compartilhar as credenciais do usuário (como nome de usuário e senha), proporcionando uma maneira segura e flexível de autorizar serviços.

Nesse processo autenticação, são definidos 4 papéis básicos:

cuidado

A grande maioria das questões cobra a função de cada papel.

Papéis

1) Resource Owner

• É a pessoa que concede acesso aos seus dados: você.

2) Resource Server

• É o servidor que armazena e protege recursos do usuário, validando tokens de acesso emitidos pelo Authorization Server. Ele garante que apenas clientes autorizados acessem os dados conforme os escopos permitidos.

3) Authorization Server

• O servidor que autentica o usuário e emite tokens de acesso ao client, permitindo que este acesse os recursos do usuário.
• Estes recursos possuem informações dos Resource Owner (Usuários) e expõe no formato de Claims através do Bearer Token.
• Sempre em Https.

4) Client

• A aplicação de terceiros que deseja acessar os recursos do usuário em um servidor de recursos.

O fluxo fuciona da seguinte forma:

1) A aplicação (cliente) solicita autorização para o usuário, para que a aplicação possa interagir e solicitar informações de suas credenciais junto ao provedor de identidade.

2) O Dono do Recurso (resource owner) realiza a autorização.

3) De posse da autorização, esta é encaminhada pelo cliente ao Servidor de Autorização, responsável por viabilizar a passagem das credenciais de acesso aos serviços do provedor.

4) O provedor de credenciais passa o TOKEN, por meio de uma comunicação segura. De posse desse token, a aplicação(client) poderá acessar os recursos do usuário requisitante. Aqui é onde temos a referência ao nosso BEARER TOKEN, que também será utilizado na etapa 5. São as credenciais em si usadas para acessar os recursos protegidos. Os tokens de acesso devem ser lidos e interpretados pelo recurso protegido (Resource Server), que é o público-alvo do token.

5) Passa-se o token aos provedores de serviços que detêm os recursos protegidos dos usuários.

6) As informações e recursos protegidos são compartilhados com o Cliente.

Tipos de Tokens

1) Bearer Tokens

É um tipo de Access Token. São usados para acessar recursos protegidos em nome de um usuário. Neste contexto, o portador apresenta um token válido para obter acesso. Tem como vulnerabilidade ou ponto de atenção o fato de não haver verificação da legitimidade do remetente. Logo, pode ser vulnerável se cair em mãos não autorizadas.

2) Sender-Constrained Tokens (Mutual TLS)

Garantem que o remetente seja legítimo. Para tanto, são vinculados à conexão TLS mútua entre cliente e servidor de autorização. O servidor de recursos verifica o certificado do cliente, o que, na prática, traz uma burocracia para o processo justamente pela necessidade da Infraestrutura de chaves públicas e certificados do cliente. O token inclui o hash do certificado (por exemplo, no JWT). O remetente deve provar que possui a chave privada do certificado vinculado.

3) ID Tokens

Fornecem informações sobre o usuário autenticado.

4) Refresh Tokens

Permitem que os clients obterem novos access tokens sem novo login. São mais duradouros que os access tokens e geralmente são usados para renovar tokens expirados. Isso deve estar expresso ao usuário no ato da autorização.

Concessão

Modos de Concessão

• Authorization Code: Usa um código temporário trocado por um token de acesso, ideal para aplicações web seguras.
• Implicit Grant: O token é enviado diretamente ao cliente sem código intermediário, mas é menos seguro.
• Resource Owner Password: O usuário informa login/senha diretamente ao cliente, sendo menos recomendado por riscos de segurança.
• Client Credentials: O cliente se autentica sem usuário, usado para comunicação entre serviços(entre máquinas).

Requisição no Endpoint do token:

Exemplo:

POST /token HTTP/1.1 Host: auth-tjpa.jus.br Content-Type: application/x-www-form-urlencoded  
grant_type=client_credentials &client_id=client_id &client_secret=client_secret  

Essa requisição utiliza o método POST, que é o método correto para este tipo de operação. A requisição inclui os parâmetros grant_type, client_id e client_secret, que são obrigatórios para o fluxo de client credentials (credenciais do cliente).

Vamos analisar cada um dos parâmetros e o motivo pelo qual eles satisfazem a especificação do OAuth2:

grant_type=client_credentials: Este parâmetro especifica o tipo de concessão de token que está sendo solicitada. No caso, as credenciais do cliente são usadas diretamente para obter o token, sem envolver o usuário.

client_id=client_id: Este é o identificador único do cliente registrado no servidor de autorização. Ele é necessário para identificar qual aplicação está solicitando o token.

client_secret=client_secret: Este é o segredo associado ao client_id. Ele age como uma senha que autentica o cliente no servidor de autorização.

Portanto, a requisição está corretamente formatada e contém os três parâmetros necessários para a obtenção de um token de acesso.