ES2609836B2 - Procedure and system for the validation of a request for authentication / authorization of a user - Google Patents

Abstract

System and procedure for the validation of a request for authentication / authorization of a user (EU). It includes receiving, from a service provider (RP), a request for authentication / authorization from a user (EU); extract the dynamic context (C) from the request received from the service provider (RP), where said context (C) comprises user-defined rules (EU) for its identity (ID); extract the profile (P) associated with said identity (ID), where said profile (P) contains information extracted from historical contexts associated with requests and past transactions made for said identity (ID); verify compliance with the rules included in context (C) by the request received to establish the validation of said request, and decide whether to raise the level of security (LoA) associated with said request; Send to the service provider (RP) information about the elevation level of security (LoA).

Description

5

10

fifteen

twenty

25

30

PROCEDURE AND SYSTEM FOR THE VALIDATION OF A REQUEST FOR AUTHENTICATION / AUTHORIZATION OF A USER

DESCRIPTION

Technical Field of the Invention

The present invention belongs to the field of digital identity management.

Background of the invention or State of the Art

Previously, a small definition of the terminology used is given:

IAAA: Identification, Authentication, Authorization and Accountability. In Spanish: Identification, Authentication, Authorization and Traceability.

RP: Relying Party that offers some type of asset, resource, service or application and that relies on an external identity provider to manage the IAAA procedures of its users.

EU: End User or end user who wishes to access the services offered by the RP and uses an IAAA procedure based on the telephone number and / or the SIM card of a terminal (T), that is, provided by a Telecommunications operator

IP: Identity Provider, entity in which the user initially performs the IAAA procedure. Both the PR and the EU rely on this entity to handle authentication and authorization requests. For this invention, it is a telecommunications operator since it is taken into account that the identity is based on the telephone number and / or the SIM card.

Authorization server, Token endpoint and User info endpoint: Systems that allow the authentication or IP operator to perform the authentication procedure using OpenIDConnect / MobileConnect, that is, basing the identities on the telephone number and / or the SIM card.

LoA: Level of Assurance or security level of an IAAA procedure, indicates the number and type of authentication factors to be used.

5

10

fifteen

twenty

25

30

35

Usually, digital identity management is associated with two types of functionalities: identification / authentication and authorization. That is, this type of management allows, in a digital context, to verify that an individual is who he claims to be but also to authorize or not, depending on the verified identity, access to different assets to perform certain tasks or not. Currently it seems that a consensus has been reached in the industry, according to which the best option is to use federated solutions and implement authentication schemes over authorization (OpenIDConnect specification, which implements OpenID over OAUth).

In addition, digital identity management schemes have evolved towards the use of mobile devices with a SIM card inserted in the terminal (T) and the telephone number associated with it, allowing a ubiquitous use of identity (MobileConnect specification based on OpenIDConnect). That is, schemes that are integrated with the devices used by users intelligently, making authentication and authorization procedures not perceived as differentiated, complex and / or expensive processes, but that they occur in a natural, simple and simple way. the most automatic and transparent way possible for users. All this while maintaining adequate levels of security and control.

It should be borne in mind that the telephone number is associated more and more closely with a specific individual who maintains it for a long period of time. In addition, this association is usually contractual (involving some type of government identification and subscriber banking information) and involves a company, the telecom operator, which is stable, is subject to strong regulations supervised by national and international external agencies and is obliged to follow standards that guarantee interoperability.

Different works are pointing out ways to improve the security of these schemes based on OpenIDConnect / MobileConnect by adding new authentication factors to their mode of operation or making them more complex (less predictable, more difficult to guess, intercept and / or generate).

The problem with these improvements is that they add complexity to the IAAA procedures by increasing security levels, consuming resources on the user's device (battery and network bandwidth), forcing this user to take part in the process (activating the geo-location of your device, photographing your face or scanning a QR code, for example) and consuming your time and effort (sometimes requiring technical knowledge that you may not have), and sometimes incurring considerable latencies.

5

10

fifteen

twenty

25

30

Brief Description of the Invention

The object of the present invention is a procedure and a system for the validation of a request.

Regarding the procedure for the validation of a request for authentication / authorization of a user, this includes the steps of: receiving, from a service provider, a request for authentication / authorization of a user; extract the dynamic context of the request received from the service provider, where said context comprises user-defined rules for its identity; extract the profile associated with said identity, where said profile contains information extracted from historical contexts associated with requests and past transactions made from said identity; verify compliance with the rules included in the context by the request received to establish the validation of said request, and decide whether to raise the level of security associated with said request; Send information to the service provider about the validation of the authentication / authorization request and about the decision to raise the security level.

Optionally, the user's authentication / authorization request is stored to allow traceability and to update the profile associated with the identity.

Optionally, a subset of rules is user defined.

Optionally, a subset of rules is defined by the telecommunications operator.

Optionally, if the degree of compliance with the rules defined by the user is lower than a first confidence threshold, the validation is negative and is terminated.

Alternatively, if the degree of compliance with the rules defined by the user is greater than a first confidence threshold, and if the degree of compliance with the rules defined by the telecommunications operator is less than a second confidence threshold, the validation is negative and it ends.

Alternatively, if the degree of compliance with the user-defined rules (EU) is greater than a first confidence threshold, and if the degree of compliance with the rules defined by the telecommunications operator is greater than a second confidence threshold, and if the degree of similarity of the authentication / authorization request with the user's profile (P) is lower than a third threshold, the validation is inconclusive and the security level (LoA) is raised for the

5

10

fifteen

twenty

25

30

authentication / authorization later. Optionally, in this case the RP is notified of the new security level.

Alternatively, if the degree of compliance with the rules defined by the user is greater than a first confidence threshold, and if the degree of compliance with the rules defined by the telecommunications operator is greater than a second confidence threshold, and if the degree of similarity of the authentication / authorization request with the user's profile is equal to or greater than a third threshold, the validation is positive and the authentication / authorization is then proceeded directly.

Optionally, information about the authentication / authorization validation and the established security level can also be sent to the user terminal.

With respect to the system for the validation of a request for authentication / authorization of a user, said system includes reception means for receiving and registering an authentication / authorization request issued by a service provider in response to a procedure initiated by a user from a device; extraction means to extract the dynamic context of the received request, where said context comprises user defined rules and filters for its identity; means of verification to validate the request received by the reception means against its dynamic context and the profile obtained from the means of

extraction, adapting the level of security of the subsequent procedure of

authentication / authorization based on the result of the validation.

Advantageously, the present invention allows validating a request for

Authentication / authorization based on the phone number and / or the SIM card before performing the full authentication / authorization procedure. It is possible to improve the safety and efficiency in the use of resources, both the user (EU) and the telecommunications operator (IP), so that in the case of requests not validated (classified as unsafe), not even Try to perform the authentication / authorization procedure. This is explained in more detail below.

If the previous validation result is positive, the authentication / authorization procedure is carried out with the scheme that was being

using by the telecommunications operator (e.g. OpenIDConnect / MobileConnect).

If the previous validation result is negative, it is avoided to continue with the authentication / authorization procedure and the request received is ignored. With

5

10

fifteen

twenty

25

30

this avoids the consumption of resources in the device, of time and effort on the part of the user and the associated latency.

In the event that the result of prior validation is inconclusive, the security level of the subsequent authentication / authorization is increased when the request is suspicious or suspicious (that is, if the authentication / authorization procedure is decided to continue, but there is suspicions about its origin, consistency and legitimacy, the LoA is increased).

A MID proxy is proposed to be available in front of the systems that perform the authentication / authorization in the telecommunications operators to carry out the proposed validation without modifying or altering these systems and the authentication procedures that they were already using (eg OpenIDConnect / MobileConnect).

Advantageously, the proposed validation does not require the user to install any type of application on their mobile device. Simply hire the service associated with your operator. This service is called MIDaaS (Mobiquitous Identity as a Service) from now on.

The validation procedure for authentication / authorization requests is based on two fundamental aspects:

Traceability: The real-time monitoring and activity log of all transactions carried out with a digital identity, so that a complete record of all of them can be stored from which the pattern of behavior considered usual for that identity can be extracted (profile from the EU). Some of the attributes that characterize this pattern (although you can add as many as you want) are: RP origin of the authentication request, information associated with this RP (type of asset, resource, service or application offered, activity sector, name domain name, geographic location / language, IP address, etc.), time of the authentication request, specified expiration time, required LoA (security level), geo-location of the EU device, additional information about the EU associated with this request (access device, access network, IP address, etc.) and result of the validation procedure.

The dynamic context of the request: All information about the request that can help the telecommunications operator to validate the authentication / authorization request before having to process it. These attributes are, for each particular request, very similar to those recorded in the

5

10

fifteen

twenty

25

30

pattern associated with each identity, therefore RP origin of the authentication request, information associated with this RP, time of the authentication request, specified expiration time, LoA required, geo-location of the device of the EU, additional information about the EU.

In addition, this context also includes dynamic rules or filters specified by the user in each moment or case. For example, the context of an authentication request may include a filter that the EU has activated to indicate that no authentication requests are processed for social networks between 23.00 and 7.00. Or that authentication requests are not processed for e-commerce sites with .cn domain.

Brief description of the figures

Figure 1: Flow according to prior art to add identification / authentication to an authorization (OpenIDConnect / MobileConnect).

Figure 2: Flow according to the invention when the result of the validation is positive.

Figure 3: Flow according to the invention when the result of the validation is inconclusive.

Figure 4: Flow according to the invention when the result of the validation is negative.

Figure 5: Detail of step 3 of Figures 2 to 4 with the validation flow performed by the MID proxy according to the invention.

Figure 6: Flow diagram of the validation procedure according to the invention.

Figure 7: Block diagram according to the invention for the MID proxy.

Detailed description of the invention

For clarification purposes and referring to the previous figures, several examples of embodiment are set forth. These examples are not restrictive about the scope of the present invention.

Figure 1 shows the known scheme in a basic use case according to a current technique (OpenIDConect 1.0 / MobileConnect over OAuth 2.0). In this way, an RP is allowed to verify the identity of a user through a procedure of

5

10

fifteen

twenty

25

30

35

authentication / authorization performed by the Authorization Server itself, as well as obtaining basic information associated with its profile (name, surname, email, etc.). As you can see, a Token ID is added to the Access Token used by OAuth to manage authorization. Thanks to this scheme, telecommunications operators can become identity providers based on the telephone number and / or the SIM card. To increase the level of security of the IAAA procedure, new authentication factors that require the active intervention of the user could be added, forcing this user to take part in the process (activating the geo-location of his device, photographing his face or scanning a QR code, for example). All of them also consume resources on the user's device (battery and network bandwidth), so the scenarios in which they can be used are severely restricted.

A flow chart with different steps can be seen in Figures 2-4. Then, we will comment on each one.

Step 1: The RP creates the authentication / authorization request to perform IAAA procedure with the EU (usually because the EU will have requested from some device, access an asset, resource, application or service that the RP previously provides).

Step 2: The RP launches this authentication / authorization request to the MID proxy on the IP. Step 3: This proxy performs the validation procedure object of this invention (described later in detail), and after this validation, it registers it along with its result to track the events associated with the identity of the EU and sends it to the Authorization Server

Step 4: What happens next depends on the result of the validation procedure:

Option 4.1: If the result of the validation has been positive, the MIDProxy allows the IAAA procedure to begin normally, by resending the authentication / authorization request to the Authorization Server. This is shown in Figure 2. Option 4.2: If the result of the validation has been inconclusive, the MIDProxy increases the Level of Assurance (LoA) before allowing the IAAA procedure to begin, resending the authentication / authorization request to the Authorization Server. It also notifies the RP of the new value of the LoA so that the subsequent authentication / authorization procedure is carried out without problems. This is shown in figure 3.

5

10

fifteen

twenty

25

30

35

Option 4.3: If the result of the validation has been negative, simply notify the EU and the PR and the IAAA procedure that is aborted (although registered for subsequent checks) is not performed. This is shown in Figure 4. Step 5: In the first two options (4.1 and 4.2), the IAAA procedure continues normally so that the EU provides its consent for this process to the MID proxy.

Step 6: The MID proxy registers the consent and sends it to the Authorization Server.

Step 7: The Authorization server generates an authorization code for the EU and sends it to the MID proxy to be registered.

Step 8: The MID proxy sends it to the EU.

Step 9: The EU submits this authorization code to the PR.

Step 10: The RP presents this authorization code in the IP endpoint Token to obtain the access and identity tokens (Access Token and ID Token respectively). Step 11: The token endpoint sends these tokens to the RP.

Step 12: The RP validates the Token ID, so that the authentication / authorization procedure is terminated and the EU can access the resources that it had initially requested, leaving the entire IAAA procedure registered in the MID proxy.

Step 13: Optionally the RP can use the Access Token to go to the MID proxy and request additional information about the EU, static (User Info) or dynamic (Context).

Step 14: This request is registered in the MID proxy and redirected to the User Info + Context endpoint.

Step 15: This endpoint responds to the MID proxy with the requested information.

Step 16: The MID proxy records this response and redirects it to the RP.

Figure 5 specifies in detail the flow of the validation procedure performed by the MID proxy and which has been summarized as "validation and registration" in step 3 of Figures 2, 3 and 4.

As you can see this proxy is responsible for carrying out the validation procedure, so it brings together three main tasks characteristic of the scheme proposed in this invention:

1. Perform the transaction log that contains data on any action that occurs regarding the identity of a EU, which allows traceability to be offered both to the EU (of its identity) and to the RP (of the identities of all its users) . The "Transaction Log" is the element that stores the data associated with all requests (all attributes of authentication / authorization requests that

5

10

fifteen

twenty

25

30

35

they have already been listed), regardless of their final result and that allows other modules or components to summarize in a habitual behavior pattern what is considered "normal" for a specific identity. The extraction of characteristics to summarize this pattern can be done with any of the traditional methods and algorithms that are used in pattern recognition.

2. Obtain the context of the request, taking into account the dynamic factors that are considered appropriate, both for the EU and for the PR, on the basis of which it is possible to discriminate between consistent and non-consistent requests, that is, between requests that are they are considered safe and are validated because they can be successfully completed or requests, doubtful (in which the level of security required in subsequent authentication is increased) or completely insecure (which are aborted). The "Context Server" is the element responsible for enriching the request with all relevant context information (also mentioned above), and this includes the rules or filters that are allowed to define the EU itself in relation to their identities.

3. Contrast the enriched petition with the personal criteria established by the EU and with general validation criteria (those that all must request must comply to be consistent).

to. Personal validation criteria: It is necessary to check whether in the context of the request any rule or filter of those specified by the EU is incorporated. As an example of a personal validation criterion, a request from a certain domain name, in a certain time slot or requesting a specific authorization for certain type of assets, resources, services or applications can be directly dismissed, so the result of the validation already It would be negative.

b. General validation criteria: If the personal validation criteria are passed, it is necessary to apply the general ones.

First, general validation criteria specified by the IP are applied to distinguish between consistent and non-consistent requests. As an example of a general validation criterion, a request that is currently classified as consistent (not affected by any EU rule) but in which the location of the RP service affirms the position of the EU access device is in Rome, while that the independent location of the EU reveals that its mobile device is in London (the machine with which the RP website is navigated and the mobile terminal may be independent, but must be physically close unless otherwise indicated ), would end with a negative result for validation. Finally, if all the above criteria have been met successfully, once

5

10

fifteen

twenty

25

30

Having extracted the characteristics of the authentication / authorization request and its context (with the aforementioned attributes), they can be compared with the behavior pattern considered usual for that digital identity (EU profile).

i. With a sufficient level of coincidence, it ends with a positive validation. The threshold for the level of match will depend on the level of security required by each user.

ii. With a level of coincidence below this threshold, the authentication / authorization procedure is allowed but its security level is increased, that is, the LoA (result of the inconclusive validation, as there are doubts or suspicions, continues with the IAAA procedure but increasing the security requirements).

EXAMPLE 1

In this example, an EU that has the MIDaaS service activated visits from its laptop a website of an RP that offers a service in which it is interested. As usual, the website requires the EU to identify and authenticate before accessing the service.

The EU chooses to authenticate through the IP (simply providing their telephone number), obtaining the PR personal and context data of the EU that it authorizes to obtain without the need for the EU to enter any other information.

Assume four scenarios:

1. The request for authentication / authorization of the RP for this EU is registered in the MID Proxy. Next, the context of this request is retrieved. No personal criteria of the EU suggest that it is a non-consistent request. There is also no problem with the general validation criteria: the request falls within the normal behavior pattern of the EU (I had previously used the services of this PR at a similar time and location) and there is no other particular relevance. The result of the validation is positive and the user is authenticated with the LoA initially required. The EU authenticates successfully.

2. The request for authentication / authorization of the PR for this EU is registered in the MID Proxy. Next, the context of this request is retrieved. No personal criteria of the EU suggest that it is a non-consistent request. A suspicion arises when applying the general criteria: the request does not enter at all within the normal behavior pattern of the EU: I had never used the services of this PR, it does not usually access this type of services at this time, it is a domain in an unusual geographical area, etc. The result of the validation is no

5

10

fifteen

twenty

25

30

35

conclusive and we proceed to authenticate the user with a LoA higher than initially required, so more authentication factors are needed than would have been used normally. The EU is authenticated successfully and its usual behavior pattern is updated with this request. If the EU failed to complete the authentication / authorization procedure successfully, an impersonation would have been avoided by detecting a request that does not fit the user's usual behavior profile.

3. The request for authentication / authorization of the RP for this EU is registered in the MID Proxy. Next, the context of this request is retrieved. No personal criteria of the EU suggest that it is a non-consistent request. A suspicion arises when applying the general criteria: the distance between the device (a computer or a tablet, for example) used by the EU to access the RP and its mobile terminal (the one containing the SIM card) is hundreds of kilometers ( and the EU has not updated its personal validation criteria to notify of this particular). The validation has a negative result and the authentication / authorization procedure is not even launched. A possible impersonation has been avoided, since a criterion that is considered essential to catalog the request as consistent is not met. Everything is recorded so that both the IP and the EU can analyze the case later and take the necessary actions.

4. The request for authentication / authorization of the RP for this EU is registered in the MID Proxy. Next, the context of this request is retrieved. A personal criterion of the EU is detected that allows to catalog the request as not consistent immediately: it is not allowed to perform authentication for this type of service in this time slot. The validation has a negative result and the authentication / authorization procedure is not even launched. Possible identity theft has been avoided. Everything is recorded so that the case can be analyzed later and take the necessary actions.

EXAMPLE 2

For years there have been telecommunications operators that offer the possibility of making payments through mobile terminals and operators, without the need for any other element. This practice is often called telco billing and allows a mobile phone subscriber to upload their purchases to their account through their telecommunications operator.

In this example, a company allows its employees (EU) to make payments through its corporate mobile terminal to avoid the handling of corporate bank cards.

5

10

fifteen

twenty

25

30

35

Assume that one of these employees tries to make a mobile payment in an establishment (RP) within their working hours, within the geographical scope of their office and for an amount authorized by their company. The request for authentication / authorization of the RP for this EU is registered in the MID Proxy. Next, the context of this request is retrieved. No personal criteria of the EU (in this case these criteria are set by your company, which is the one that has contracted the line) suggests that it is a non-consistent request. There is also no problem with the general validation criteria: the request falls within the normal behavior pattern of the EU (I had previously used the services of this PR at a similar time and location) and there is no other particular relevance. The result of the validation is positive and the user is authenticated with the LoA initially required. The EU is authenticated successfully and payment is authorized.

Now let's assume a second scenario in which the employee has lost his mobile device or has been stolen. Let's also assume that you had all your passwords pointed to in a file stored on the device. If a person in possession of the device and passwords attempts to make a payment before the company cancels the SIM card of the device, the following would happen: the request for authentication / authorization of the RP for this false EU is registered in the MID Proxy. Next, the context of this request is retrieved.

First of all if the payment is not within the schedule, geographical scope or amount authorized by the company through the personal validation criteria, the authentication / authorization request will not be processed and an impersonation will have been avoided. If these criteria do not classify the request as non-consistent, they are likely to be general validation (if the payment of the standard of normal behavior of the EU or the rest of the criteria that apply) is passed to make it inconsistent, aborting it or at least, increasing the LoA and thus, not even performing authentication / authorization or performing it with a greater number of authentication factors (that is, with a much greater probability of avoiding impersonation).

A flow diagram of the validation procedure according to the invention (600) can be seen in Figure 6. The procedure begins upon receiving the authentication / authorization request issued by an RP (in response to a user service request). Then, the authentication / authorization request (601) is registered and in a next step, the dynamic context (C) of this request (602) is retrieved. The usual behavior profile (P) of the EU involved in the IAAA procedure that is desired to start with this received request (603) is then extracted.

5

10

fifteen

twenty

25

30

35

In the next step (604), the EU rules and filters that were recovered with context C are applied. If this application is not passed because one of these rules or filters is not complied with, this result will be recorded, notified to the parties and to abort the IAAA procedure (605). The result of the validation will be directly NEGATIVE.

If the personal validation criteria are passed for the user, then the request received is compared with what is considered a consistent profile for the IP (606). That is, the general validation criteria of the operator are applied for any request. If these criteria are not met and the similarity with the desired profile is below a threshold, this result will be recorded, notified to the parties and abort the IAAA procedure (605). The result of the validation will be directly NEGATIVE.

If these criteria are passed, the request received is compared with the usual profile for the EU, P (607). If the similarity with this usual profile is below a threshold, the security level of the subsequent authentication / authorization procedure (608) will be increased and this result recorded, notified to the parties and the IAAA procedure continued (609). The result of the validation will be NON-CONCLUDING. If, on the contrary, it is above this threshold, this result will be recorded, notified to the parties and to continue the IAAA procedure (610) as requested from the beginning (without modifying the LoA). The result of the validation will be POSITIVE.

An exemplary embodiment as a system (70) is illustrated in Figure 7. Possible implementation modules are illustrated in the different functional blocks.

In particular, a reception means (71) can be observed that receives, from a service provider (RP) an authentication / authorization request made through a device (D) which can be for example a desktop computer, a tablet or laptop and includes it in a historical transaction log. This corresponds to block 601 of flow chart 600.

It is also necessary a means of extraction (72) that retrieves all the information that constitutes the context of the request (C) and that will be used in the subsequent validation. Therefore, the context of the request itself received from the PR, the context of the EU (through the identity used in its relationship with the PR) and the rules and filters that this user defines for their validation criteria to be applied personal. This corresponds to block 602 of flow chart 600.

Finally, the means of verification (73) receives the authorization / authentication request and its context C and proceeds to evaluate them (blocks of 603 in

forward for flow chart 600). This means is capable of generating a habitual behavior profile (P) for the user from the information stored in the historical transaction log. Applying to the request and context received the rules and filters included in the context itself and comparing its characteristics with this usual behavior profile, this means checks if the request received can proceed, if its level of security (LoA) must be increased or if it should be aborted.

Claims (11)

5 10 fifteen twenty 25 30 35 1. Procedure for the validation of an authentication / authorization request in an identity provider (IP) of a user (EU) who wishes to access a service offered by a service provider (RP), characterized in that it comprises: - extract in the identity provider (IP) the dynamic context (C) of the request received from the service provider (RP), where said context (C) comprises attributes of the request and user-defined rules (EU) in the Identity provider (IP) in which you specify how you want your identity (ID) to be managed; - extract in the identity provider (IP) the profile (P) associated with said identity (ID), where said profile (P) summarizes the past transactions made with said identity (ID), that is, this profile (P) is a pattern of behavior of what can be considered customary for said identity (ID); - extract in the identity provider (IP) the general validation criteria that this provider considers essential to be able to accept an authentication / authorization request; - check if the authentication / authorization request received in the identity provider (IP) complies with the rules defined by the user (EU), with the criteria defined by the identity provider (IP) and if it is also consistent taking into account account profile (P) associated with the user's identity (ID). 2. Method according to claim 1, characterized in that the user authentication / authorization request (EU) is stored to allow traceability and to update the profile (P) associated with the identity (ID), by constructing with each new request a behavior pattern that models the usual activities for that user with that identity (ID). 3. The method according to claim 1 or 2, characterized in that a set of rules is defined by the user (EU) in the identity provider (IP) to specify how he wants his identity (ID) managed and what criteria must be met in order to validate an authentication / authorization request that comes from a device (D) used by it. 4. Method according to any one of claims 1 to 3, characterized in that a set of criteria or rules is defined by the identity provider (IP) 5 10 fifteen twenty 25 30 35 determining the requirements that must be met necessarily before validating an authentication / authorization request that comes from a user (EU). 5. Method according to any one of claims 1 to 4, characterized in that if the degree of compliance with the rules defined by the user (EU) is lower than a first confidence threshold, the authentication / authorization request validation is negative and aborted, so that it is not even processed. Method according to any one of claims 1 to 4, characterized in that: - if the degree of compliance with the user-defined rules (EU) is greater than a first confidence threshold, and - If the degree of compliance with the rules defined by the identity provider (IP) is lower than a second confidence threshold, the authentication / authorization request validation is negative and is aborted, so that it is not even processed. 7. Method according to any one of claims 1 to 4, characterized in that: - if the degree of compliance with the user-defined rules (EU) is greater than a first confidence threshold, and - if the degree of compliance with the rules defined by the identity provider (IP) is greater than a second confidence threshold, and - if the degree of consistency of the authentication / authorization request with the user's profile (P) is lower than a third threshold, the validation is inconclusive and, as a precaution, the security level (LoA) is raised ) for subsequent authentication / authorization, which is processed. 8. The method according to any one of claims 5 to 7, characterized in that the service provider (RP) is notified that the validation of its authentication / authorization request has been inconclusive and therefore will be processed with a level of security (LoA) higher than that indicated in the initial petition or that has been negative and therefore will not be processed at all. 5 10 fifteen twenty 25 30 9. Method according to any one of claims 1 to 7, characterized in that it further comprises sending to the user terminal (T) information on the result of the authentication / authorization request validation if this result has been negative or inconclusive and, in the latter case, the new security level (LoA) established. 10. Method according to any one of claims 1 to 4, characterized in that: - if the degree of compliance with the user-defined rules (EU) is greater than a first confidence threshold, and - if the degree of compliance with the rules defined by the identity provider (IP) is greater than a second confidence threshold, and - if the degree of consistency of the authentication / authorization request with the profile (P) of the user (EU) is equal to or greater than a third threshold, the validation is positive and proceeds directly with the authentication / authorization at the security level (LoA) initially requested by the service provider (RP). 11. System (70) configured for carrying out the method described in claims 1 to 10 characterized in that it comprises: - reception means (71) configured to receive and register an authentication / authorization request launched by a service provider (RP) in response to a transaction initiated by a user (EU) with his identity (ID) from any device ( D); - extraction means (72) configured to extract the dynamic context (C) of the received request, where said context (C) comprises attributes of the request and user-defined rules or filters for its identity (ID); - verification means (73) configured to validate the request received by the reception means (71) taking into account the context (C) extracted from the extraction means (72), the general validation criteria of the identity provider (IP) ) and the profile (P) or behavior pattern that can be modeled from the record made by the receiving means (71); the possible results of this validation being positive, inconclusive or negative.