O desenvolvedor Jacó está implementando a aplicação AppJus. A autenticação dos usuários na AppJus utiliza o protocolo OpenID Connect. A fim de constatar o recebimento do ID Token, Jacó criou na AppJus a tela DbgAuth, onde devem ser exibidos o identificador único atribuído pelo provedor de OpenID ao usuário autenticado e a data-hora de emissão do ID Token. Sendo assim, para exibir a DbgAuth, Jacó deve extrair do ID Token os valores dos atributos:
- A)iss e sub;
Errada, porque iss identifica o emissor do token, e não o usuário autenticado.
- B)iat e sub;
Certa, porque sub traz o identificador único do usuário e iat informa a data-hora de emissão do ID Token.
- C)iss e iat;
Errada, porque iss aponta para o provedor emissor, não para o usuário.
- D)acr e iat;
Errada, porque acr trata do nível ou contexto de autenticação, e não do identificador do usuário.
- E)iss e acr.
Errada, porque iss é o emissor e acr não representa a data de emissão do token.
Gabarito: B
No OpenID Connect, o ID Token carrega algumas informações básicas sobre a autenticação, e é nele que você encontra os campos que interessam aqui. Quando a questão pede o identificador único do usuário atribuído pelo provedor, ela está falando do subject, o famoso atributo sub. Já a data e hora em que o token foi emitido aparecem no campo iat, de issued at, que informa justamente o instante de emissão do token. Pense assim: sub diz quem é o usuário dentro daquele emissor, e iat diz quando o token nasceu. É uma combinação bem típica em provas, porque a banca gosta de misturar campos de identidade com campos de metadados do token. O iss, por exemplo, identifica o emissor do token, não o usuário. Já acr está ligado ao contexto ou classe de autenticação, não à data de emissão. Então, para exibir a tela DbgAuth com o identificador único do usuário e a data-hora de emissão do ID Token, a aplicação deve ler sub e iat. Essa leitura bate com a especificação do OpenID Connect, que define esses claims no ID Token.