Sumário

O presente documento analisa os diversos padrões e especificações utilizados no Open Banking Brasil e apresenta as informações passíveis de serem trafegadas que demandem a criptografia do ID_TOKEN, bem como as formas como essa criptografia deve ocorrer.

Fontes de informações sensíveis

O ID_TOKEN pode possuir Claims que contenham informações pessoais, que devem ser protegidas contra acesso não autorizado. Estas Claims são relacionadas na tabela abaixo com a indicação do documento que as define. Maiores informações podem ser obtidas na seção "Documentação de Referência", ao final desse documento.

Regras para criptografia

Documentação de Referência

OpenID Connect Core 1.0

ID Token

sub REQUIRED. Subject Identifier. A locally unique and never reassigned identifier within the Issuer for the End-User, which is intended to be consumed by the Client, e.g., 24400320 or AItOawmwtWwcT0k51BayewNvutrJUqsvl6qs7A4. It MUST NOT exceed 255 ASCII characters in length. The sub value is a case sensitive string.

ID Tokens MUST be signed using JWS [JWS] and optionally both signed and then encrypted using JWS [JWS] and JWE [JWE] respectively, thereby providing authentication, integrity, non-repudiation, and optionally, confidentiality, per Section 16.14. If the ID Token is encrypted, it MUST be signed then encrypted, with the result being a Nested JWT, as defined in [JWT]. ID Tokens MUST NOT use none as the alg value unless the Response Type used returns no ID Token from the Authorization Endpoint (such as when using the Authorization Code Flow) and the Client explicitly requested the use of none at Registration time.

ID Tokens SHOULD NOT use the JWS or JWE x5u, x5c, jku, or jwk Header Parameter fields. Instead, references to keys used are communicated in advance using Discovery and Registration parameters, per Section 10.

Authentication Request (Hybrid Flow)

Authentication Requests are made as defined in next Section (Authentication Request), except that these Authentication Request parameters are used as follows:

Authentication Request

This specification also defines the following request parameters: id_token_hint OPTIONAL. ID Token previously issued by the Authorization Server being passed as a hint about the End-User's current or past authenticated session with the Client. If the End-User identified by the ID Token is logged in or is logged in by the request, then the Authorization Server returns a positive response; otherwise, it SHOULD return an error, such as login_required. When possible, an id_token_hint SHOULD be present when prompt=none is used and an invalid_request error MAY be returned if it is not; however, the server SHOULD respond successfully when possible, even if it is not present. The Authorization Server need not be listed as an audience of the ID Token when it is used as an id_token_hint value. If the ID Token received by the RP from the OP is encrypted, to use it as an id_token_hint, the Client MUST decrypt the signed ID Token contained within the encrypted ID Token. The Client MAY re-encrypt the signed ID token to the Authentication Server using a key that enables the server to decrypt the ID Token, and use the re-encrypted ID token as the id_token_hint value.

Authentication Request Validation (Hybrid Flow)

When using the Hybrid Flow, the Authentication Request is validated in the same manner as for the Authorization Code Flow, as defined in next Section (Authentication Request Validation).

Authentication Request Validation

If the sub (subject) Claim is requested with a specific value for the ID Token, the Authorization Server MUST only send a positive response if the End-User identified by that sub value has an active session with the Authorization Server or has been Authenticated as a result of the request. The Authorization Server MUST NOT reply with an ID Token or Access Token for a different user, even if they have an active session with the Authorization Server. Such a request can be made either using an id_token_hint parameter or by requesting a specific Claim Value as described in Section 5.5.1, if the claims parameter is supported by the implementation.

ID Token Validation

When using the Hybrid Flow, the contents of an ID Token returned from the Authorization Endpoint MUST be validated in the same manner as for the Implicit Flow, as defined in Section below (ID Token Validation).

ID Token Validation

When using the Implicit Flow, the contents of the ID Token MUST be validated in the same manner as for the Authorization Code Flow, as defined in next Section (ID Token Validation), with the exception of the differences specified in this section.

ID Token Validation

1. If the ID Token is encrypted, decrypt it using the keys and algorithms that the Client specified during Registration that the OP was to use to encrypt the ID Token. If encryption was negotiated with the OP at Registration time and the ID Token is not encrypted, the RP SHOULD reject it.

ID Token

When using the Hybrid Flow, the contents of an ID Token returned from the Token Endpoint are the same as for an ID Token returned from the Authorization Endpoint, as defined in next Section (ID Token Validation) , with the exception of the differences specified in this section.

If an ID Token is returned from both the Authorization Endpoint and from the Token Endpoint, which is the case for the response_type values code id_token and code id_token token, the iss and sub Claim Values MUST be identical in both ID Tokens. All Claims about the Authentication event present in either SHOULD be present in both. If either ID Token contains Claims about the End-User, any that are present in both SHOULD have the same values in both. Note that the OP MAY choose to return fewer Claims about the End-User from the Authorization Endpoint, for instance, for privacy reasons. The at_hash and c_hash Claims MAY be omitted from the ID Token returned from the Token Endpoint even when these Claims are present in the ID Token returned from the Authorization Endpoint, because the ID Token and Access Token values returned from the Token Endpoint are already cryptographically bound together by the TLS encryption performed by the Token Endpoint.

ID Token Validation

When using the Hybrid Flow, the contents of an ID Token returned from the Token Endpoint MUST be validated in the same manner as for the Authorization Code Flow, as defined in the Following Section.

Standard Claims

This specification defines a set of standard Claims. They can be requested to be returned either in the UserInfo Response, per Section 5.3.2, or in the ID Token Section

Financial-grade API Security Profile 1.0 - Part 1: Baseline

Returning authenticated user's identifier

1. shall issue an ID Token in the token response when openid was included in the requested scope as in Section 3.1.3.3 of OIDC with its sub value corresponding to the authenticated user and optional acr value in ID Token.

Authorization request and response

In this document, the authorization request is not encrypted. Thus, it is possible to leak the information contained if the web browser is compromised. Authorization response can be encrypted as ID Token can be encrypted.

Privacy considerations

Introduction

Privacy threats to OAuth and OpenID Connect implementations include the following:

• (User tracking by RPs) Two or more RPs correlating access tokens or ID Tokens to track users.

• (Attacker observing personal data in authorization request) Authorization request might contain personal data. This can be observed by an attacker. These threats can be mitigated by choosing appropriate options in OAuth or OpenID, or by introducing some operational rules. For example, "Attacker observing personal data in authorization request" can be mitigated by either using authorization request by reference using request_uri or by encrypting the request object. Similarly, "Attacker observing personal data in authorization endpoint response" can be mitigated by encrypting the ID Token or JARM response.

Financial-grade API Security Profile 1.0 - Part 2: Advanced

ID Token as detached signature

In addition, if the response_type value code id_token is used, the authorization server 3. should support signed and encrypted ID Tokens; 6. should not return sensitive PII in the ID Token in the authorization response, but if it needs to, then it should encrypt the ID Token. NOTE: The authorization server may return more claims in the ID Token from the token endpoint than in the one from the authorization response

Confidential client

ID Token as detached signature

In addition, if the response_type value code id_token is used, the client 5. shall support both signed and signed & encrypted ID Tokens.

Open Banking Brasil Financial-grade API Security Profile 1.0 Implementers Draft 3

Servidor de Autorização

1. deve suportar os parâmetros claims como definido no item 5.5 do OpenID Connect Core

2. deve suportar o atributo claim padrão oidc "cpf" conforme definido no item deste documento

Token de ID como assinatura separada

1. não deveria retornar Informação de Identificação Pessoal (PII) confidenciais no token de ID na resposta de autorização, mas se for necessário, então ele deve criptografar o token de ID .

Solicitando uma "claim" cpf

Este perfil define "cpf" como uma nova claim padrão de acordo com cláusula 5.1 OIDC

O número do CPF (Cadastro de Pessoas Físicas, [sepeˈɛfi]; português para "Registro de Pessoas Físicas") é o cadastro de pessoa física brasileira. Este número é atribuído pela Receita Federal Brasileira para brasileiros e estrangeiros residentes que, direta ou indiretamente, pagar impostos no Brasil.

No modelo de identidade do Open Banking Brasil, o cpf é uma string composta por números 11 caracteres de comprimento e podem começar com 0.

Se a Claim cpf for solicitada como essencial para constar no ID token ou na resposta ao endpoint de UserInfo e na solicitação constar no parâmetro value com determinado CPF exigido, o Authorization Server DEVE retornar no atributo cpf o valor que corresponda ao da solicitação.

Se a Claim cpf for solicitada como essencial para constar no ID Token ou na resposta no endpoint de UserInfo, o Authorization Server deve retornar no atributo cpf o valor com o CPF do usuário autenticado.

Se a Claim cpf indicada como essencial não puder ser preenchida ou não for compatível com o requisito, o Authorization Server deve tratar a solicitação como uma tentativa de autenticação com falha.

Nome: cpf, Tipo: String, Regex: 'd{11}$'