Methods, servers and systems for supporting authentication

Abstract

A method performed by a second server (220) for supporting authentication to a session The method comprises receiving (410), from a first server (210), a first multi-factor authentication (MFA) request for performing a part of a second part of a MFA of a first user (100), wherein the first MFA request comprises a first token relating to a group of users and to the session, generating (420) a second token comprising a user identity of the first user (100), sending (430), to the first server (210), a third token, comprising the first token and the second token, receiving (440), from the first server (210), a second MFA request for performing the part of the second part of the MFA of a second user (110), updating (450) the second token, and sending (460), to the first server (210), an updated third token.

Description

[0001] METHODS, SERVERS AND SYSTEMS FOR SUPPORTING AUTHENTICATION

[0002] TECHNICAL FIELD

[0003] The present disclosure relates to a first server and a second server, and methods performed by the first server and the second server. Related systems, a computer program, and a computer readable storage medium are also disclosed.

[0004] BACKGROUND

[0005] Applying cloud-native technology to isolated systems such as mobile technology may lead to a contrast between security reasons mandatory for the cloud-native technology and consolidated ways of working in the isolated systems, as for example, management of a network node connected on a dedicated communication channel or a shared usage of a digital instrument. Using cloud-native technology requires a fast, scalable, flexible, easy to use and automatic security system for a cloud-native application.

[0006] An authentication method in an authentication system, such as a security system in a cloud-native application, may control access to, e.g., cloud data and resources. The use of multi-factor authentication (MFA) protocols in an authentication system provides an increased security level according to, for example, National Institute of Standards and Technology (NIST) statements in comparison to a single factor authentication system, such as for example a usage of a password for authenticating users.

[0007] An authentication system comprising the use of MFA protocols, requires at least two distinct authentication factors for successful authentication. MFA can be performed using a server, such as a multi-factor authenticator or by a combination of authenticator servers that provide different authentication factors. The authentication factors may be a password, an identity batch, a cryptographic key, a fingerprint, a completely automated public turning test to tell computers and humans apart (CAPTCHA), a code, or biometric data. The MFA is bound to an individual user. An example of an authentication system which uses MFA is two-factor authentication using a password and a biometric authentication. Authentication using a biometric factor based on biometric data is a security process that relies on the unique biological characteristics of an individual user for verification. Systems such as cloud native applications, often require changes of user identities for access to, e.g., the same resources. Anyhow, in the MFA procedure there is a strict connection between the individual user and its authentication in multiple user scenarios.

[0008] In published technology, propositions are made to delegate or impersonate the authentication. A common use case may be for example a Security Token Service for allowing a resource server Alpha to make calls to a backend service Charlie on behalf of the requesting user Bravo. Depending on the local site policy and authorization infrastructure, it may be desirable for Alpha to use its own credentials to access Charlie along with an annotation of a form that indicates that Alpha is acting on behalf of Bravo ("delegation") or for Alpha to be granted a limited access credential to Charlie but that continues to identify Bravo as the authorized entity ("impersonation").

[0009] Figure 1 illustrates a flowchart relating to an MFA flow of a first user 100 and a second user 110 who use an authentication system to get access to a computer system, wherein the first user 100 and second user 110 access as a group of users with similar or the same function, such as acting on the same resources in the computer system or having the same permissions on the computer system. In a step 101 , the first user 100 provides the user identity of the first user 100, for example by providing an initial token. In a step 102, a first factor authentication is performed for the user identity of the first user 100, e.g., using a credential of the first user 100. In a step 103, authentication is performed using the second factor, for example a biometric factor based on biometric data of the first user 100. In a step 104, the first user 100 is granted access to a first session related to the computer system. The second user 110 now wishes to take over handling of the computer system. In this case, in a step 111 , the second user 110 provides the user identity of the second user 110, for example by providing a second token. In a step 112, the first factor authentication of the second user 110 is performed. In a step 113, the second factor authentication of the second user 110 is performed. Step 114 comprises granting the second user 110 access to a second session. When the second user 110 starts a second session, the computer system does not attribute the same role to the second user 110 as to the first user 100. In an example, the first user 100 must log out of the computer system and the second user 110 must log in again to “take over”. There is no difference in the authentication process if the second user 110 logs in, whereby the second user 110 has similar functions to the first user 100, or if a third user logs in with other functions who is not part of the user group. Identification of the individual user, i.e. , the first and second user 110, must be performed on a per-user basis each time when a takeover occurs in order to maintain security using MFA of individual users accessing different sessions on the same system, even if the individual users are part of a user group, such as users accessing the same system or users working with the same permissions on the system. This can lead to an interruption in a continuous workflow during the takeover and to additional overheads.

[0010] US 10715564 B2 refers to an identity cloud service that implements a microservices based architecture and provides multi-tenant identity and data security management and secure access to cloud based applications.

[0011] SUMMARY

[0012] An object of the invention is to improve the authentication flow of users in a group of users who can have access to a system.

[0013] A first aspect of the invention relates to a method performed by a first server for supporting authentication to a session. The method comprises receiving, from a first application device, a first token, wherein the first token relates to the session, and the first token relates to a group of users, upon successful first part of a multi-factor authentication, MFA, of a first user associated to the first application device, initiating the session, sending, to a second server, a first MFA request for performing at least a part of a second part of the MFA of the first user, wherein the first MFA request comprises the first token, receiving, from the second server, a third token comprising the first token and a second token comprising a user identity of the first user, granting access to the first user to the session based on the third token, upon obtaining a request associated to a second user, performing at least a part of a first part of an MFA of the second user, sending, to the second server, a second MFA request for performing at least a part of the second part of the MFA of the second user, receiving, from the second server, an updated third token comprising the first token and an updated second token comprising the user identity of the first user and a user identity of the second user, and granting access to the second user to the session based on the updated third token.

[0014] According to an embodiment of the first aspect, wherein initiating the session may comprise starting the session by the first server.

[0015] According to an embodiment of the first aspect, the method may further comprise: receiving, from the first application device, the user identity of the first user; and performing at least the part of the first part of the MFA of the first user. Hereby is achieved that, the first user is partly authenticated.

[0016] In an embodiment, performing at least the part of the first part of the MFA of the first user may comprise validating the user identity of the first user, wherein validating comprises verifying that the group of users comprises the user identity of the first user. Hereby is achieved, that that the first user is verified to be a part of the group of users.

[0017] In an embodiment verifying that the group of users comprises the identity of the first user may comprise sending, to a data storage, the user identity of the first user; and receiving, from the data storage, an indication that the group of users comprises the user identity of the first user. Hereby is achieved, that the data storage verifies that the first user is a part of the group of users.

[0018] According to an embodiment of the first aspect, performing at least the part of the first part of the MFA of the second user may comprise validating the user identity of the second user, wherein validating comprises verifying that the group of users comprises the user identity of the second user. Hereby is achieved, that that the second user is verified to be a part of the group of users.

[0019] In an embodiment, verifying that the group of users comprises the identity of the second user may comprise sending, to a data storage, the user identity of the second user, and receiving, from the data storage, an indication that the group of users comprises the user identity of the second user. Hereby is achieved, that the data storage verifies that the second user is a part of the group of users.

[0020] In an embodiment, verifying may comprise using a Lightweight Directory Access Protocol, LDAP, directory. According to an embodiment of the first aspect, the method may comprise receiving, from a second application device, the user identity of the second user. Hereby is enabled, that the second user may be granted.

[0021] According to an embodiment of the first aspect, wherein the first MFA request may comprise the user identity of the first user, and / or the second MFA request may comprise the user identity of the second user. Hereby is enabled, that a third token may be generated.

[0022] According to an embodiment of the first aspect, the third token may be a session access token and / or the updated third token may be an updated session access token. Hereby is achieved, that the third token may be used to grant access to the first user and / or the second user.

[0023] According to an embodiment of the first aspect, the method may comprise determining that the first token received from the first application device is not valid, sending, to the first application device, a first identification request for identification of the first user or the group of users, and receiving, from the first application device, an identity of the group of users. Hereby is achieved, that the group of users may be identified.

[0024] In an embodiment, sending the first identification request may comprise sending a first pointer to a first login server. Hereby is achieved, that a user comprised in the group of users may identify itself via the first login server.

[0025] According to an embodiment of the first aspect, the method may comprise upon receiving an identity of group of users, sending, to the first application device, a second identification request for identification of the first user. Hereby is achieved, that the first user may be identified.

[0026] In an embodiment, wherein sending the second identification request may comprise sending a second pointer to a second login server. Hereby is achieved, that the first user may identify itself via the second login server.

[0027] According to an embodiment of the first aspect, the method may comprise obtaining, from a second application device, the request associated to the second user; and sending, to a second application device, a third identification request for identification of the second user. Hereby is achieved, that the second application device requesting identification of the second user. In an embodiment, sending the third identification request may comprise sending a third pointer to a third login server. Hereby is achieved, that the second user may identify itself via the second login server.

[0028] According to an embodiment of the first aspect, the user identity of the first user may be credential of the first user and / or the user identity of the second user may be a credential of the second user.

[0029] According to an embodiment of the first aspect, granting access to the first user to the session, may comprise sending, to the first application device, the third token comprising the first token, the second token and an identity token. Hereby is achieved that the first user has access to an application.

[0030] According to an embodiment of the first aspect, granting access to the second user to the session, may comprise sending, to a second application device, the updated third token. Hereby is achieved that the second user has access to a second application.

[0031] According to an embodiment of the first aspect, the second server may be an authenticator for at least the part of the second part of the MFA.

[0032] A second aspect of the invention relates to a method performed by a second server for supporting authentication to a session. The method comprising receiving, from a first server, a first multi-factor authentication, MFA, request for performing at least a part of a second part of a MFA of a first user, wherein the first MFA request comprises a first token, the first token relating to a group of users and to the session, generating a second token comprising a user identity of the first user, sending, to the first server, a third token, comprising the first token and the second token, receiving, from the first server, a second MFA request for performing at least the part of the second part of the MFA of a second user, updating the second token, wherein the updated second token comprises the user identity of the first user and a user identity of the second user, sending, to the first server, an updated third token comprising the first token and the updated second token. Hereby is achieved that a first and a second user a granted to the session.

[0033] According to an embodiment of the second aspect, the method may comprise receiving, from a second application device, a request associated to the second user, and sending, to the first server, the request associated to the second user.

[0034] Hereby is achieved that the second application device contacts the second server for verification.

[0035] According to an embodiment of the second aspect, the first MFA request may comprise the user identity of the first user, and / or wherein the second MFA request may comprise the user identity of the second user. Hereby is enabled, that a third token may be generated.

[0036] According to an embodiment of the second aspect, the method may comprise performing at least the part of the second part of the MFA of the first user. Hereby is achieved that, the first user is partly authenticated.

[0037] According to an embodiment of the second aspect, the method may comprise performing at least the part of the second part of the MFA of the second user. Hereby is achieved that, the second user is partly authenticated.

[0038] According to an embodiment of the second aspect, wherein performing at least the part of the second part of the MFA of the first user, may comprise validating the user identity of the first user, wherein validating may comprise verifying that the group of users comprises the user identity of the first user. Hereby is achieved, that that the first user is verified to be a part of the group of users.

[0039] According to an embodiment of the second aspect, wherein verifying that the group of users comprises the identity of the first user may comprise sending, to a data storage, the user identity of the first user, and receiving, from the data storage, an indication that the group of users comprises the identity of the first user. Hereby is achieved, that the data storage verifies that the first user is a part of the group of users.

[0040] According to an embodiment of the second aspect, wherein verifying may comprise using a Lightweight Directory Access Protocol, LDAP, directory.

[0041] According to an embodiment of the second aspect, wherein the third token may be a session access token and / or wherein the updated third token may be an updated session access token. Hereby is achieved, that the third token may be used to grant access to the first user and / or the second user. According to an embodiment of the second aspect, wherein the first server may be an authenticator for at least a part of the first part of the, MFA and / or an identity provider server.

[0042] A third aspect of the invention relates to a first server configured to receive, from a first application device, a first token, wherein the first token relates to the session, and the first token relates to a group of users, upon successful first part of a multifactor authentication, MFA, of a first user associated to the first application device, initiate the session, send, to a second server, a first MFA request for performing at least a part of a second part of the MFA of the first user, wherein the first MFA request comprises the first token, receive, from the second server, a third token comprising the first token and a second token comprising a user identity of the first user, grant access to the first user to the session based on the third token, upon obtaining a request associated to a second user, perform at least a part of a first part of the MFA of the second user, send, to the second server, a second MFA request for performing at least a part of the second part of the MFA of the second user, receive, from the second server, an updated third token comprising the first token and an updated second token comprising the user identity of the first user and a user identity of the second user, and grant access to the second user to the session based on the updated third token.

[0043] According to an embodiment of the third aspect, the first server may be configured to perform the method according to the first aspect or any embodiment of the first aspect.

[0044] A fourth aspect of the invention relates to a first server, comprising a processor and a memory, the memory containing instructions executable by the processor whereby the first server is configured to receive, from a first application device, a first token, wherein the first token relates to the session, and the first token relates to a group of users, upon successful first part of a multi-factor authentication, MFA, of a first user associated to the first application device, initiate the session, send, to a second server, a first MFA request for performing at least a part of a second part of the MFA of the first user, wherein the first MFA request comprises the first token, receive, from the second server, a third token comprising the first token and a second token comprising a user identity of the first user, grant access to the first user to the session based on the third token, upon obtaining a request associated to a second user, perform at least a part of a first part of the MFA of the second user, send, to the second server, a second MFA request for performing at least a part of the second part of the MFA of the second user, receive, from the second server, an updated third token comprising the first token and an updated second token comprising the user identity of the first user and a user identity of the second user, and grant access to the second user to the session based on the updated third token.

[0045] According to an embodiment of the fourth aspect, the first server may be configured to perform the method according to the first aspect or any embodiment of the first aspect.

[0046] A fifth aspect of the invention relates to a second server, configured to receive, from a first server, a first multi-factor authentication, MFA, request for performing at least a part of a second part of a multi-factor authentication, MFA, of a first user, wherein the first MFA request comprises a first token, the first token relating to a group of users and to the session, generate a second token comprising a user identity of the first user, send, to the first server, a third token, comprising the first token and the second token, receive, from the first server, a second MFA request for performing at least the part of the second part of the MFA of a second user, update the second token, wherein the updated second token comprises the user identity of the first user and a user identity of the second user, send, to the first server, the an updated third token comprising the first token and the updated second token.

[0047] According to an embodiment of the fifth aspect, the second server may be configured to perform the method according to the second aspect or any embodiment of the second aspect.

[0048] A sixth aspect of the invention relates to a second server, comprising a processor and a memory, the memory containing instructions executable by the processor, whereby the first server is configured to receive, from a first server, a first multi-factor authentication, MFA, request for performing at least a part of a second part of a multi-factor authentication, MFA, of a first user, wherein the first MFA request comprises a first token, the first token relating to a group of users and to the session, generate a second token comprising a user identity of the first user, send, to the first server, a third token, comprising the first token and the second token, receive, from the first server, a second MFA request for performing at least the part of the second part of the MFA of a second user, update the second token, wherein the updated second token comprises the user identity of the first user and a user identity of the second user, send, to the first server, the an updated third token comprising the first token and the updated second token.

[0049] According to an embodiment of the sixth aspect, the second server may be configured to perform the method according to the second aspect or any embodiment of the second aspect.

[0050] A seventh aspect of the invention relates a system comprising a first server performing a method according to the first aspect or any embodiment of the first aspect and a second server performing a method according second aspect or any embodiment of the second aspect, the first server being configured to receive by the first server, from a first application device, a first token, wherein the first token relates to the session, and the first token relates to a group of users, upon successful first part of a multi-factor authentication, MFA, of a first user associated to the first application device, initiate, by the first server the session, send, by the first server to the second server, a first MFA request for performing at least a part of a second part of the MFA of the first user, wherein the first MFA request comprises the first token, receive, by the first server from the second server, a third token comprising the first token and a second token comprising a user identity of the first user, grant, by the first server, access to the first user to the session based on the third token, upon obtaining, by the first server a request associated to a second user, perform, by the first server, at least a part of a first part of a MFA of the second user, send, by the first server to the second server, a second MFA request for performing at least a part of the second part of the MFA of the second user, receive, by the first server from the second server, an updated third token comprising the first token and an updated second token comprising the user identity of the first user and a user identity of the second user, and grant, by the first server, access to the second user to the session based on the updated third token.

[0051] An eighth aspect of the invention relates to a system comprising a first server performing a method according to the first aspect or any embodiment of the first aspect and a second server performing a method according second aspect or any embodiment of the second aspect, the second server being configured to receive, by the second server from the first server, a first multi-factor authentication, MFA, request for performing at least a part of a second part of a multi-factor authentication, MFA, of a first user, wherein the first MFA request comprises a first token, the first token relating to a group of users and to the session, generate, by the second server, a second token comprising a user identity of the first user, send, by the first server to the first server, a third token, comprising the first token and the second token, receive, by the first server from the first server, a second MFA request for performing at least the part of the second part of the MFA of a second user, update, by the first server the second token, wherein the updated second token comprises the user identity of the first user and a user identity of the second user, send, by the first server to the first server, an updated the third token comprising the first token and the updated second token.

[0052] A ninth aspect of the invention relates to a computer program comprising instructions which, when executed on at least one processor of a first server, cause the at least one processor of the first server to carry out the method according to the first aspect or any embodiment of the first aspect, and / or at least one processor of a second server, cause the at least one processor of the second server to carry out the method according the second aspect or any or any embodiment of the second aspect.

[0053] A tenth aspect of the invention relates to a tangible, non-transitory-computer- readable medium comprising instructions that, when executed on at least one processor of a first server, cause the at least one processor of the first server to carry out the method according to the first aspect or any embodiment of the first aspect, and / or at least one processor of a second server, cause the at least one processor of the second server to carry out the method according to the second aspect or any embodiment of the second aspect.

[0054] BRIEF DESCRIPTION OF THE DRAWINGS

[0055] Figure 1 shows a flowchart relating to a multi-factor authentication flow of a first user and a second user in an authentication system according to the prior art.

[0056] Figure 2 shows a schematic diagram illustrating an example of an environment in which embodiments presented herein can be applied. Figure 3 is a flowchart illustrating a method performed by the first server for supporting authentication to a session according to an embodiment of present disclosure.

[0057] Figure 4 is a flowchart illustrating a method performed by the first server for supporting authentication to a session according to an embodiment of present disclosure.

[0058] Figure 5 shows an exemplifying flowchart relating to a multi-factor authentication flow of the first user and the second user in a system according to an embodiment of present disclosure.

[0059] Figures 6A to 6B are signaling diagrams of an exemplary interaction between the first user, the second user, the first application device, optionally the second application device, the first server, the second server, and the data storage, according to an embodiment of present disclosure.

[0060] Figures 7A to 7B depict signaling diagrams of an embodiment of the exemplary interaction between the first user, the second user, the first application device, optionally the second application device, the first server, the second server, and the data storage.

[0061] Figures 8A to 8B depict signaling diagrams of an embodiment of the exemplary interaction between the first application device, optionally the second application device, the first server, the second server, the data storage, the first communication device 260 and the first communication device.

[0062] Figures 9A to 9B depict signaling diagrams of an embodiment of the exemplary interaction between the first user, the second user, the first application device, optionally the second application device, the first server, the second server, and the data storage.

[0063] Figures 10A to 10B illustrate flowcharts illustrating embodiments of the method performed by the first server for supporting authentication to a session.

[0064] Figure 11 A to 11 B illustrate a flowchart illustrating embodiments of the method performed by the second server for supporting authentication to a session. Figure 12 illustrates a block diagram illustrating embodiments of the first server in further detail.

[0065] Figure 13 illustrates a block diagram illustrating embodiments of the second server in further detail.

[0066] DETAILED DESCRIPTION

[0067] Figure 2 illustrates a schematic diagram illustrating an example of an environment in which embodiments presented herein can be applied. It relates to a first server 210, a second server 220 and a first application device 240. In an embodiment, the first server 210 comprises a data storage 230. In another embodiment, the data storage 230 is not comprised by the first server 210. Figure 1 also illustrates a first user 100 and a second user 110, wherein the first user 100 and the second user 110 in the figure are indicated as human. The first server 210, the second server 220, and the data storage 230 may be comprised in a cloud environment 200. Figure 1 also illustrate a second application device 250 a first communication device 260 and a first communication device 270. In an embodiment the first user 100 communicates with the first application device 240 via for example the first communication device 260 and the second user 110 communicates with the second application device 250 via for example the first communication device 270. In another embodiment the first user 100 and the second user 110 communicate with the first application device 240. In an example the first and / or the second application device 250 is a cloud application.

[0068] Figure 3 is a flowchart illustrating a method performed by the first server 210 for supporting authentication to a session. The method comprises a first step 310 of receiving from a first application device 240, a first token, wherein the first token relates to the session, and the first token relates to a group of users. In a step 320, the method comprises upon successful first part of a multi-factor authentication (MFA) of a first user 100 associated to the first application device 240, initiating the session. In a sending step 330 the method comprises sending to a second server 220, a first MFA request for performing at least a part of a second part of the MFA of the first user 100, wherein the first MFA request comprises the first token. The method further comprises in a step 340 receiving, from the second server 220, a third token comprising the first token and a second token comprising a user identity of the first user 100. In a step 350, the method comprises, granting access to the first user 100 to the session based on the third token. The method comprises in a step 360, upon obtaining a request associated to a second user 110, performing 360 at least a part of a first part of an MFA of the second user 110. Step 370 comprises sending, to the second server 220, a second MFA request for performing at least a part of the second part of the MFA of the second user 110. Step 380 of the method comprises receiving, from the second server 220, an updated third token comprising the first token and an updated second token comprising the user identity of the first user 100 and a user identity of the second user 110. The method further comprises granting access to the second user 110 to the session based on the updated third token comprising the first token and the updated second token.

[0069] The invention or any of its embodiments provides advantages, for example, the step 310 may address the challenges described above of enabling identification and / or authentication as a group of users when accessing a system. The step 320 of initiating the session, upon successful first part of an MFA of a first user 100 associated to the first application device 240, is provided to address the challenge of preserving security in the session by identifying the first user 100 of the group of users. The step 330 comprises sending 330 to a second server 220, a first MFA request for performing at least a part of a second part of the MFA of the first user 100, wherein the first MFA request comprises the first token which enables the MFA of the first user 100 as part of the group of users by comprising the first token in the first request. The step 340 enables granting access to the first user 100 as part of the group of users to the session. The step 350 enables granting access to the individual first user 100 to the session which is for example related to the group of users. Steps 360 and 370, enable performing the MFA of the second user 110 as a part of the group of users within the same session. Advantageously, the second user 110 is not required to provide the first token relating to the group of users while maintaining the session continuity, thereby simplifying the authentication / identification process, and further reducing signaling overhead.

[0070] Figure 4 is a flowchart illustrating a method performed by the first server 210 for supporting authentication to a session. In a first step 410 the method comprises receiving, from a first server 210, a first MFA request for performing at least a part of a second part of an MFA of a first user 100, wherein the first MFA request comprises a first token, and the first token relates to a group of users and to the session. Step 420 comprises generating a second token comprising a user identity of the first user 100. In a sending step 430, the method comprises sending, to the first server 210, a third token, comprising the first token and the second token. Step 440 comprises receiving, from the first server 210, a second MFA request for performing at least the part of the second part of the MFA of a second user 110. The method comprises step 450 of updating the second token, wherein the updated second token comprises the user identity of the first user 100 and a user identity of the second user 110. In a step 460, the method comprises sending, to the first server 210, the updated third token comprising the first token and the updated second token.

[0071] Step 410 may address the challenge of performing MFA of a first user 100 as a part of a group of users. The step 420 of generating a second token comprising a user identity of the first user 100 which enables to retain the individuality of the user identity of the first user 100 as part of the group of users. Step 410 and / or step 420 enables step 430 of sending a third token comprising the first and the second token. Sending the third token enables relating the user identity of the first user 100 to the group of users in the authentication procedure retaining the individuality of the user identity of the first user 100. The Step 440 enables performing multi-factor authentication of a second user 110. The step 450 of updating the second token addresses the challenge of maintaining the session while enabling access to the second user 110. By updating the second token, the user identity of the second user 110 is retained as part of the group of users, while the user identity of the first user 100 is also maintained. This enables the generation of an evolutionary or dynamic token by constantly updating the second token based on the user identity of the first or second user 110. Updating the second token allows the session to be maintained. The step 460 of sending the updated third token enables access to be granted to the second user 110 belonging to the group of users while maintaining the same session.

[0072] Figure 5 relates to an exemplifying flowchart relating to an MFA flow of the first user 100 and the second user 110 in a system, wherein the first and the second user 110 are accessing the system as a group of users while maintaining the session. In a step 501 the identity of the group of users is provided. In a step 502 the user identity if the first user 100 is provided. In a step 503 the first factor authentication is performed of the user identity of the first user 100. In a step 504 the second factor authentication is performed of the user identity of the first user 100. The first user 100 gets granted in a step 505 to the session. For example, meanwhile or after, in a step 511 the identity of the group of users is provided. In a step 512 the user identity of the second user 110 is inserted. In a step 513 the first factor authentication is performed to authenticate the second user 110. In a step 514 the second factor authentication is performed. In a step 115 the second user 110 is granted to the same session as the first user 100 is granted to. The first user 100 optionally closes in a step 506 the application, e.g., log off.

[0073] The session is identified by, e.g., the third token, which is dynamically updatable based on the user. The session may be an authentication session different to a multicast session. In an example the authentication session is a seamless session where only one individual user has access at a time, i.e. , first the first user 100 accessing the system then the second user 110 accessing the system. Different communication devices, such as the first communication device 260 and the first communication device 270 may be used for communication for authenticating to the same seamless sessions. The seamless session may be an operational session relating to a group of users acting with the same resources with different roles. The authentication session may be a collaboration session where more than one individual user can access the system in at a time, i.e., the first user 100 and the second user 110 accessing the system at the same time using the same session. The same communication device 260 may be shared between the first and the second user 110 for communication for authenticating to the same collaboration session. The collaboration session may relate to a group of users acting with the same role, similar role, or at least part of overlapping role on the system. The session may be an online subsystem (OSS) session. Alternatively, or additionally, the session is implemented in a data security system (DSI).

[0074] The solution therefore allows an improved security within a seamless change of the user identities using the same session. By relating the group of users with the user identities, i.e., the user identity of the first user 100 and second user 110, the assurance of the MFA to the group of users is improved. Advantageously, by maintaining the session, overhead in the authentication flow of a group of users is decreased while maintaining the security by ensuring maintaining the MFA flow of the individual users. When changing from first to second user 110, there is no need to provide the first token which may decrease the overhead in the authentication. By maintaining the first token, the session is maintained.

[0075] The group of users may correspond a set of at least one physical user with any sort of commonality among physical users such as users with same rights to act on the system, a set of users acting with the same role or a set of users acting on the same resources with different roles. In other words, the group of users may be referred to as a group of abstract users.

[0076] Figures 6A to 6B are signaling diagrams of an exemplary interaction between the first user 100, the second user 110, the first application device 240, optionally the second application device 250, the first server 210, the second server 220, and the data storage 230 as shown in Figure 2. In Figures 6A and 6B, the communication device, the first user 100, the second user 110, the first application device 240, optionally the second application device 250, the first server 210, the second server 220, and the data storage 230 are depicted for illustration, even if not all entities are comprised in the interaction of each sub figure 6A to 6B. Figure 6A and 6B are illustrated on two pages for convenience, but they are understood as one single signaling diagram. The steps of Figure 6B continue where the steps of Figure 6A end. The data storage 230 relates herein to data storage 230 hardware.

[0077] In an optional step 601 of figure 6A the first user 100 starts an application via the first application device 240. The step 601 may enable the first user 100 to request access to at least one resource in a system.

[0078] The application is an application program or an application software. The application can be self-contained or a group of programs. The program is a set of operations that runs the application for the user. Examples of the application are a word processor, a database program, a web browser, a deployment tool, an image editor, a communication platform or a software program such as a client application. The at least one resource is any physical or virtual component of limited availability within a system, for example, a computer system. Examples of resource types are Interrupt request (IRQ) lines, Direct memory access (DMA) channels, Port-mapped I / O, Memory-mapped I / O, Locks, External devices External memory or objects, such as memory managed in native code, from Java; or objects in the Document Object Model (DOM), from JavaScript, Central Processing Unit (CPU), Hard disk drives, Cache space, including CPU cache and memory management unit (MMU) cache, Network throughput, Electrical power or input / output operations.

[0079] The first application device 240 is a first hardware component, running the application. The second application device 250 is a second hardware component running the application. In an example the first or second hardware component is the first or first communication device 270.

[0080] The first application device 240 sends in a step 602 the first token, wherein the first token relates to the session, and the first token relates to a group of users. The first server 210 receives, from the first application device 240, the first token, wherein the first token relates to the session, and the first token relates to the group of users. Step 602 may correspond to step 310 of method 300. The step 602 may enable the first server 210 to validate whether a previous authentication of the group of users has been performed successfully relating to the first token.

[0081] The token is a signed credential encoded into a long string of characters. The token may be an authentication token comprising a header, a payload and signature. The header defines the token type being used, as well as the signing algorithm involved. The payload is responsible for defining the token issuer and the token’s expiration details. It may also provide information about the user. The signature verifies the authenticity of a message, wherein the message comprises the token, and that a message has not changed while in transit. Examples of the token are a connected token, a contactless token, a disconnected token, a software toke or a JavaScript Object Notation (JSON) Web Token (JWT).

[0082] In an optional step 603 of Figure 6A the first server 210 determines that the first token received from the first application device 240 is not valid. The step 603 may enable determining whether an authentication is needed. In an example, if the first token is already present and valid, the authentication already has taken place, the first token has not yet expired, and no authentication is needed.

[0083] In an optional step 604 the first server 210 sends, to the first application device 240, a first identification request for identification of the first user 100 or the group of users. The first application device 240, receives, from the first server 210, the first identification request. The step 604 may enable starting the authentication procedure of the first user 100 and initiating the session.

[0084] In an optional step 605, the first user 100 provides an identity of the group of users to the first application device 240. The first application device 240 receives the identity of the group of users.

[0085] The identity of the group of users, the identity of the first user 100 and / or the identity of the second user 110 is the collection of attributes and values associated to the group of users, the first user 100 and / or the second user 110. The identity of the group of users, the identity of the first user 100 and / or the identity of the second user 110 is for example a credential associated to the group of users, a username associated to the group of users, a personal identification number (PIN), a combination of any example or other collection of attributes and values possessed only by the users associated to the group of users.

[0086] In an optional step 606, the first application device 240 sends the identity of the group of users to the first server 210. The first server 210 receives, from the first application device 240, the identity of the group of users. The step 606 may enable authorizing the first user 100 as a part of a group of users to the application using the session.

[0087] In an optional step 607, the first server 210 sends, upon receiving an identity of group of users, to the first application device 240, a second identification request for identification of the first user 100. The step 608 may enable requesting the first user 100 for providing the user identity of the first user 100.

[0088] The first application device 240 receives the second identification.

[0089] In an optional step 608, the first user 100 provides the identity of the first user 100 to the first application device 240. The first application device 240 receives the identity of the first user 100. The step 808 may enable authentication of the first user 100 using the identity of the first user 100.

[0090] In an optional step 609, the first application device 240 sends the user identity of the first user 100 to the first server 210. The first server 210 receives, from the first application device 240, the user identity of the first user 100. In an optional step 610 the first server 210 performs at least the part of the first part of the MFA of the first user 100. The step 610 may enable partly authenticating the first user 100 using a first factor.

[0091] An MFA relates to at least two step authentication procedure that requires at least two factors based on multi-factor protocols. A factor relates to an authentication factor which is a security control used for verifying the identity of a user. An example of factors are knowledge factors, such as credentials, possession factors, inherence factors, location factors and behavior factors. A possession factor is, e.g., a key to the security lock. The possession factor is associated to physical entities possessed by the user, e.g., relating to connected or disconnected tokens. An inherence factor is at least one metric intrinsically owned by the user, such as biometrics, e.g., using fingerprint readers, retina scanners, face recognition or voice recognition. The MFA may be based on an authentication protocol for an authentication procedure of a user.

[0092] In figure 6A and 6B, a two-factor authentication is exemplified, i.e. , two factors are used to authenticate the user. The invention anyhow is not limited to two-factor authentication. The MFA including more the 2 factors may be applied using more than two servers to authenticate the first user 100 and / or the second user 110.

[0093] Upon successful first part of an MFA of a first user 100 associated to the first application device 240, the first server 210 initiates the session. Initiating session may correspond to step 320 of method 300.

[0094] In a step 611 the first server 210 sends, to a second server 220, a first MFA request for performing at least a part of a second part of the MFA of the first user 100, wherein the first MFA request comprises the first token, the first token relating to the group of users and to the session. The second server 220 receives, from the first server 210, the first MFA request. The step 611 may correspond to step 330 of method 300 and step 410 of method 400. The step 611 may enable performing the second part of the MFA by the second server 220.

[0095] In an optional step 612, the second server 220, performs at least the part of the second part of the MFA of the first user 100. A second factor is used for the second part of the MFA. The step 612 may enable authenticating the first user 100 using the second factor. In a step 613, the seconds server generates a second token comprising a user identity of the first user 100. The step 613 may enable relating the identity of the first user 100 to the second token. The step 613 may correspond to step 420 of method 400.

[0096] In a step 614, the second server 220 sends, to the first server 210, a third token, comprising the first token and the second token. The first server 210 receives from the second server 220, the third token comprising the first token and the second token. The step 614 may enable the first server 210 to grant access to the first user 100 as a part of the group of users. The step 614 may correspond to step 430 of method 400 and step 340 of method 300.

[0097] In a step 615, the first server 210 grants access to the first user 100 to the session based on the third token. The step 615 may enable the first user 100 to access the application. The step 615 may correspond to step 350 of method 300.

[0098] Referring to figure 6B, in an optional step 616 the second user 110 starts the application via the second application device 250. The step 616 may enable the second user 110 to request for authentication of the second user 110.

[0099] In an optional step 617 the second application device 250 sends, to the first server 210, a request associated to the second user 110. The first server 210 receives, from the second application device 250 the request associated to the second user 110. The step 617 may enable the first server 210 to be triggered to initiate the MFA for the second user 110.

[0100] In an optional step 618, the first server 210, sends, to a second application device 250, a third identification request for identification of the second user 110. The step 618 may enable the second user 110 to provide the identity if the second user 110.

[0101] In an optional step 619, the second user 110 provides to the second application device 250 the user identity of the second user 110. The second application device 250 receives the user identity of the second user 110. The step 619 may enable authentication of the second user 110 using the identity of the second user 110 within the session.

[0102] The second application device 250 sends in an optional step 620, to the first server 210, the user identity of the second user 110. The first server 210, receives from the second application device 250, the user identity of the second user 110.

[0103] In a step 621 , the first server 210, upon obtaining a request associated to a second user 110), performs at least a part of the first part of the MFA of the second user 110. The step 621 may enable partly authenticating the second user 110 using the first factor. The step 621 may correspond to step 360 of method 300.

[0104] In a step 622 the first server 210, sends, to the second server 220, a second MFA request for performing at least a part of the second part of the MFA of the second user 110. The second server 220 receives, from the first server 210, the second request for performing at least the part of the second part of the MFA of a second user 110. The step 622 may enable performing the second part of the multi-factor authentication by the second server 220. The step 622 may correspond to step 370 of method 300 and step 440 of method 400.

[0105] In an optional step 623, the second server 220, performs at least the part of the second part of the MFA of the second user 110. The step 623 may enable authenticating the second user 110 using the second factor.

[0106] In a step 624, the second server 220 updates the second token, wherein the updated second token comprises the user identity of the first user 100 and a user identity of the second user 110. The step 624 may enable relating the identity of the first user 100 and the identity of the second user 110 to the second token. The step 624 may correspond to step 450 of method 400.

[0107] In a step 625, the second server 220, sends, to the first server 210, the updated third token. The first server 210, receives from the second server 220, the updated third token comprising the user identity of the first user 100 and a user identity of the second user 110. The step 625 may enable the first server 210 to grant access to the second user 110 as a part of the group of users. The step 625 may correspond to step 460 of method 400 and step 380 of method 300.

[0108] The first server 210 grants, in a step 626, access to the second user 110 to the session based on the updated third token. The step 626 may enable the second user 110 to access the application. The step 626 may correspond to step 390 of method 300. Figures 7A to 7B are signaling diagrams illustrating a first embodiment of the exemplary interaction between the first user 100, the second user 110, the first application device 240, optionally the second application device 250, the first server 210, the second server 220, and the data storage 230 as shown in Figure 2. In figures 7A to 7B the communication device, the first user 100, the second user 110, the first application device 240, optionally the second application device 250, the first server 210, the second server 220, and the data storage 230 are depicted for illustration, even if not all entities are comprised in the interaction illustrated in each sub figure 7A to 7B. Figure 7A and 7B are illustrated on two pages for convenience, but they are understood as one single signaling diagram. The steps of Figure 7B continue where the steps of Figure 7A end.

[0109] In a step 701 of figure 7A the first user 100 starts an application via the first application device 240.

[0110] In the first embodiment the first user 100 interacts with the first communication device 260, such as a user equipment (UE), to start the application. Starting the application comprises that the first communication device 260 sends an access request, to the first application device 240, to start the application for accessing the at least one resource. In the embodiment, the application is a client application such as a web browser or an API client, while the application device is a client web application device. The resource is an application programmable interface (API) resource. The access request is an API request, such a HTTP request message as for example HTTP GET.

[0111] A step 702 of Figure 7A corresponds to step 603 of Figure 6A, wherein the token is a JSON Web Token (JWTs). The first server 210 is an OpenlD Connect Provider (OIDC Provider). The first application device 240 sends the first token using an OAuth 2.0 Authentication Request, a HTTP GET message to the first server 210. In an example the first token is comprised in a cookie.

[0112] A step 703 of Figure 7A may correspond to step 603 of Figure 6A, wherein the determining comprises checking or validating whether a previous authentication has been performed successfully. An invalid token implies that no prior authentication of the group of users has been performed or that the first token has expired. In the embodiment, determining comprises validating by requesting verification of the data store and receiving a response from the data store. The data store herein refers to data storage 230 hardware. In the embodiment, the data store refers to a Lightweight Directory Access Protocol (LDAP) data store, wherein requesting the verification comprises sending an LDAP message and receiving the response comprises receiving an LDAP message.

[0113] In an alternative example the data storage 230 may comprise a list of user identities.

[0114] A step 704 may correspond to step 604 of Figure 6A, wherein sending the first identification request comprises sending a first pointer to a first login server. The first login server may be the first server 210, wherein the first pointer is a pointer to the login page hosted by the first server 210.

[0115] The first pointer, a second pointer and / or a third pointer may be a Uniform resource locator (URL) or Uniform Resource Identifier (URI) previously saved in the op.authz.endpoint configuration property of the first server 210. Sending comprises publishing the pointer at a location of an OAuth 2.0 authorization endpoint as a JSON object through the OpenlD Connect provider metadata, such as an HTML form.

[0116] A step 705 may correspond to step 605 of Figure 6A, wherein the identity of the group of users is the username of the group of users. The first user 100 provides the identity of the group of users using the pointer to the login page using first communication device 260. The first application device 240 obtains the identity of the group of users from the login page.

[0117] A step 706 may correspond to step 606 of Figure 6A, wherein sending the identity of the group of users comprises sending a list of users which are part of the group of users by sending e.g. a HTTP based message such as a userinfo response message of the OIDC protocol.

[0118] A step 707 may correspond to step 607 of Figure 6A, wherein, sending the second identification request comprises sending the second pointer to a second login server. In the embodiment the second login server is the first server 210, wherein the second pointer is the pointer to a second login page hosted by the first server 210.

[0119] A step 708 may correspond to step 608 of Figure 6A, wherein the first user 100 provides the user identity of the first user 100 using the pointer to the second login page using first communication device 260. The first application device 240 obtains the user identity of the first user 100 from the second login page. The user identity of the first user 100 is at least one credential of the first user 100. The credential is, e.g., a combination of a password and a username.

[0120] A step 709 corresponds to step 609 of Figure 6A, wherein the user identity of the first user 100 is sent using e.g. an HTTP based message such as a userinfo response message of the OIDC protocol.

[0121] A step 710 corresponds to step 610 of Figure 6A, wherein performing at least the part of the first part of the MFA of the first user 100 comprises verifying the credential of the first user 100 by sending the credential of the first user 100 to the data storage 230 and receiving an acknowledgement from the data storage 230 that the credential of the first user 100 is valid. A second part of the first part of the MFA of the first user 100 is performed by the data storage 230 by verifying the first user 100 by the data storage 230. Sending and receiving comprises the use of at least one LDAP message. The first factor is a knowledge factor, i.e. , the credential of the first user 100. In the first embodiment, initiating the session comprises starting the session by the first server 210. The session is started when the first part of an MFA of the first user 100 is started. At this point, the session is not yet validated.

[0122] In a step 711 correspond to step 611 of Figure 6A, wherein, the first MFA request and / or the second MFA request is a OIDC protocol-based message such as an OAuth 2.0 Authorization Request. The first MFA request and / or the second MFA request comprises the user identity of the first user 100 and / or the user identity of the second user 110.

[0123] In a step 712 and 713, the second server 220 validates the user identity of the first user 100, wherein validating comprises verifying that the group of users comprises the identity of the first user 100. Step 712 and 713 enables authorization of the first user 100 as the part of the group of users.

[0124] In a step 712, the second server 220 sends, to the data storage 230, the user identity of the first user 100. In the first embodiment the second server 220 sends the credential of the first user 100. Sending the user identity of the comprises using an LDAP message. In the step 713, the second server 220 receives, from the data storage 230, an indication that the group of users comprises the user identity of the first user 100. In the first embodiment, the indication is comprised in an LDAP message.

[0125] A step 714 may correspond to step 612 in Figure 6A, wherein, the second factor is a biometric recognition factor. Performing at least the part of the second part of the MFA of the first user 100 (the second user 110) comprises establishing a connection with the first communication device 260 (the first communication device 270). Establishing a connection may comprise using a quick response (QR) code. Performing further comprises sending a third MFA request for biometric recognition of the first user 100 (the second user 110) to the first communication device 260 (the first communication device 270). The first communication device 260 (the first communication device 270) receives the third MFA request for biometric recognition of the first user 100 (the second user 110). The first communication device 260 (the first communication device 270) recognizes the first user 100 (the second user 110) using the biometric recognition, such as a fingerprint of the first user 100 (second user 110) an or a face of the first user 100. Recognizing by the first communication device 260 (the second communication device 270) comprises performing a second part of the second part of the MFA of the first user 100 (the second user 110). The first communication device 260 (the first communication device 270) sends a confirmation of the biometric recognition of the first user 100 (the second user 110) to the second server 220. The second server 220 receives the confirmation of the biometric recognition of the first user 100 (the second user 110).

[0126] A step 715 may correspond to step 613 of Figure 6A, wherein the second token comprises the user attributes of the first user 100, i.e., the identity of the first user 100. The second token is at least a part of a JWT OIDC Token and corresponds to a session access token. The session access token is a string containing a unique secret token, such as an API key. The second server 220 generates the third token, wherein the third token, comprises the first token and the second token. Generating the third token enables relating the identity of the group of users to the user identity of the first user 100. The third token is the JWT OIDC Token with a custom claim defining a relation of the identity of group of users to the user identity of the first user 100. Generating the third token comprises adding the custom claim to the JWT OIDC Token. In a step 716 may correspond to step 614 of Figure 6A, wherein the third token is sent as a concatenation of the first and second token including the custom claim using e.g. an HTTP based message such as an OIDC token answer API. The third token is sent with an identity token.

[0127] Upon successful second part of the MFA of the first user 100, the session is validated.

[0128] A step 717 corresponds to step 615 of Figure 6A, wherein, granting access comprises generating, by the first server 210 an ID token. The identity (ID) token contains standard claims such as e.g. a name or a nickname. The ID token is a Base64-encoded JSON document. Granting access comprises sending, by the first server 210 a message, wherein the message contains the third token and the ID token. The message is a JavaScript Object Notation (JSON) meta-data document.

[0129] The first user 100 is authenticated and may access via the first application the application using the session.

[0130] Referring to figure 7B, a step 718 may correspond to step 616 of Figure 6B. The step 718 may enable the second user 110 to request access to, e.g., a second resource of the at least one resource. In the first embodiment, the second user 110 interacts with the first communication device 270, such as UE, to start the application. Starting the application comprises that the first communication device 270 sends an access request, to the first application device 240, to open the application for accessing the at least one resource.

[0131] A step 719 may correspond to step 617 of Figure 6B, wherein the request associated to the second user 110 is e.g. an HTTP based message such as an OIDC protocolbased message such as an OAuth 2.0 Authorization Request for requesting access to the second resource.

[0132] A step 720 may correspond to the step 618 of Figure 6B, wherein, the third identification request comprises sending the third pointer to a third login server. Sending comprises publishing the third pointer at a location of an OAuth 2.0 authorization endpoint as a JSON object through the OpenlD Connect provider metadata, such as an HTML form. In an example, the first, second and / or third login page is the same. A step 721 may correspond to step 619 of Figure 6B, wherein the first application device 240 receives the identity of the second user 110 via the login page. The user identity of the second user 110 is at least one credential of the second user 110.

[0133] A step 722 may correspond to step 620 of Figure 6B, wherein the user identity of the second user 110 is sent using e.g. an HTTP based message such as a userinfo response message of the OIDC protocol.

[0134] A step 723 may correspond to step 621 of Figure 6B, wherein performing at least the part of the first part of the MFA of the second user 110 comprises verifying the identity of the second user 110 by sending the credential to the data storage 230 and receive an acknowledgement from the data storage 230 that the credential of the user is valid, wherein the second part for the first part of the MFA is permed by the data storage 230. Sending and receiving comprises using at least one LDAP message.

[0135] In a step 724 may correspond to step 622 of Figure 6B.

[0136] In a step 725 and 726, the second server 220 validates the user identity of the second user 110, wherein validating comprises verifying that the group of users comprises the identity of the second user 110. Step 725 and 726 enables authorization of the second user 110 as the part of the group of users.

[0137] In the step 725, the second server 220 sends, to the data storage 230, the user identity of the second user 110. In the first embodiment the second server 220 sends the credential of the second user 110. Sending the user identity of the second user 110 of the comprises using an LDAP message.

[0138] In the step 726, the second server 220 receives, from the data storage 230, an indication that the group of users comprises the user identity of the second user 110. In the first embodiment, the indication is comprised in an LDAP message.

[0139] A step 727 may correspond to step 623 of Figure 6B.

[0140] A step 728 may correspond to step 624 of Figure 6B, wherein the second server 220 generates the updated third token, and wherein the updated third token, comprises the first token and the updated second token. Generating the updated third token enables relating the identity of the group of users to the user identity of the first user 100 and the user identity of the second user 110. The updated second token corresponds to an updated session access token. The updated session access token is a string containing a unique secret token, such as an API key. The updated third token corresponds to a refresh token. The refresh token is a string containing a unique secret token, such as an API key.

[0141] A step 729 may correspond to step 625 of Figure 6B, wherein the updated third token is sent using e.g. an HTTP message such as the OIDC token answer API.

[0142] A step 730 may correspond to step 626 of Figure 6B, wherein granting access to the second user 110 comprises generating, by the first server 210 an ID token.

[0143] The second user 110 is authenticated and may access via the first application device 240 the application using the session.

[0144] Figure 8A to 8B depict signaling diagrams of an embodiment of the exemplary interaction between the first application device 240, optionally the second application device 250, the first server 210, the second server 220, the data storage 230, the first communication device 260 and the first communication device 270 as shown in Figure 2. In Figures 8A to 8B the communication device, the first user 100, the second user 110, the first application device 240, optionally the second application device 250, the first server 210, the second server 220, the data storage 230, the first communication device 260 and the first communication device 270 are depicted for illustration, even if not all entities are comprised in the interaction of each sub figure 8A to 8B. Figure 8A and 8B are illustrated on two pages for convenience, but they are understood as one single signaling diagram. The steps of Figure 8B continue where the steps of Figure 8A end.

[0145] In a step 801 of figure 8A, the first communication device 260 provides the identity of the group of users to the first application device 240. The first application device 240 receives the identity of the group of users. Step 801 enables the first application device 240 to trigger the authentication procedure of the first user 100 as a part of the group of users. The group of users is at least one first client ID, along with e.g., a client secret relating to the group of users.

[0146] In the second embodiment the identity of the group of users is a client identity of the group of users. The client identity is a public identifier of the client. The first application device 240 is a client application. The first user 100 initiates step 801 , by opening the application.

[0147] A step 802 may correspond to step 606 of Figure 6A, wherein the identity of group of users is send via M2M communication using HTTP request message such as an Access Token request of a client credential flow in OAuth2.0 RFC 6749 section 4.4.. The first server 210 and the second server 220 are for example keycloak servers. Upon receiving the first server 210 generates a first token relating to the identity of the group of users.

[0148] A step 803 may correspond to step 604 of Figure 6A, wherein sending the second MFA request is upon receiving an identity of group of users. The first server 210 may request for the user identity of the first user 100. The user identity of the first user 100 is at least one second client ID, along with e.g., a client secret relating to the first user 100. The request is send using a HTTP request message.

[0149] A step 804 may correspond to step 608, the user identity of the first user 100 is provided.

[0150] A step 805 may correspond to step 609, wherein the user identity of the first user 100 is sent via M2M communication using HTTP request message such as an Access Token request of a client credential flow in OAuth2.0 RFC 6749 section 4.4.

[0151] In a step 806 and a step 807, the first server 210 validates the user identity of the first user 100, wherein validating comprises verifying that the group of users comprises the identity of the first user 100. Step 806 and 807 enables authorization of the first user 100 as the part of the group of users.

[0152] In the step 806, the first server 210 sends, to the data storage 230, the user identity of the first user 100. In the second embodiment the second server 220 sends the credential of the first user 100. The data storage 230 is a cloud OSS data storage 230. Sending the user identity of the comprises using e.g. an HTTP based message. In an alternative example, the data storage 230 is for example an LDAP data storage 230 or a data storage 230 comprising user identities.

[0153] In the step 807, the second server 220 receives, from the data storage 230, a first indication that the group of users comprises the user identity of the first user 100. In the second embodiment, the first indication is comprised in e.g. an HTTP based message.

[0154] The first server 210 performs at least the part of the first part of the MFA of the first user 100. Performing enables partly authenticating the first user 100 using a first factor. Performing may correspond to step 610 of Figure 6A.

[0155] Performing at least the part of the first part of the MFA of the first user 100 (second user 110) corresponds to step 710 of Figure 7A. The second part of the first part of the MFA of the first user 100 (second user 110) is performed by the data storage 230 by verifying the user identity of the first user by the data storage 230. The first factor is relating to the client ID and e.g., the client secret of the first user 100 (second user 110). Performing at least a part of the first part of the MFA is comprised in steps 806 and 807. Initiating the session may comprise starting the session by the first server 210. At this stage the session is not validated yet.

[0156] A step 808 may correspond to step 611 of Figure 6A, wherein the first MFA request is sent via M2M communication using HTTP request message such as an Access Token request of a client credential flow in OAuth2.0 RFC 6749 section 4.4.

[0157] A step 809 may correspond to step 612 of Figure 6A, wherein the second factor comprises a one-time password or a time-based One-Time Password (TOTP). Performing at least the part of the second part of the MFA of the first user 100 comprises sending an OTP or TOTP to the first communication device 260. Sending is done using, e.g., an out- of band channel such as a short message service (SMS), E-mail, social login, WebAuthn / FIDO / Passkeys etc. Performing at least the part of the second part of the MFA further comprises providing by the user the OTP or TOTP to the second server 220 via the first communication device 260. The first communication device 260 sends the OTP to a login server, the second server 220 or the client device. A second part of the second part of the MFA of the first user 100 is performed by the first communication device 260.

[0158] A step 810 may correspond to step 613 of Figure 6A, wherein the second token comprises the user attributes of the first user 100, i.e., the identity of the first user 100. The second token is a part of a JWT OIDC token. The second server 220 generates the third token, wherein the third token correspond to an access token with a custom claim defining a relation of the identity of group of users to the user identity of the first user 100. The third token corresponds to an access token.

[0159] A step 811 may correspond to step 614 of Figure 6A, wherein the third token is sent via M2M communication using HTTP response message such as an Access Token response of the client credential flow in OAuth2.0 RFC 6749 section 4.4. or an OIDC token answer API.

[0160] Upon successful second part of the MFA of the first user 100, the session is validated.

[0161] A step 812 may correspond to step 615 of Figure 6A, wherein granting access comprises generating, by the first server 210 an ID token.

[0162] The first user 100 is authenticated and may access via the first application the application using the session.

[0163] In the second embodiment the second user 110 opens the application using the first communication device 270.

[0164] In step 813, the first communication device 270 provides the user identity of the second user 110 to the second application device 250. The second application device 250 receives the identity of the second user 110 from the first communication device 270. The step 813 enables authentication of the second user 110 using the identity of the second user 110 within the session. The user identity of the second user 110 may comprise the client ID of the second user 110, along with e.g., the client secret relating to the second user 110. The second application device 250 is a client application. The user identity of the second user 110 is sent using a user-info message.

[0165] In a step 814, the second application device 250 sends the user identity of the first user 100 to the first server 210. The first server 210 receives, from the second application device 250, the user identity of the second user 110. The user identity of the second user 110 may be sent via M2M communication using HTTP request message such as an Access Token request of a client credential flow in OAuth2.0 RFC 6749 section 4.4. In a step 815 and a step 816, the first server 210 validates the user identity of the second user 110, wherein validating comprises verifying that the group of users comprises the identity of the second user 110. Step 815 and 816 enables authorization of the second user 110 as the part of the group of users.

[0166] In a step 815, the first server 210 sends, to the data storage 230, the user identity of the second user 110. Sending the user identity of the comprises using an ... message.

[0167] In the step 816, the second server 220 receives, from the data storage 230, a second indication that the group of users comprises the user identity of the second user 110. The second indication may be sent using e.g. an HTTP based message.

[0168] The first server 210 performs at least the part of the first part of the MFA of the second user 110. Performing enables partly authenticating the second user 110 using a first factor.

[0169] Performing at least the part of the first part of the MFA of the first user 100 (second user 110) corresponds to step 723 of Figure 7B. The first factor may be the client ID and e.g., the client secret of the second user 110. Performing at least a part of the first part of the MFA is comprised in steps 815 and 816.

[0170] In an example, beyond the second embodiment, the first factor for authenticating the second user 110 is different from the first factor for authenticating the first user 100.

[0171] A step 817 may correspond to step 622 of Figure 6B, wherein the second MFA request comprises the third token, wherein the third token comprises the first token and the second token. The second MFA request is a M2M communication-based message.

[0172] A step 818 may correspond to step 623 of Figure 6B.

[0173] In an example, the second factor for authenticating the second user 110 is different from the second factor for authenticating the first user 100.

[0174] A step 819 may correspond to step 624 of Figure 6B wherein, the second server 220 generates an updated third token, wherein the updated third token, comprises the first token and the updated second token. Generating the updated third token enables relating the identity of the group of users to the user identity of the first user 100 and the user identity of the second user 110. The updated third token comprises the custom claim defining a relation of the identity of group of users to the user identity of the first user 100 and the user identity of the second user 110. The updated third token comprising the first token and the updated second token corresponds to a refresh token. The refresh token is a strong containing a unique secret token.

[0175] A step 820 may correspond to step 625 of Figure 6B, and wherein, the updated third token is sent via M2M communication using HTTP response message such as an Access Token response of the client credential flow in OAuth2.0 RFC 6749 section 4.4. or an OIDC token answer API.

[0176] A step 821 may correspond to step 626 of Figure 6B, wherein granting access comprises generating, by the first server 210, an ID token.

[0177] The second user 110 is authenticated and may access via the second application device 250 the application using the session.

[0178] Figures 9A to 9B depict signaling diagrams of an embodiment of the exemplary interaction between the first user 100, the second user 110, the first application device 240, optionally the second application device 250, the first server 210, the second server 220, and the data storage 230 as shown in Figure 2. In figures 9A to 9B the communication device, the first user 100, the second user 110, the first application device 240, optionally the second application device 250, the first server 210, the second server 220, and the data storage 230 are depicted for illustration, even if not all entities are comprised in the interaction of each sub figure 9A to 9B. Figure 9A and 9B are illustrated on two pages for convenience, but they are understood as one single signaling diagram. The steps of Figure 9B continue where the steps of Figure 9A end. The data storage 230 relates herein to data storage 230 hardware.

[0179] In the third embodiment steps 901 to 909 of figure 9A are the same as steps 701 to 709 of Figure 7A, wherein the first application device 240 is an Ericsson intelligent controller (EIC).

[0180] A step 910 may correspond to step 610 of Figure 6A, wherein the first factor may be a biometrical factor, wherein performing comprises setting up a connectivity with the first communication device 260 (first communication device 270). Performing further comprises sending, to the first communication device 260 (first communication device 270), a third MFA request for a biometrical recognition of the first user 100 (second user 110). The first communication device 260 (first communication device 270) receives the third MFA request for the biometrical recognition of the first user 100 (second user 110). The first communication device 260 (first communication device 270) recognizes the first user 100 (second user 110) using the biometrical recognition such as a fingerprint of the first user 100 (second user 110) or a face of the first user 100. The first communication device 260 (first communication device 270) sends a confirmation of the biometrical recognition of the first user 100 (second user 110) to the first server 210. The first communication device 260 (first communication device 270) is performing by receiving, recognizing and sending a second part of the first part of the MFA. The first server 210 receives the confirmation of the biometrical recognition.

[0181] A step 911 may comprise validating the user identity of the first user 100, wherein validating comprises verifying that the group of users comprises the user identity of first user 100. Step 911 enables authorization of the first user 100 as the part of the group of users. The first server 210 may be a keyclock server, comprising a data storage 230. Verifying comprises checking in the data storage 230 that the group of users comprises the user identity of the first user 100. The step 911 may be comprised in step 910.

[0182] A step 912 may correspond to step 711 of Figure 7A.

[0183] A step 913 may correspond to step 612 of Figure 6A, wherein the second factor may be a location factor. Performing at least the part of the second part of the MFA of the first user 100 may comprise verifying the location of the first user 100 (second user 110). The second server 220 sends a third MFA request for the location to the first communication device 260 (first communication device 270). The first communication device 260 (first communication device 270) receives the third MFA request and determines the location of the first user 100 (second user 110). The first communication device 260 sends the location of the first user 100 to the second server 220. Verifying the location comprises checking that the location of the first user 100 (second user 110) is comprised a pre-defined geo location. In an example IP addresses or MAC addresses of the first communication device 260 (first communication device 270) is used. The first communication device 260 (first communication device 270) is performing by receiving, determining and sending a second part of the second part of the MFA for the first user 100 (second user 110).

[0184] Steps 914 to 917 may correspond 715 to 717 of Figure 7A.

[0185] Referring to figure 9B, in a step 918 the first application device 240 sends, to the second server 220, a request associated to the second user 110. The second server 220 receives, from the first application device 240, a request associated to the second user 110. The step 918 may enable an improved modular architecture. The first application device 240 contacts the second server 220 using an address preconfigured in the first application device 240. The request associated to the second user 110 may be a OIDC protocol-based message such as an OAuth 2.0 Authorization Request.

[0186] In a step 919, the second server 220 sends to the first server 210 the request associated to the second user. The request associated to the second user sent by the second server 220 comprises a verification request for verification of the second user 110. The first server 210 receives the verification request.

[0187] In the third embodiment, the verification request is a OIDC protocol-based message such as an OAuth 2.0 Authorization Request.

[0188] Step 921 to 923 are the same as step 720 to 722 of figure 7B.

[0189] Referring to figure 9B, a step 924 may correspond to step 621 of Figure 6B, wherein the first factor is a biometrical factor, wherein performing may comprise performing step 910 for the second user 110 using the first communication device 270 as described in step 910.

[0190] Step 924, further comprises step 925 of validating the user identity of the second user 110, wherein validating comprises verifying that the group of users comprises the user identity of second user 110. In an example, step 925 comprises performing a second part of the first part of the MFA of the second user 110. Verifying comprises checking in the data storage 230 that the group of users comprises the user identity of the second user 110. A step 926 may correspond to step 724 of Figure 7A.

[0191] A step 927 may correspond to step 623 of Figure 6B, wherein the second factor is a location factor. Performing comprises performing step 913 using the second user 110 and the first communication device 270 as described in step 913. In an example IP addresses or MAC addresses of the first communication device 270 are used.

[0192] Step 928 to 930 are corresponding to steps 728 to 730 of Figure 7B.

[0193] In an embodiment of the exemplary interaction between the first user 100, the second user 110, the first application device 240, the first server 210, the second server 220, and the data storage 230, the steps 701 to 710 are performed. In the embodiment steps 712 to 715 and 717 are performed by the first server 210. Further the steps 718 to 723, 725 to 728 and 730 are performed, wherein the steps 725 to 728 are performed by the first server 210, wherein the first server 210 is a keycloak server. The first application device 240 is a cloud native application such as a EIC application device of an Ericsson Intelligent Automation Platform Ecosystem (EIAP Ecosystem) application device or a virtual function-based application device.

[0194] In an embodiment of the exemplary interaction between the first user 100, the second user 110, the first application device 240, the second application device 250 optionally the second application device 250, the first server 210, the second server 220, and the data storage 230 the steps 701 to 730 are performed, wherein the steps 718 and 722 are performed by the second application device 250. In the embodiment the second user 110 starts a second application via the first application device 240 in step 718, wherein the second application is different from the application started by the first user 100. The second application device 250 is a web application device, EIC application device, an Ericsson Intelligent Automation Platform Ecosystem (EIAP Ecosystem) application device or a virtual function-based application device.

[0195] In an embodiment of the exemplary interaction of the first user 100, the second user 110, the first application device 240, the second application device 250, optionally the second application device 250, the first server 210, the second server 220, and the data storage 230, the steps 701 to 730 are performed, wherein the second user 110 requests access to the resource to which the first user 100 has requested access. In an embodiment of the exemplary interaction between the first user 100, the second user 110, the first application device 240, optionally the second application device 250, optionally the second application device 250, the first server 210, the second server 220, and the data storage 230, the steps 701 to 730 are performed, wherein a third authentication using a third factor, such as any factor listed in 610, is performed between step 727 and 728 by the second server 220 or by the third server. The third server being an OIDC provider server.

[0196] In an embodiment of the exemplary interaction, of the first user 100, the second user 110, the first application device 240, optionally the second application device 250, the first server 210, the second server 220, and the data storage 230, the steps 701 to 730 are performed. In the embodiment a third user starts the application in a step 731. Steps 718 to 730 will be repeated in steps 731 to 743, wherein the third user provides the user identity of the third user in the step 734, wherein the user identity of the third user is send by the first application device 240 or a second or a third application device to the first server 210 in the step 735, wherein the first server 210 performs at least the part of the first part of the MFA of the third user in the step 736 and the second server 220 performs at least the part of the second part of the MFA of the third user in the step 740. In the step 738 the user identity of the third user is sent to the data storage 230. The second server 220 generates the updated third token comprising the first token and the updated second token, wherein the updated second token comprises the user identity of the first user 100, the user identity of the second user 110, the user identity of the third user and the identity of the group of users. In the step 743 the first server 210 grants access to the third user.

[0197] In an embodiment of the exemplary interaction of the first user 100, the second user 110, the first application device 240, the second application device 250, the first server 210, the second server 220, and the data storage 230, the steps 801 to 821 are performed, wherein step 813, 814 and 821 are performed by the first application device 240.

[0198] In an embodiment of the exemplary interaction of the first user 100, the second user 110, the first application device 240, the second application device 250, optionally the second application device 250, the first server 210, the second server 220, and the data storage 230, the steps 801 to 821 are performed, wherein step 806, 807, 815 and 816 are performed by the second server 220.

[0199] In an embodiment of the exemplary interaction, the steps 801 to 821 are performed, wherein a third authentication using a third factor, such as any factor listed in 610, is performed between step 818 and 819 by the second server 220 or by the third server. The third server being a keycloak server.

[0200] In an embodiment the first and second server 220 relating to steps 701 to 730, 801 to 821 or 901 to 930 are for example a keycloak server, a Forgerock server, an OIDC provider server or any other Host Configuration protocol (HCP) based server.

[0201] In an embodiment steps 801 to 807, 809 to 810, 812, 813 to 816, 818 to 819 and 821 are performed, wherein the second server 220 is the first server 210 and wherein steps 809 to 810 and 818 to 819 are performed by the first server 210, and wherein the first server 210 generates the third token, and wherein the first server 210 generates the updated third token.

[0202] In an embodiment of the exemplary interaction, the steps 901 to 930 are performed, wherein steps 917 to 918 and 921 to 923 are performed by the second application device 250.

[0203] In an embodiment the steps 901 to 930 are performed, wherein a third authentication using a third factor, such as any factor listed in step 610, is performed between step 927 and 928 by the second server 220 or by a third server. The third server being an OIDC provider server.

[0204] In an embodiment the steps 901 to 930 are performed, wherein step 911 of validating the user identity of the first user 100 is performed by the second server 220 and / or step 925 validating the user identity of the second user 110 is performed by the second server 220. In the embodiment performing the first authentication comprises using any factor listed in step 610.

[0205] In an embodiment the first server 210 is the second server 220, and the MFA is performed by the first server 210. In an example step 901 to 930 are performed, except of step 912, 915, 919, 926 and 929, wherein the first server 210 is the second server 220, and the first server 210 generates the third token, wherein the first server 210 generates the updated third token. In an embodiment step 901 to 930 are performed wherein steps 917, 918 and 921 to 923 are performed by the second application device 250.

[0206] In an embodiment of the exemplary interaction, wherein the first server 210 or the second server 220 comprises the data storage 230.

[0207] In an embodiment of the exemplary interactions, the data storage 230 is a LDAP data storage 230, a cloud Object Storage Service (OSS) data storage 230 or a data storage 230 comprising user identities.

[0208] In an example, the client application relates to any application, plug-in, helper, component or other executable code that runs on, e.g., the user’s communication device; examples of client applications include those that provide instant messaging, chat, email, data, file viewing, media playing, file sharing, games, internet navigation, search and other services. In a further example the client application relates to the web browser application requested by the user in order to use a resource. The client application is for example an EIC.

[0209] Figures 10A to 10B illustrate flowcharts illustrating embodiments of the method 1000 performed by the first server 210 as shown in Figure 2 for supporting authentication to a session. Figure 10A and 10B are illustrated on two pages for convenience, but they are understood as one single signaling diagram. The steps of Figure 10B continue where the steps of Figure 10A end.

[0210] In a step 1002, the first server 210 receives from a first application device 240, a first token, wherein the first token relates to the session, and the first token relates to a group of users. This step 1002 relates to step 602 of figure 6A and exemplary to step 702 of figure 7B, step 802 of figure 8A or step 902 of figure 9A.

[0211] In an optional step 1004, the first server 210 determines that the first token received from the first application device 240 is not valid. This step 1004 relates to step 603 of figure 6A and exemplary to step 703 of figure 7B or step 903 of figure 9A.

[0212] In an optional step 1006, the first server 210 sends, to the first application device 240, a first identification request for identification of the first user 100 or the group of users. This step 1006 relates to step 604 and / or 607 of figure 6A and exemplary to step 704 and / or 707 of figure 7B, step 803 of figure 8A or step 904 and / or step 907 of figure 9A.

[0213] In an optional step 1008, the first server 210 receives, from the first application device 240, an identity of the group of users. This step 1008 relates to step 606 of figure 6A and exemplary to step 706 of figure 7B, step 802 of figure 8A or step 906 of figure 9A.

[0214] In an optional step 1010, the first server 210 upon receiving an identity of group of users, sending, to the first application device 240, a second identification request for identification of the first user 100. This step 1010 relates to step 607 of figure 6A and exemplary to step 707 of figure 7B, step 803 of figure 8A or step 907 of figure 9A.

[0215] In an optional step 1012, the first server 210 receives, from the first application device 240, the user identity of the first user 100. This step 1012 relates to step 609 of figure 6A and exemplary to step 709 of figure 7B, step 805 of figure 8A or step 909 of figure 9A.

[0216] In an optional step 1014, the first server 210 performs at least the part of the first part of the MFA of the first user 100. Optionally, the step 1014 of performing 1014 at least the part of the first part of the MFA of the first user 100 comprises a step 1014a of validating 1014a the user identity of the first user 100 wherein validating 1014a optionally comprises a step 1014b of verifying 1014b that the group of users comprises the user identity of the first user 100. Optionally, the step 1014b of verifying that the group of users comprises the identity of the first user 100 comprises a step 1014c of sending 1014c, to the data storage 230, the user identity of the first user, and a step 1014d of receiving 1014d, from the data storage 230 the indication that the group of users comprises the user identity of the first user 100. This step 1014 relates to step 610 of figure 6A and exemplary to step 710 of figure 7B, step 806 and / or step 807 of figure 8A or step 910 of figure 9A.

[0217] In a step 1016, the first server 210 sends to the second server 220, a first MFA request for performing at least a part of a second part of the MFA of the first user 100, wherein the first MFA request comprises the first token. This step 1016 relates to step 610 of figure 6A and exemplary to step 710 of figure 7B, step 806 and / or step 807 of figure 8A or step 910 of figure 9A. In a step 1018, the first server 210 receives, from the second server 220, a third token comprising the first token and a second token comprising a user identity of the first user 100. This step 1018 relates to step 614 of figure 6A and exemplary to step 716 of figure 7B, step 811 of figure 8A or step 915 of figure 9A.

[0218] Referring to figure 10B, in a step 1020, the first server 210 grants access to the first user 100 to the session based on the third token. Optionally, the step 1020 of granting 1020 access to the first user 100 to the session, comprises a step 1020a of sending 1020a, to the first application device 240, the third token comprising the first token, the second token and an identity token. This step 1020 relates to step 615 of figure 6A and exemplary to step 717 of figure 7B, step 812 of figure 8A or step 916 of figure 9A.

[0219] In an optional step 1022, the first server 210 obtains, from a second application device 250, the request associated to the second user. This step 1022 relates to step 617 of figure 6B and exemplary to step 717 of figure 7B, step 821 of figure 8B or step 916 of figure 9B.

[0220] In an optional step 1024, the first server 210 sends, to a second application device 250, a third identification request for identification of the second user 110. This step 1024 relates to step 618 of figure 6B and exemplary to step 720 of figure 7B, or step 921 of figure 9B.

[0221] In an optional step 1026, the first server 210 receives from a second application device 250, the user identity of the second user 110. This step 1026 relates to step 620 of figure 6B and exemplary to step 722 of figure 7B, step 814 of figure 8B or step 922 of figure 9B.

[0222] In a step 1028, the first server 210 performs at least a part of the first part of the MFA of a second user 110. Optionally, the step of performing 1028 at least the part of the first part of the MFA of the second user 110 comprises a step 1028a of validating 1028a the user identity of the second user 110, wherein validating 1028a comprises a step 1028b of verifying 1028b that the group of users comprises the user identity of the second user 110. Optionally, verifying 1028b that the group of users comprises the identity of the second user 110 comprises a step 1028c of sending 1028c, to a data storage 230, the user identity of the second user 110, and a step 1028d of receiving 1028d, from the data storage 230, the indication that the group of users comprises the user identity of the second user 110. This step 1028 relates to step 621 of figure 6B and exemplary to step 724 of figure 7B, step 815 and / or 816 of figure 8B or step 924 of figure 9B.

[0223] In a step 1030, the first server 210 sends, to the second server 220, the second MFA request. This step 1030 relates to step 622 of figure 6B and exemplary to step 724 of figure 7B, step 817 of figure 8B or step 926 of figure 9B.

[0224] In a step 1032, the first server 210 receives, from the second server 220, an updated third token comprising the first token and an updated second token comprising a user identity of the first user 100. This step 1032 relates to step 625 of figure 6B and exemplary to step 729 of figure 7B, step 820 of figure 8B or step 929 of figure 9B.

[0225] In a step 1034, the first server 210 grants access to the second user 110 to the session based on the updated third token. Optionally the step of granting 1034 access to the second user 110 to the session, comprises a step 1034a of sending 1034a, to a second application device 250, the updated third token This step 1034 relates to step 626 of figure 6B and exemplary to step 730 of figure 7B, step 821 of figure 8B or step 930 of figure 9B.

[0226] Figures 11A to 11 B illustrate flowcharts illustrating embodiments of the method 1100 performed by the second server 220 as shown in Figure 2 for supporting authentication to a session. Figure 11 A and 11 B are illustrated on two pages for convenience, but they are understood as one single signaling diagram. The steps of Figure 11 B continue where the steps of Figure 11 A end.

[0227] Referring to Figure 11 A, in a step 1102, the second server 220 receives from a first server 210, a first MFA request for performing at least a part of a second part of an MFA of a first user 100, wherein the first MFA request comprises a first token, the first token relating to a group of users and to the session. This step 1102 relates to step 611 of figure 6A and exemplary to step 711 of figure 7A, step 808 of figure 8A or step 912 of figure 9A.

[0228] In an optional step 1104, the second server 220 performs at least the part of the second part of the MFA of the first user 100. Optionally, the step 1104 of performing 1104 at least the part of the second part of the MFA of the first user 100, comprises a step 1104a of validating 1104a the user identity of the first user 100, wherein validating 1104a comprises a step 1104b of verifying 1104b that the group of users comprises the user identity of the first user 100. Optionally, verifying 1104b that the group of users comprises the identity of the first user 100 comprises a step 1104c of sending 1104c, to a data storage 230, the user identity of the first user 100, and a step 1104d of receiving 1104d, from the data storage 230, an indication that the group of users comprises the identity of the first user 100. This step 1104 relates to step 612 of figure 6A and exemplary to step 712, step 713 and / or step 714 of figure 7A, step 809 of figure 8A or step 913 of figure 9A.

[0229] In a step 1106, the second server 220 generates a second token comprising a user identity of the first user 100. This step 1106 relates to step 613 of figure 6A and exemplary to step 715 of figure 7A, step 810 of figure 8A or step 914 of figure 9A.

[0230] In a step 1108, the second server 220 sends, to the first server 210, a third token, comprising the first token and the second token. This step 1108 relates to step 614 of figure 6A and exemplary to step 716 of figure 7A, step 811 of figure 8A or step 915 of figure 9A.

[0231] In an optional step 1110, the second server 220 receives from a second application device 250, a request associated to the second user 110.

[0232] In an optional step 1112, the second server 220 sends, to the first server 210, associated to the second user 110.

[0233] Referring to Figure 11 B, in a step 1114, the second server 220 receives, from the first server 210, the second MFA request. This step 1114 relates to step 622 of figure 6A and exemplary to step 724 of figure 7A, step 817 of figure 8A or step 926 of figure 9A.

[0234] In an optional step 1116, the second server 220 performs at least the part of the second part of the MFA of the second user 110. Optionally, the step 1116 of performing 1116 at least the part of the second part of the MFA of the second user 110, comprises a step 1116a of validating 1116a the user identity of the second user 110, wherein validating 1116a comprises a step 1116b of verifying 1116b that the group of users comprises the identity of the second user 110. Optionally, verifying 1116b that the group of users comprises the identity of the second user 110 comprises a step 1116c of sending 1116c, to a data storage 230, the user identity of the second user 110, and a step 1116d of receiving 1116d, from the data storage 230, the indication that the group of users comprises the identity of the second user 110. This step 1116 relates to step 623 of figure 6A and exemplary to step 725, 726 or 727 of figure 7A, step 818 of figure 8A or step 927 of figure 9A.

[0235] In a step 1118, the second server 220 updates the second token, wherein the updated second token comprises the user identity of the first user 100 and a user identity of the second user 110. This step 1118 relates to step 624 of figure 6A and exemplary to step 728 of figure 7A, step 819 of figure 8A or step 928 of figure 9A.

[0236] In a step 1120, the second server 220 sends, to the first server 210, the updated third token comprising the first token and the updated second token. This step 1120 relates to step 625 of figure 6A and exemplary to step 729 of figure 7A, step 820 of figure 8A or step 929 of figure 9A.

[0237] Figure 12 illustrates a block diagram illustrating embodiments of the first server 210 in further detail. In practice, the steps 1002 to 1034 of the method 1000 performed by the first server 210 are performed by a processing circuitry 1204, embodied in one or more processors and / or microprocessors arranged to execute a computer program 1201 that is downloaded to a computer program product 1205, here in the form of a suitable computer readable storage medium 1202 associated with the microprocessor. The computer readable storage medium 1202 may be a memory, such as a random access memory (RAM) or a read-only memory (ROM), or a tangible non-volatile computer readable storage medium, such as flash memory or a hard disk drive, or any combination thereof. The computer program 1201 comprises computer-executable instructions stored or downloaded to the computer readable storage medium 1202 and are executable by the processing circuitry 1204. Alternatively, the computer program 1201 may be transferred to the computer readable storage medium 1202 using a suitable computer program product, such as a memory stick or in a memory of a device. Thus, the computer program 1201 may be stored in any suitable manner in the computer program product. The processing circuity 1204 is arranged to cause the first server to carry out the steps 1002 to 1034 of the method 1000 in accordance with any of the of the described embodiments for steps 1002 to 1034. The processing circuitry 1204 is in one embodiment one or more general-purpose processors wherein each one of the general purpose processors includes one or more cores, but may alternatively be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a complex programmable logic device (CPLD), etc. An I / O interface 1203 is provided for communicating with external and / or internal entities using wired communications, e.g., based on Ethernet, and / or wireless communications, e.g., WiFi, and / or a cellular network corresponding to one or a combination of 5G cellular networks, LTE, LTE-advanced, UMTS, or any other current or future wireless network, such as a future 3GPP 6G network, as long as the principles described below are applicable.

[0238] Figure 12 illustrates a block diagram illustrating embodiments of the second server 220 in further detail. In practice, the steps 1102 to 1120 of the method 1100 performed by the second server 220 are performed by a processing circuitry 1304, embodied in one or more processors and / or microprocessors arranged to execute a computer program 1301 that is downloaded to a computer program product 1305, here in the form of a suitable computer readable storage medium 1302 associated with the microprocessor. The computer readable storage medium 1302 may be a memory, such as a random access memory (RAM) or a read-only memory (ROM), or a tangible non-volatile computer readable storage medium, such as flash memory or a hard disk drive, or any combination thereof. The computer program 1301 comprises computer-executable instructions stored or downloaded to the computer readable storage medium 1302 and are executable by the processing circuitry 1304. Alternatively, the computer program 1301 may be transferred to the computer readable storage medium 1302 using a suitable computer program product, such as a memory stick or in a memory of a device. Thus, the computer program 1301 may be stored in any suitable manner in the computer program product. The processing circuity 1304 is arranged to cause the second server 220 to carry out the steps 1102 to 1120 of the method 1100 in accordance with any of the of the described embodiments for steps 1102 to 1120. The processing circuitry 1304 is in one embodiment one or more general-purpose processors wherein each one of the general purpose processors includes one or more cores, but may alternatively be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a complex programmable logic device (CPLD), etc. An I / O interface 1303 is provided for communicating with external and / or internal entities using wired communications, e.g., based on Ethernet, and / or wireless communications, e.g., Wi-Fi, and / or a cellular network corresponding to one or a combination of 5G cellular networks, LTE, LTE-advanced, UMTS, or any other current or future wireless network, such as a future 3GPP 6G network, as long as the principles described below are applicable.

Claims

48CLAIMS:1 . A method performed by a first server (210) for supporting authentication to a session, the method comprises: receiving (310), from a first application device (240), a first token, wherein the first token relates to the session, and the first token relates to a group of users; upon successful first part of a multi-factor authentication, MFA, of a first user (100) associated to the first application device (240), initiating (320) the session; sending (330), to a second server (220), a first MFA request for performing at least a part of a second part of the MFA of the first user (100), wherein the first MFA request comprises the first token; receiving (340), from the second server (220), a third token comprising the first token and a second token comprising a user identity of the first user (100); granting (350) access to the first user (100) to the session based on the third token; upon obtaining a request associated to a second user (110), performing (360) at least a part of a first part of an MFA of the second user (110); sending (370), to the second server (220), a second MFA request for performing at least a part of the second part of the MFA of the second user (110); receiving (380), from the second server (220), an updated third token comprising the first token and an updated second token comprising the user identity of the first user (100) and a user identity of the second user (110); and granting (390) access to the second user (110) to the session based on the updated third token.

2. The method according to claim 1 , wherein initiating (320) the session comprises starting the session by the first server (210).

493. The method according to any of the previous claims, the method comprising: receiving (1012), from the first application device (240), the user identity of the first user (100); and performing (1014) at least the part of the first part of the MFA of the first user (100).

4. The method according to claim 3, wherein performing (1014) at least the part of the first part of the MFA of the first user (100) comprises: validating (1014a) the user identity of the first user (100), wherein validating (1014a) comprises verifying (1014b) that the group of users comprises the user identity of the first user (100).

5. The method according to claim 4, wherein verifying (1014b) that the group of users comprises the identity of the first user (100) comprises: sending (1014c), to a data storage (230), the user identity of the first user (100); and receiving (1014d), from the data storage (230), an indication that the group of users comprises the user identity of the first user (100).

6. The method according to any of the previous claims, wherein performing (360) at least the part of the first part of the MFA of the second user (110) comprises: validating (1028a) the user identity of the second user (110), wherein validating (1028a) comprises verifying (1028b) that the group of users comprises the user identity of the second user (110).

7. The method according to claim 6, wherein verifying (1028b) that the group of users comprises the identity of the second user (110) comprises: sending (1028c), to a data storage (230), the user identity of the second user (110); and50 receiving (1028d), from the data storage (230), an indication that the group of users comprises the user identity of the second user (110).

8. The method according to any of claims 4 to 7, wherein verifying (1014b, 1028b), comprises using a Lightweight Directory Access Protocol, LDAP, directory.

9. The method according to any of the previous claims, the method comprising: receiving (1026), from a second application device (250), the user identity of the second user (110).

10. The method according to any of the previous claims, wherein the first MFA request comprises the user identity of the first user (100), and / or wherein the second MFA request comprises the user identity of the second user (110).11 . The method according to any of the previous claims, wherein the third token is a session access token and / or wherein the updated third token is an updated session access token.

12. The method according to any of the previous claims, the method comprising: determining (1004) that the first token received from the first application device (240) is not valid; sending (1006), to the first application device (240), a first identification request for identification of the first user (100) or the group of users; and receiving (1008), from the first application device (240), an identity of the group of users.

13. The method according to claim 12, wherein sending (1006) the first identification request comprises sending a first pointer to a first login server.5114. The method according to any of claims 12 or 13, the method comprising: upon receiving (1008) an identity of group of users, sending (1010), to the first application device (240), a second identification request for identification of the first user (100).

15. The method according to claim 14, wherein sending (1010) the second identification request comprises sending a second pointer to a second login server.

16. The method according to any of the previous claims, the method comprising: obtaining (1022), from a second application device (250), the request associated to the second user (110); and sending (1024), to a second application device (250), a third identification request for identification of the second user (110).

17. The method according to claim 16, wherein sending (1024) the third identification request comprises sending a third pointer to a third login server.

18. The method according to any of the previous claims, wherein the user identity of the first user (100) is a credential of the first user (100) and / or the user identity of the second user (110) is a credential of the second user (110).

19. The method according to any of the previous claims, wherein granting (350) access to the first user (100) to the session, comprises sending (1020a), to the first application device (240), the third token comprising the first token, the second token and an identity token.

20. The method according to any of the previous claims, wherein granting (390) access to the second user (110) to the session, comprisessending (1034a), to a second application device (250), the updated third token.21 . The method according to any of the previous claims, wherein the second server (220) is an authenticator for at least the part of the second part of the MFA.

22. A method performed by a second server (220) for supporting authentication to a session, the method comprises: receiving (410), from a first server (210), a first multi-factor authentication, MFA, request for performing at least a part of a second part of a MFA of a first user (100), wherein the first MFA request comprises a first token, the first token relating to a group of users and to the session; generating (420) a second token comprising a user identity of the first user (100); sending (430), to the first server (210), a third token, comprising the first token and the second token; receiving (440), from the first server (210), a second MFA request for performing at least the part of the second part of the MFA of a second user (110); updating (450) the second token, wherein the updated second token comprises the user identity of the first user (100) and a user identity of the second user (110); and sending (460), to the first server (210), an updated third token comprising the first token and the updated second token.

23. The method according to claim 22, the method comprises: receiving (1110), from a second application device (250), a request associated to the second user (110); and sending (1112), to the first server (210), the request associated to the second user (110).

24. The method according to any of claims 22 to 23, wherein the first MFA request comprises the user identity of the first user (100), and / or wherein thesecond MFA request comprises the user identity of the second user (110).

25. The method according to any of claims 22 to 24, wherein the method comprises: performing (1104) at least the part of the second part of the MFA of the first user (100).

26. The method according to any of claims 22 to 25, wherein the method comprises: performing (1116) at least the part of the second part of the MFA of the second user (110).

27. The method according to claim 25, wherein performing (1104) at least the part of the second part of the MFA of the first user (100), comprises: validating (1104a) the user identity of the first user (100), wherein validating (1104a) comprises verifying (1104b) that the group of users comprises the user identity of the first user (100).

28. The method according to claim 27, wherein verifying (1104b) that the group of users comprises the identity of the first user (100) comprises: sending (1104c), to a data storage (230), the user identity of the first user (100); and receiving (1104d), from the data storage (230), an indication that the group of users comprises the identity of the first user (100).

29. The method according to claim26, wherein performing (1116) at least the part of the second part of the MFA of the second user (110), comprises: validating (1116a) the user identity of the second user (110), wherein validating (1116a) comprises verifying (1116b) that the group of users comprises the identity of the second user (110).

30. The method according to claim 29, wherein verifying (1116b) that the group of users comprises the identity of the second user (110) comprises:54 sending (1116c), to a data storage (230), the user identity of the second user (110); and receiving (1116d), from the data storage (230), an indication that the group of users comprises the identity of the second user (110).31 . The method according to any of claims 27 to 30, wherein verifying (1104b, 1116b) comprises using a Lightweight Directory Access Protocol, LDAP, directory.

32. The method according to any of claims 22 to 31 , wherein the third token is a session access token and / or wherein the updated third token is an updated session access token.

33. The method according to 22 to 32, wherein the first server (210) is an authenticator for at least a part of the first part of the, MFA and / or an identity provider server.

34. A first server (210) configured to: receive, from a first application device (240), a first token, wherein the first token relates to the session, and the first token relates to a group of users; upon successful first part of a multi-factor authentication, MFA, of a first user (100) associated to the first application device (240), initiate the session; send, to a second server (220), a first MFA request for performing at least a part of a second part of the MFA of the first user (100), wherein the first MFA request comprises the first token; receive, from the second server (220), a third token comprising the first token and a second token comprising a user identity of the first user (100); grant access to the first user (100) to the session based on the third token; upon obtaining a request associated to a second user (110), perform at least a part of a first part of the MFA of the second user (110);55 send, to the second server (220), a second MFA request for performing at least a part of the second part of the MFA of the second user (110); receive, from the second server (220), an updated third token comprising the first token and an updated second token comprising the user identity of the first user (100) and a user identity of the second user (110); and grant access to the second user (110) to the session based on the updated third token.

35. The first server (210) according to claim 34, configured to perform the method according to any of claims 2 to claim 21 .

36. A first server (210), comprising processing circuitry (1204) and a computer readable storage medium (1202), the computer readable storage medium (1202) containing instructions executable by the processing circuitry (1204), whereby the first server (210) is configured to: receive, from a first application device (240), a first token, wherein the first token relates to the session, and the first token relates to a group of users; upon successful first part of a multi-factor authentication, MFA, of a first user (100) associated to the first application device (240), initiate the session; send, to a second server (220), a first MFA request for performing at least a part of a second part of the MFA of the first user (100), wherein the first MFA request comprises the first token; receive, from the second server (220), a third token comprising the first token and a second token comprising a user identity of the first user (100); grant access to the first user (100) to the session based on the third token; upon obtaining a request associated to a second user (110), perform at least a part of a first part of the MFA of the second user (110); send, to the second server (220), a second MFA request for performing at least a part of the second part of the MFA of the second user (110); receive, from the second server (220), an updated third token comprising the first token and an updated second token comprising the user identity of the first user (100) and a user identity of the second user (110); and56 grant access to the second user (110) to the session based on the updated third token.

37. The first server (210) according to claim 36, configured to perform the method according to any of claims 2 to claim 21 .

38. A second server (220), configured to: receive, from a first server (210), a first multi-factor authentication, MFA, request for performing at least a part of a second part of an MFA of a first user (100), wherein the first MFA request comprises a first token, the first token relating to a group of users and to the session; generate a second token comprising a user identity of the first user (100); send, to the first server (210), a third token, comprising the first token and the second token; receive, from the first server (210), a second MFA request for performing at least the part of the second part of the MFA of a second user (110); update the second token, wherein the updated second token comprises the user identity of the first user (100) and a user identity of the second user (110); and send, to the first server (210), an updated third token comprising the first token and the updated second token.

39. The second server (220) according to claim 38, configured to perform the method according to any of claims 23 to claim 33.

40. A second server (220), comprising processing circuitry (1304) and a computer readable storage medium (1302), the computer readable storage medium (1302) containing instructions executable by the processing circuitry (1304), whereby the second server (220) is configured to: receive, from a first server (210), a first multi-factor authentication, MFA, request for performing at least a part of a second part of a MFA of a first57 user (100), wherein the first MFA request comprises a first token, the first token relating to a group of users and to the session; generate a second token comprising a user identity of the first user (100); send, to the first server (210), a third token, comprising the first token and the second token; receive, from the first server (210), a second MFA request for performing at least the part of the second part of the MFA of a second user (110); update the second token, wherein the updated second token comprises the user identity of the first user (100) and a user identity of the second user (110); send, to the first server (210), an updated third token comprising the first token and the updated second token.41 .The second server (220) according to claim 40, configured to perform the method according to any of claims 23 to 33.

42. A system comprising a first server (210) performing a method according to claims 1 to 21 and a second server (220) performing a method according to claim 22 to 33, the first server (210) being configured to: receive by the first server (210), from a first application device (240), a first token, wherein the first token relates to the session, and the first token relates to a group of users; upon successful first part of a multi-factor authentication, MFA, of a first user (100) associated to the first application device (240), initiate, by the first server (210) the session; send, by the first server (210) to the second server (220), a first MFA request for performing at least a part of a second part of the MFA of the first user (100), wherein the first MFA request comprises the first token;58 receive, by the first server (210) from the second server (220), a third token comprising the first token and a second token comprising a user identity of the first user (100); grant, by the first server (210), access to the first user (100) to the session based on the third token; upon obtaining, by the first server (210) a request associated to a second user (110), perform, by the first server (210), at least a part of a first part of an MFA of the second user (110); send, by the first server (210) to the second server (220), a second MFA request for performing at least a part of the second part of the MFA of the second user (110); receive, by the first server (210) from the second server (220), an updated third token comprising the first token and an updated second token comprising the user identity of the first user (100) and a user identity of the second user (110); and grant, by the first server (210), access to the second user (110) to the session based on the updated third token.

43. A system comprising a first server (210) performing a method according to claims 1 to 21 and a second server (220) performing a method according to claim 22 to 33, the second server (220) being configured to: receive, by the second server (220) from the first server (210), a first multi-factor authentication, MFA, request for performing at least a part of a second part of an MFA of a first user (100), wherein the first MFA request comprises a first token, the first token relating to a group of users and to the session; generate, by the second server (220), a second token comprising a user identity of the first user (100); send, by the first server (210) to the first server (210), a third token, comprising the first token and the second token; receive, by the first server (210) from the first server (210), a second MFA request for performing at least the part of the second part of the MFA of a second user (110);59 update, by the first server (210) the second token, wherein the updated second token comprises the user identity of the first user (100) and a user identity of the second user (110); send, by the first server (210) to the first server (210), an updated third token comprising the first token and the updated second token.

44. A computer program (1201 ,1301 ) comprising instructions which, when executed on: processing circuitry (1204) of a first server (210), cause the processing circuitry (1204) of the first server (210) to carry out the method according to any one of claims 1 to 21 ; and / or processing circuitry (1304) of a second server (220), cause the processing circuitry (1304) of the second server (220) to carry out the method according to any of claims 22 to 33.

45. A tangible, non-transitory-computer-readable medium (1202, 1302) comprising instructions that, when executed on processing circuitry (1204) of a first server (210), cause the processing circuitry (1204) of the first server (210) to carry out the method according to any one of claims 1 to 21 ; and / or processing circuitry (1304) of a second server (220), cause the processing circuitry (1304) of the second server (220) to carry out the method according to any of claims 22 to 33.

Images