| Índice | ||||
|---|---|---|---|---|
|
Foreword
Este documento também está disponível em Português
...
shall perform client authentication using private_key_jwt;
shall require requests of the type "pushed authorization requests" PAR;
shall distribute discovery metadata (such as the authorization endpoint) via the metadata document as specified in OIDD and [RFC8414] (".well-known");
shall support the claims parameter as defined in clause 5.5 OpenID Connect Core;
shall support the acr "urn:brasil:openbanking:loa2" as defined in section 5.2.2.3;
should support the acr "urn:brasil:openbanking:loa3" as defined in section 5.2.2.3;
shall implement the userinfo endpoint as defined in clause 5.3 OpenID Connect Core;
shall support parameterized OAuth 2.0 resource scope consent as defined in clause 6.3.1 OIDF FAPI WG Lodging Intent Pattern;
may support Financial-grade API: Client Initiated Backchannel Authentication Profile;
(withdrawn temporarily);
shall support refresh tokens;
shall issue access tokens with an expiry no greater than 900 seconds and no less than 300 seconds;
shall always include an acr claim in the id_token;
shall support the response_type value code id_token;
shall not allow refresh token rotation;
shall ensure that, in case of sharing the Authorization Server for other services, in addition to Open Finance, it does not disclose and/or allow the use of non-certified methods in the Open Finance environment;
shall ensure that the settings disclosed to other participants through OpenID Discovery (indicated by the Well-Known file registered in the Directory) are restricted to the operating modes to which the institution has certified;
shall keep in your settings the methods for which there are still active clients;
shall update the records that use non-certified methods, through bilateral treatment between the institutions involved;
shall refuse requests, for the Open Finance environment, that are outside the modes of operation to which the institution has certified its Authorization Server;
the minimum expiration time of request_uri must be 60 seconds;
shall deny all requests without header x-fapi-interaction-id on protected resources endpoints;
must require the use of Proof Key for Code Exchange (PKCE);
must require the use of subject_type “public”;
must require the use of response_mode “fragment”;
shall issue refresh_tokens (JWT or opaque) without an expiration period in scenarios where it is necessary.
...
Each of elements above must be encoded using the Base64url pattern RFC4648 and the elements must be concatenated with "." (JWS Compact Serialization method as defined in RFC7515).
The payload of signed messages (request JWT and response JWT) shall include the following claims as defined at RFC7519:
...
This profile defines OAuth 2.0 dynamic scope "consent" as follows:
string 'consent' ; or ‘recurring-consent’ and
delimiter of a colon ":"; and
Consent API REST Resource Id as returned by a successful creation of Open Finance Consent Resource;
In addition:
the Consent Resource Id must include url safe characters only;
the Consent Resource Id must be namespaced;
the Consent Resource Id must have the properties of a nonce Nonce;
7.1.3. Dynamic Consent Scope Example
...
shall only issue refresh_tokens when linked to an active and valid consent;
Must not issue refresh_token when consent status is "CONSUMED" (for phase 3);
Must issue an access_token through the grant_type client credentials when consent status is "CONSUMED"(for phase 3).
shall only share access to resources when presented access_token linked to an active consent and with the status "AUTHORISED“. For tokens generated with the scope: payments or recurring-payments, the status of the consent will not be validated.
In the scenario of receiving an invalid token, status code 401 should be returned.
shall revoke refresh tokens and, access tokens where aplicable, when the linked Consent Resource is deleted;
shall ensure access tokens are issued with sufficient scope necessary for access to data specified in the Permission element of a linked Consent Resource object;
shall not reject an authorisation request requesting scopes broader than those necessary to access data specified in the Permissions element of a linked Consent Resource object;
may reduce requested scope to a level sufficient to enable access to data resources specified in the Permissions element of a linked Consent Resource object;
shall retain a complete audit history of the consent resource in accordance with current Central Bank brazilian regulation;
shall return authentication failure and return code _accessdenied in the error parameter (as specified in section 4.1.2.1 of RFC6749) if the CPF of the authenticated user is not the same as indicated in the loggedUser element of the Consent Resource Object;
shall return authentication failure and return code _accessdenied in the error parameter (as specified in section 4.1.2.1 of RFC6749) if the businessEntity element has not been populated in the related Consent Resource Object and the user has selected or authenticated by using a credential related to a business account;
an autenticated or selected business account's CNPJ must match the value present in the businessEntity element of the Consent Resource Object. In case of divergence authorization server shall return authentication failure and return code access_denied in the error parameter (as specified in section 4.1.2.1 of RFC6749);
shall ensure refresh_token expiration time is at least equal to the linked consent resource expiration time.
...