FORM 2
THE PATENTS ACT, 1970 (39 OF 1970) & THE PATENT RULES, 2003
COMPLETE SPECIFICATION
(See section 10 and rule 13)
“METHOD AND SYSTEM FOR AUTHENTICATING A USER ACCESS BASED ON ONE OR MORE AUTHENTICATION
KEYS”
We, Jio Platforms Limited, an Indian National, of Office - 101, Saffron, Nr. Centre Point, Panchwati 5 Rasta, Ambawadi, Ahmedabad - 380006, Gujarat, India.
The following specification particularly describes the invention and the manner in which it is to be performed.

METHOD AND SYSTEM FOR AUTHENTICATING A USER ACCESS BASED ON ONE OR MORE AUTHENTICATION KEYS
TECHNICAL FIELD
[0001] Embodiments of the present disclosure generally relate to authentication management systems and more particularly, embodiments of the present disclosure relate to methods and systems for authenticating a user access based on one or more authentication keys.
BACKGROUND
[0002] The following description of the related art is intended to provide background information pertaining to the field of the disclosure. This section may include certain aspects of the art that may be related to various features of the present disclosure. However, it should be appreciated that this section is used only to enhance the understanding of the reader with respect to the present disclosure, and not as admissions of the prior art.
[0003] With the advancement of technology, a majority of organizations adopt microservice platforms and expose these microservice platforms to users through various Application Programming Interfaces (APIs). These APIs are needed to be secured in order to restrict malicious users from accessing unauthorized 3rd party data. The organizations often face the challenge of implementing a secure and scalable authentication solution that restricts the malicious users for accessing the one or more microservice platforms and along the way provide better customer experience to authenticated users associated with the microservice platforms.
[0004] Conventionally, the APIs are secured using a user authentication system, which may involve one or more details associated with user (such as username, password) and based on the verification of the one or more details, the user may

access a plurality of services, offered by the one or more microservice platforms. Further, the APIs are also secured by providing limited access to the users based on the permissions given to such user. For example – CEO of Company X that owns the API may be able to access all the microservices, but an associate in the Company X may be able to access a limited number of services.
[0005] Further, over the period of time various solutions have been developed to restrict malicious users from accessing unauthorized information from one or microservice platforms. However, there are certain challenges with existing solutions. The existing solutions are unable to handle a user traffic when such one or more microservice platforms are used by the user at a larger level or when the the one or more microservices platforms are scaled up. Further, scaling of the one or more microservice platforms leads to increased complexity & overhead of the the one or more microservice platforms as well as higher costs & fees for the usage and maintenance of the service. This further leads to chances of crashes on the one or more service platforms & the user experience can deteriorate.
[0006] Thus, there exists an imperative need in the art to system and method for authenticating a user access based on one or more authentication keys to restrict malicious users from accessing unauthorized information, which the present disclosure aims to address.
SUMMARY
[0007] This section is provided to introduce certain aspects of the present disclosure in a simplified form that are further described below in the detailed description. This summary is not intended to identify the key features or the scope of the claimed subject matter.
[0008] An aspect of the present disclosure may relate to a method for authenticating a user access based on one or more authentication keys. The method comprises

receiving, at a transceiver unit from a user, an access request to access a service associated with a platform, wherein the access request comprises an authentication key. Further, the method comprises identifying, by an analysis unit, a key type associated with the authentication key, wherein the key type is at least one of an Application Programming Interface (API) key, a JSON Web Tokens (JWT) key and an Open Authorization (oAuth) key. Further, the method comprises validating, by the analysis unit, the authentication key based on the key type and a set of prestored authentication keys associated with the user, wherein the set of prestored authentication keys comprises one or more of a prestored API key associated with the user, a prestored JWT key associated with the user, and a prestored oAuth key associated with the user. Further, the method comprises determining, by the analysis unit, a validation status associated with the authentication key, wherein the validation status is at least one of a positive validation status and a negative validation status. Further, the system comprises granting, by a control unit to the user, the access to the service associated with the platform based on the positive validation status.
[0009] In an exemplary aspect of the present disclosure, the validation of the authentication key is performed via one or more gateways associated with the platform.
[0010] In an exemplary aspect of the present disclosure, the method further comprises identifying, by the analysis unit, a target prestored authentication key from the set of prestored authentication keys associated with the user based on the identified key type.
[0011] In an exemplary aspect of the present disclosure, the positive validation status is determined in an event, the authentication key is a successful match with the target prestored authentication key.

[0012] In an exemplary aspect of the present disclosure, the negative validation status is determined in an event, the authentication key is an unsuccessful match with the target prestored authentication key.
[0013] In an exemplary aspect of the present disclosure, the method further comprises rejecting, by the control unit to the user, the access to the service associated with the platform based on the negative validation status.
[0014] In an exemplary aspect of the present disclosure, the method further comprises generating, by a processing unit, one or more new authentication key associated with the user based on a user input, wherein the one or more new authentication key is at least one of a new API key associated with the user, a new JWT key associated with the user, and a new oAuth key associated with the user.
[0015] In an exemplary aspect of the present disclosure, the method further comprises replacing, by the processing unit, one or more prestored authentication key from the set of prestored authentication keys in an event the one or more new authentication key is generated.
[0016] Another aspect of the present disclosure may relate to system for authenticating a user access based on one or more authentication keys. The system comprises a transceiver unit configured to receive from a user, an access request to access a service associated with a platform, wherein the access request comprises an authentication key. Further, the system comprises an analysis unit connected at least to the transceiver unit, wherein the analysis unit is configured to identify, a key type associated with the authentication key, wherein the key type is at least one of an Application Programming Interface (API) key, a JSON Web Tokens (JWT) key and an Open Authorization (oAuth) key. Further, the analysis unit is configured to validate, the authentication key based on the key type and a set of prestored authentication keys associated with the user, wherein the set of prestored authentication keys comprises one or more of a prestored API key associated with

the user, a prestored API key associated with the user, and a prestored oAuth key associated with the user. Furthermore, the analysis unit configured to determine, a validation status associated with the authentication key, wherein the validation status is at least one of a positive validation status and a negative validation status. Further, the system comprises a control unit connected to at least the analysis unit, wherein the control unit is configured to grant, to the user, the access to the service associated with the platform based on the positive validation status.
[0017] Another aspect of the present disclosure may relate to a user equipment (UE) for authenticating a user access based on one or more authentication keys, the UE comprises a memory. Further, a processor connected to the memory, wherein the processor is configured to transmit, to a system, an access request to access a service associated with a platform, wherein the access request comprises an authentication key. The processor is further configured to receive, from the system, at least one of a grant and a reject associated with the access request. Further, the at least one of the grant and the reject associated with the access request, is received based on identifying, by the system, a key type associated with the authentication key, wherein the key type is at least one of an Application Programming Interface (API) key, a JSON Web Tokens (JWT) key and an Open Authorization (oAuth) key. Further, the at least one of the grant and the reject associated with the access request, is received based on validating, by the system, the authentication key based on the key type and a set of prestored authentication keys associated with the user, wherein the of set of prestored authentication keys comprises one or more of a prestored API key associated with the user, a prestored JWT key associated with the user, and a prestored oAuth key associated with the user. Further, the at least one of the grant and the reject associated with the access request, is received based on determining, by the system, a validation status associated with the authentication key, wherein the validation status is at least one of a positive validation status and a negative validation status.

[0018] Yet another aspect of the present disclosure may relate to a non-transitory computer readable storage medium storing instructions for authenticating a user access based on one or more authentication keys, the instructions include executable code which, when executed by one or more units of a system, causes a transceiver unit of the system to receive from a user, an access request to access a service associated with a platform, wherein the access request comprises an authentication key. Further, the executable code when executed causes an analysis unit of the system to identify, a key type associated with the authentication key, wherein the key type is at least one of an Application Programming Interface (API) key, a JSON Web Tokens (JWT) key and an Open Authorization (oAuth) key. Further, the executable code when executed causes the analysis unit of the system to validate, the authentication key based on the key type and a set of prestored authentication keys associated with the user, wherein the set of prestored authentication keys comprises one or more of a prestored API key associated with the user, a prestored JWT key associated with the user, and a prestored oAuth key associated with the user. Further, the executable code when executed by causes the analysis unit of the system to determine, a validation status associated with the authentication key, wherein the validation status is at least one of a positive validation status and a negative validation status. Further, the executable code when executed causes a control unit of the system to grant, to the user, the access to the service associated with the platform based on the positive validation status.
OBJECTS OF THE DISCLOSURE
[0019] Some of the objects of the present disclosure, which at least one embodiment disclosed herein satisfies are listed herein below.
[0020] It is an object of the present disclosure to provide a system and a method for authenticating a user access based on one or more authentication keys to restrict malicious users from accessing unauthorized information.

[0021] It is another object of the present disclosure to provide a solution that facilitates key management for updating the one or more authentication keys, based on user requirements.
[0022] It is yet another object of the present disclosure to provide a solution that mitigates the risk of tampered or expired keys, in view of maintaining security against the malicious users.
DESCRIPTION OF THE DRAWINGS
[0023] The accompanying drawings, which are incorporated herein, and constitute a part of this disclosure, illustrate exemplary embodiments of the disclosed methods and systems in which like reference numerals refer to the same parts throughout the different drawings. Components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Also, the embodiments shown in the figures are not to be construed as limiting the disclosure, but the possible variants of the method and system according to the disclosure are illustrated herein to highlight the advantages of the disclosure. It will be appreciated by those skilled in the art that disclosure of such drawings includes disclosure of electrical components or circuitry commonly used to implement such components.
[0024] FIG. 1 illustrates an exemplary network architecture for authenticating a user access based on one or more authentication keys, in accordance with exemplary implementations of the present disclosure.
[0025] FIG. 2 illustrates an exemplary block diagram of a computing device upon which the features of the present disclosure may be implemented in accordance with exemplary implementation of the present disclosure.

[0026] FIG. 3 illustrates a block diagram of a system for authenticating a user access based on one or more authentication keys, in accordance with exemplary implementations of the present disclosure.
5 [0027] FIG. 4 illustrates a flow diagram of a method for authenticating a user
access based on one or more authentication keys in accordance with exemplary implementations of the present disclosure.
[0028] FIG. 5, illustrates an exemplary user interface (UI) [500] illustrating an
10 exemplary dashboard, in accordance with exemplary implementations of the
present disclosure.
[0029] FIG. 6, illustrates an exemplary user interface (UI) for generating
Application Programming Interface (API) credentials, in accordance with
15 exemplary implementations of the present disclosure.
[0030] The foregoing shall be more apparent from the following more detailed description of the disclosure.
20 DETAILED DESCRIPTION
[0031] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that
25 embodiments of the present disclosure may be practiced without these specific
details. Several features described hereafter may each be used independently of one another or with any combination of other features. An individual feature may not address any of the problems discussed above or might address only some of the problems discussed above.
30
9

[0032] The ensuing description provides exemplary embodiments only, and is not
intended to limit the scope, applicability, or configuration of the disclosure. Rather,
the ensuing description of the exemplary embodiments will provide those skilled in
the art with an enabling description for implementing an exemplary embodiment.
5 It should be understood that various changes may be made in the function and
arrangement of elements without departing from the spirit and scope of the disclosure as set forth.
[0033] Specific details are given in the following description to provide a thorough
10 understanding of the embodiments. However, it will be understood by one of
ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. 15
[0034] Also, it is noted that individual embodiments may be described as a process
which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure
diagram, or a block diagram. Although a flowchart may describe the operations as
a sequential process, many of the operations may be performed in parallel or
20 concurrently. In addition, the order of the operations may be re-arranged. A process
is terminated when its operations are completed but could have additional steps not included in a figure.
[0035] The word “exemplary” and/or “demonstrative” is used herein to mean
25 serving as an example, instance, or illustration. For the avoidance of doubt, the
subject matter disclosed herein is not limited by such examples. In addition, any
aspect or design described herein as “exemplary” and/or “demonstrative” is not
necessarily to be construed as preferred or advantageous over other aspects or
designs, nor is it meant to preclude equivalent exemplary structures and techniques
30 known to those of ordinary skill in the art. Furthermore, to the extent that the terms
“includes,” “has,” “contains,” and other similar words are used in either the detailed
10

description or the claims, such terms are intended to be inclusive—in a manner similar to the term “comprising” as an open transition word—without precluding any additional or other elements.
5 [0036] As used herein, a “processing unit” or “processor” or “operating processor”
includes one or more processors, wherein processor refers to any logic circuitry for processing instructions. A processor may be a general-purpose processor, a special purpose processor, a conventional processor, a digital signal processor, a plurality of microprocessors, one or more microprocessors in association with a Digital
10 Signal Processing (DSP) core, a controller, a microcontroller, Application Specific
Integrated Circuits, Field Programmable Gate Array circuits, any other type of integrated circuits, etc. The processor may perform signal coding data processing, input/output processing, and/or any other functionality that enables the working of the system according to the present disclosure. More specifically, the processor or
15 processing unit is a hardware processor.
[0037] As used herein, “a user equipment”, “a user device”, “a smart-user-device”, “a smart-device”, “an electronic device”, “a mobile device”, “a handheld device”, “a wireless communication device”, “a mobile communication device”, “a
20 communication device” may be any electrical, electronic and/or computing device
or equipment, capable of implementing the features of the present disclosure. The user equipment/device may include, but is not limited to, a mobile phone, smart phone, laptop, a general-purpose computer, desktop, personal digital assistant, tablet computer, wearable device or any other computing device which is capable
25 of implementing the features of the present disclosure. Also, the user device may
contain at least one input means configured to receive an input from unit(s) which are required to implement the features of the present disclosure.
[0038] As used herein, “storage unit” or “memory unit” refers to a machine or
30 computer-readable medium including any mechanism for storing information in a
form readable by a computer or similar machine. For example, a computer-readable
11

medium includes read-only memory (“ROM”), random access memory (“RAM”),
magnetic disk storage media, optical storage media, flash memory devices or other
types of machine-accessible storage media. The storage unit stores at least the data
that may be required by one or more units of the system to perform their respective
5 functions.
[0039] As used herein “interface” or “user interface refers to a shared boundary
across which two or more separate components of a system exchange information
or data. The interface may also be referred to a set of rules or protocols that define
10 communication or interaction of one or more modules or one or more units with
each other, which also includes the methods, functions, or procedures that may be called.
[0040] All modules, units, components used herein, unless explicitly excluded
15 herein, may be software modules or hardware processors, the processors being a
general-purpose processor, a special purpose processor, a conventional processor,
a digital signal processor (DSP), a plurality of microprocessors, one or more
microprocessors in association with a DSP core, a controller, a microcontroller,
Application Specific Integrated Circuits (ASIC), Field Programmable Gate Array
20 circuits (FPGA), any other type of integrated circuits, etc.
[0041] As used herein the transceiver unit include at least one receiver and at least
one transmitter configured respectively for receiving and transmitting data, signals,
information or a combination thereof between units/components within the system
25 and/or connected with the system.
[0042] As discussed in the background section, the current known solutions have
several shortcomings. The existing solutions are unable to handle the user traffic
when one or more microservice platforms are used at a larger level or when the one
30 or more microservice platforms are scaled up. Further, scaling of the one or more
microservice platforms leads to increased complexity and overhead of the
12

microservice platforms, as well as higher costs and fees for the usage and
maintenance of a service at the one or more microservice platforms. Furthermore,
if scaling out is not done properly, an Application Programming Interface (API)
Gateway associated with the one or more microservice platforms may become a
5 bottleneck as the scaling up of the one or more microservice platforms may lead to
chances of crashes on the one or more microservice platforms & may further deteriorate the user experience.
[0043] The present disclosure aims to overcome the above-mentioned and other
10 existing problems in this field of technology by providing a novel solution
authenticating a user access based on one or more authentication keys. The present
disclosure provides gateways, which adds an extra security layer. The API gateway
includes an API key that gets assigned when an external system(user) tries to access
the service platform. This API key is a unique key that allows the user to access the
15 platform without compromising the data of other users. Further, the API gateway
as per the present disclosure supports various authentication mechanisms such as,
but not limited to, API keys, a JSON Web Tokens (JWT), an Open Authorization
(OAuth) key, and custom authentication schemes, and further allows addition of
more API gateway instances in order to manage traffic increase, allowing
20 administrators to define access policies based on user roles, groups, or other
attributes.
[0044] Referring to FIG. 1, an exemplary system architecture [100] for authenticating a user access based on one or more authentication keys, in
25 accordance with exemplary implementations of the present disclosure is shown. In
an implementation the system architecture [100] may contain an Evolved Packet core (EPC) [102], a Fulfilment management system (FMS) [114], at least one subscription engine [104], at least one load balancer [106], one or more channels [108], one or more databases [110], and one or more interconnected units [112]
30 associated with the subscription engine [104].
13

[0045] The load balancer [106] manages the traffic from different channels, ensuring efficient distribution of requests to the subscription engine. It handles both HTTPS and WebSocket requests, directing them to appropriate instances within the engine. 5
[0046] As shown in FIG. 1, the EPC [102] and the FMS [114] are connected with
the subscription engine [104], via an Elastic Load Balancer (ELB). The subscription
engine [104] may further connect to a platform for providing one or more services
to the user. Further, the user may use a user equipment (UE) for connecting with
10 the subscription engine [104] for accessing the platform.
[0047] As used herein, the EPC [102] and the FMS [114], may be used for managing data connectivity and network functions, which may be required for connecting the UE with the subscription engine [104].
15
[0048] Further, the one or more channels [108] are further connected with the subscription engine [104] via the load balancer [106]. Further, the one or more channels [108] may include a Retail Point of Sale (RPOS), a Device Management Platform (DMP), a SELFCARE, and a Customer Relationship Management User
20 Interface (CRM UI). Further, the one or more channels [108] may use a Hyper Text
Transmission Protocol (HTTP) or Web Sockets (ws) for providing a secure communication between the one or more channels [108] and the load balancer [106].
25 [0049] Further, the subscription engine [104] may include one or more instances,
such as: a User Instance, a Configuration Instance, an Analytics Instance, an Integration Instance, a Subscriber Instance, a Batch-Processing Instance, a Private Service Connect (PSC) Instance, a User Subscription Instance, an Operations Administration and Management (OAM) Instance, an Admin Portal, and an Identity
30 and Access Management (IAM) Instance. Further, the one or more instances may
facilitate in management of one or more data related to users and subscribers and/or
14

may facilitate in the connection of the subscription engine [104] with at least one of the EPC [102], the FMS [114], the one or more channels [108], the one or more databases [110], and the one or more interconnected units [112].
5 [0050] Further, the one or more databases [110] may be utilized for storing one or
more information related to the one or more data related to the users and the subscribers, along with other critical information (such as configuration settings of the subscription engine [104], a set of prestored authentication keys).
10 [0051] Further, the one or more interconnected units [112] may include the FMS
[114] and facilitate interaction of the user with the subscription engine [104]. The one or more interconnected units [112] may further include a service management platform (SMP) and a Data Information Framework (DIF) that may interact with the subscription engine [104] via HTTP for User Authentication and management.
15
[0052] FIG. 2 illustrates an exemplary block diagram of a computing device [200] upon which the features of the present disclosure may be implemented in accordance with exemplary implementation of the present disclosure. In an implementation, the computing device [200] may also implement a method for
20 authenticating a user access based on one or more authentication keys utilising the
system. In another implementation, the computing device [200] itself implements the method for authenticating a user access based on one or more authentication keys using one or more units configured within the computing device [200], wherein said one or more units are capable of implementing the features as
25 disclosed in the present disclosure.
[0053] The computing device [200] may include a bus [202] or other
communication mechanism for communicating information, and a processor [204]
coupled with bus [202] for processing information. The processor [204] may be, for
30 example, a general-purpose microprocessor. The computing device [200] may also
include a main memory [206], such as a random-access memory (RAM), or other
15

dynamic storage device, coupled to the bus [202] for storing information and
instructions to be executed by the processor [204]. The main memory [206] also
may be used for storing temporary variables or other intermediate information
during execution of the instructions to be executed by the processor [204]. Such
5 instructions, when stored in non-transitory storage media accessible to the processor
[204], render the computing device [200] into a special-purpose machine that is
customized to perform the operations specified in the instructions. The computing
device [200] further includes a read only memory (ROM) [208] or other static
storage device coupled to the bus [202] for storing static information and
10 instructions for the processor [204].
[0054] A storage device [210], such as a magnetic disk, optical disk, or solid-state drive is provided and coupled to the bus [202] for storing information and instructions. The computing device [200] may be coupled via the bus [202] to a
15 display [212], such as a cathode ray tube (CRT), Liquid crystal Display (LCD),
Light Emitting Diode (LED) display, Organic LED (OLED) display, etc. for displaying information to a computer user. An input device [214], including alphanumeric and other keys, touch screen input means, etc. may be coupled to the bus [202] for communicating information and command selections to the processor
20 [204]. Another type of user input device may be a cursor controller [216], such as
a mouse, a trackball, or cursor direction keys, for communicating direction information and command selections to the processor [204], and for controlling cursor movement on the display [212]. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allow
25 the device to specify positions in a plane.
[0055] The computing device [200] may implement the techniques described
herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware
and/or program logic which in combination with the computing device [200] causes
30 or programs the computing device [200] to be a special-purpose machine.
According to one implementation, the techniques herein are performed by the
16

computing device [200] in response to the processor [204] executing one or more
sequences of one or more instructions contained in the main memory [206]. Such
instructions may be read into the main memory [206] from another storage medium,
such as the storage device [210]. Execution of the sequences of instructions
5 contained in the main memory [206] causes the processor [204] to perform the
process steps described herein. In alternative implementations of the present disclosure, hard-wired circuitry may be used in place of or in combination with software instructions.
10 [0056] The computing device [200] also may include a communication interface
[218] coupled to the bus [202]. The communication interface [218] provides a two-way data communication coupling to a network link [220] that is connected to a local network [222]. For example, the communication interface [218] may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or
15 a modem to provide a data communication connection to a corresponding type of
telephone line. As another example, the communication interface [218] may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, the communication interface [218] sends and receives electrical,
20 electromagnetic or optical signals that carry digital data streams representing
various types of information.
[0057] The computing device [200] can send messages and receive data, including program code, through the network(s), the network link [220] and the
25 communication interface [218]. In the Internet example, a server [230] might
transmit a requested code for an application program through the Internet [228], the ISP [226], the local network [222], the host [224] and the communication interface [218]. The received code may be executed by the processor [204] as it is received, and/or stored in the storage device [210], or other non-volatile storage for later
30 execution.
17

[0058] Referring to FIG. 3, a block diagram of a system [300] for authenticating a
user access based on one or more authentication keys, is shown, in accordance with
the exemplary implementations of the present disclosure. The system [300]
comprises at least one transceiver unit [302], at least one analysis unit [304], at least
5 one control unit [306], at least one processing unit [308], and one or more databases
[110]. Also, all of the components/ units of the system [300] are assumed to be connected to each other unless otherwise indicated below. As shown in the figures all units shown within the system [300] should also be assumed to be connected to each other. Also, in Figure 3 only a few units are shown, however, the system [300]
10 may comprise multiple such units or the system [300] may comprise any such
numbers of said units, as required to implement the features of the present disclosure. Further, in an implementation, the system [300] may be present in a user device/ user equipment to implement the features of the present disclosure. The system [300] may be a part of the user device /or may be independent of but in
15 communication with the user device (may also referred herein as a UE). In another
implementation, the system [300] may reside in a server or a network entity. In yet another implementation, the system [300] may reside partly in the server/ network entity and partly in the user device.
20 [0059] The system [300] is configured for authenticating a user access based on
one or more authentication keys, with the help of the interconnection between the components/units of the system [300].
[0060] Further, in accordance with the present disclosure, it is to be acknowledged
25 that the functionality described for the various the components/units can be
implemented interchangeably. While specific embodiments may disclose a
particular functionality of these units for clarity, it is recognized that various
configurations and combinations thereof are within the scope of the disclosure. The
functionality of specific units as disclosed in the disclosure should not be construed
30 as limiting the scope of the present disclosure. Consequently, alternative
arrangements and substitutions of units, provided they achieve the intended
18

functionality described herein, are considered to be encompassed within the scope of the present disclosure.
[0061] The system [300] comprises the transceiver unit [302] configured to receive
5 from a user, an access request to access a service associated with a platform,
wherein the access request comprises an authentication key.
[0062] In an implementation of the present disclosure, the access request received at the transceiver unit [302] may come from the user which may refer to at least one
10 of an end user, an administrator, a developer, and any other like user associated
with the platform that may be appreciated by a person skilled in the art in order to implement the present disclosure. Further, the user may directly send the access request or may send the access request to the platform via a third-party application. Further, the platform may incorporate one or more services and/or microservices
15 which may be accessed by the user. The one or more services and/or microservices
may include one of a user profile management microservice, content delivery microservice, customer support service microservice and similar microservices known in the state of art. Further, the platform may be a customer relationship management platform, a platform associated with internet of things (IoT) services,
20 an over the top (OTT) service, and any other such like platform that may be
appreciated by a person skilled in the art to be the platform in light of the present disclosure.
[0063] Further, the access request comprises the authentication key that
25 corresponds to a unique identifier associated with the user and that may be used in
the authentication of the access request.
[0064] The system [300] may further comprise the analysis unit [304] connected at
least to the transceiver unit [302]. Further, the analysis unit [304] is configured to
30 identify, a key type associated with the authentication key, wherein the key type is
at least one of an Application Programming Interface (API) key, a JSON Web
19

Tokens (JWT) key and an Open Authorization (oAuth) key. In an implementation of the present disclosure, the key type may be identified by the analysis unit [304] based on analyzing one or more attributes associated with the received authentication key. 5
[0065] In an exemplary scenario, at least one of the API key, the JWT key, and the
oAuth key can be used to access a similar platform, therefore there is a requirement
to firstly access the key type of the received authentication key. For example: in an
event, for accessing an ABC microservice, an access request comprising an
10 authentication key is sent to the said ABC microservice, wherein the key type
associated with authentication key may be a JWT key.
[0066] Further, each key type may have different attributes (such as different
configuration, different datatype, different formats), based on which the analysis
15 unit [304] may identify the key type associated with the authentication key.
[0067] As used herein the “API key” may correspond to a unique identifier that
may be received by the transceiver unit [302], for accessing at least one of the
aforementioned microservices. The API key may primarily include a string of
20 characters such as “abc123def456ghi789jkl” that may be associated with a specific
user, an application or an account associated with the platform.
[0068] As used herein the “JWT key” may correspond to a unique identifier that
may be used for a secure transmission of the access request from the user. The JWT
25 key may include a plurality of Java Script Object Notation (JSON) web tokens that
may associate with the user.
[0069] As used herein the “oAuth Key” may correspond to a unique identifier that
may comprise a set of oAuth tokens that allows the user to access the platform
30 and/or a microservice on the platform, without revealing one or more user
credentials.
20

[0070] For ease of understanding, let us consider a platform requiring user
credentials (such as a user ID and a User password). Further, for accessing the
platform, the user sends the access request comprising the OAuth Key, then in such
5 case, during the authentication of the access request, the OAuth Key may allow a
user to have access to limited microservices on the platform such as only to a content delivery microservice without revealing or storing any user IDs or passwords.
10 [0071] The analysis unit [304] is further configured to identify a target prestored
authentication key from the set of prestored authentication keys associated with the user based on the identified key type. Further, as used herein the “target prestored authentication key” allows a particular user to gain access to the service associated with the platform based on the received access request with the help of secret keys
15 that are stored in the one or more databases [110]. Further, in an implementation of
the present disclosure, the target prestored authentication key may be identified based on comparing the received authentication key associated with the access request with the set of prestored authentication keys associated with the particular user.
20
[0072] The analysis unit [304] may further be connected to the one or more databases [110], where the one or more databases [110] may comprise the set of prestored authentication keys that are associated with the user. Further, there may be a separate database associated with each of the one or more API keys associated
25 with the user, the one or more prestored JWT keys associated with the user, and the
one or more oAuth keys associated with the user. Furthermore, in an implementation of the present the set of prestored authentication keys that are associated with the user may be an authentication key that is generated by a particular user and/or assigned to the particular user based on a request i.e., a user
30 input and/or a signing up action of the particular user.
21

[0073] In an implementation of the present disclosure, the analysis unit [304] based
on the key type of the authentication key, may further identify the target prestored
authentication key (i.e., the API key, the JWT key, and the oAuth Key) from the set
of prestored authentication keys, which may be stored in the one or more databases
5 [110]. In an implementation of the present disclosure, the analysis unit [304] may
identify a target prestored JWT authentication key based on comparing the received authentication key with the set of prestored authentication keys, wherein the key type of the received authentication key is a JWT key.
10 [0074] The analysis unit [304] is further configured to validate, the authentication
key based on the key type and a set of prestored authentication keys associated with the user. Further, the set of prestored authentication keys comprises one or more of a prestored API keys associated with the user, a prestored JWT key associated with the user, and a prestored oAuth key associated with the user. Further, the validation
15 of the authentication key is performed via one or more gateways associated with
the platform.
[0075] Further, the one or more gateways associated with the platform may include at least one of an API Gateways, a unidirectional gateway, and a bidirectional
20 gateway, it should be noted that the above stated gateways are exemplary in nature
and should not be interpreted in any manner to restrict the scope of this disclosure. The one or more gateways may include any other necessary gateways associated with the platform that may be obvious to the person skilled in the art for implementing the solution as disclosed herein.
25
[0076] Further, in an exemplary implementation of the present disclosure, in a scenario if the key type is the API key, the authentication key is validated based on the API key and the prestored API key associated with the user. Further to validate the authentication key, a API key is extracted from an access request header of the
30 access request. Then, the prestored API key associated with the user from the one
or more databases [110] is retrieved. Thereafter, the prestored API key and the
22

extracted API key is verified to detect if each of the key is valid i.e., has not expired. Further, the extracted API key may be analyzed for applicable access permissions i.e., a right to access the requested service on the platform.
5 [0077] Further, in another exemplary implementation of the present disclosure, in
a scenario if the key type is the JWT key, the authentication key is validated based on the JWT key and the prestored JWT key associated with the user. Further to validate the authentication key, the JWT key is extracted from an access request header of the access request. Further, a signature from the extracted JWT key is
10 retrieved. Then, the prestored JWT key associated with the user from the one or
more databases [110] is retrieved. Thereafter, the signature of the extracted JWT key is verified based on the prestored JWT key to detect if the extracted JWT key is valid i.e., has not expired. Further, the extracted JWT key may be analyzed for applicable access permissions i.e., a right to access the requested service on the
15 platform.
[0078] Further, in another exemplary implementation of the present disclosure, in a scenario if the key type is the oAuth key, the authentication key is validated based on the oAuth key and the prestored oAuth key associated with the user. Further to
20 validate the authentication key, an oAuth key is extracted from an access request
header of the access request. Further, an access token from the extracted oAuth key is retrieved. Then, the prestored JWT key associated with the user from the one or more databases [110] is retrieved. Thereafter, the access token of the extracted oAuth key is verified based on matching the access token and a prestored access
25 token of the prestored oAuth key to detect if the extracted oAuth key is valid i.e.,
has not expired. Further, the extracted oAuth key may be analyzed for applicable access permissions i.e., a right to access the requested service on the platform.
[0079] The one or more gateways mentioned above may include one or more steps
30 or process to validate the authentication key. In an implementation of the present
23

disclosure, the authentication key is validated based on one or more predefined key validation rules associated with the target prestored authentication key.
[0080] The analysis unit [304] is further configured to determine, a validation status
5 associated with the authentication key, wherein the validation status is at least one
of a positive validation status and a negative validation status. Further, the positive
validation status is determined in an event, the authentication key is the successful
match with the target prestored authentication key. Conversely, the negative
validation status is determined in an event, the authentication key is the
10 unsuccessful match with the target prestored authentication key.
[0081] For example, if a received authentication key is ABC123 and a prestored
key is also ABC123 in that event the positive validation associated with the
authentication key is determined, whereas in an event if the received authentication
15 key is ABC123 and the prestored key is ABC234 in that event the negative
validation associated with the authentication key is determined.
[0082] Further, in an event, the target prestored authentication key is the API key, then the one or more gateways (such as the API getaway) may verify the identified
20 API key from one or more prestored API keys that are stored in the one or more
databases [110]. Further, based on verifying the identified API key with the one or more prestored API keys, the one or more gateways may generate the validation status associated with the authentication key. Further, the positive validation status refers to an event, if said identified API key is present within the one or more
25 databases [110] of the one or more prestored API keys. Further, the negative
validation status refers to an event, if said identified API key is not present within the one or more databases [110] of the one or more prestored API keys.
[0083] Further, in an event, the target prestored authentication key is the JWT key,
30 then the one or more gateways (such as the IAM gateway) may verify a signature
or claims (present in the form of JSON web tokens) from the access request and
24

based on the presence of the signature or claims, present on the one or more databases [110], then one or more gateways may generate the validation status for said JWT key.
5 [0084] Further, in an event, the target prestored authentication key is the oAuth key,
then the one or more gateways (such as the oAuth Authorization Gateway) may verify a validity (expiry) of the set of oAuth tokens present in the access request and based on the verification of the set of said oAuth tokens, the one or more gateways may further generate the validation status for said oAuth key. 10
[0085] The system may further comprise the control unit [306] connected to at least the analysis unit [304]. Further, the control unit [306] is configured to grant, to the user, the access to the service associated with the platform based on the positive validation status.
15
[0086] In an implementation of the present disclosure, the control unit [306] based of the positive validation status associated with the authentication key, may further grant, or reject the access of the service associated with the platform to the user. In an event, the one or more gateways may successfully verify the authentication key
20 present in the access request, then the control unit [306] may grant access to the
user, for accessing the service associated with the platform.
[0087] Furthermore, the control unit [306] is further configured to reject, the access
of the user to the service associated with the platform based on the negative
25 validation status.
[0088] Conversely in an event, the validation status associated with the
authentication key is the negative validation status for one or more reasons (such as
the authentication key may be expired, or may be tampered), then the control unit
30 [306] may reject the access to the user, for accessing the service associated with the
platform. The control unit [306] may further redirect the user to repeatedly allow
25

the user for sending a new access request to the platform and/or the control unit
[306] may further provide one or more information regarding the reason for
rejecting the access request (such as the authentication key may be expired or may
be tampered). The control unit [306] via the transceiver unit [302] may
5 communicate the one or more information to the user.
[0089] The system architecture [100] may further comprise the processing unit
[308] connected to at least the control unit [306]. Further, the processing unit [308]
is configured to generate, one or more new authentication key associated with the
10 user based on a user input, wherein the one or more new authentication keys is at
least one of a new API key associated with the user, a new JWT key associated with the user, and a new oAuth key associated with the user.
[0090] In an implementation of the present disclosure, the user may request for
15 generating the one or more new authentication keys, for one or more reasons. The
one or more reasons may include at least one of a security concerns (such as the if
the present key is either tampered or expired), a necessary routine process (such as
the present keys associated for the platforms may require generation of new
authentication keys after a regular interval such as every three months), an
20 operational concerns (in case, the platforms is incorporated with new updates, then
there might be requirement of generating a new authentication key for accessing the new updates in the platform).
[0091] Further, the new authentication key generated based on a desired key type
25 provided in the user input, wherein the desired key type is one of the API key, the
JWT key, and the oAuth key. Thereafter, based on the desired key type provided in the user input at least one of the new API key associated with the user, the new JWT key associated with the user, and the new oAuth key associated with the user is generated. 30
26

[0092] The processing unit [308] is further configured to replace one or more prestored authentication keys from the set of prestored authentication keys in an event the one or more new authentication keys is generated.
5 [0093] Further, post generation of new authentication key, the processing unit [308]
may identify one or more prestored authentication key (i.e., an old prestored
authentication key) from the set of prestored authentication keys, which is
associated with said user and may then replace the old one or more prestored
authentication key with the one or more new authentication key associated with said
10 user.
[0094] Further, the replacing the previous one or more prestored authentication key
from the set of prestored authentication keys by the one or more new authentication
key is required due to one or more conditions, where the one or more conditions
15 may include a compromised one or more old prestored authentication key, or the
user may have lost the one or more old prestored authentication key. It is to be noted that any other conditions can be implemented in the present disclosure that is known to a person skilled in the art.
20 [0095] Referring to FIG. 4, an exemplary method flow diagram [400] for
authenticating a user access based on one or more authentication keys, in accordance with exemplary implementations of the present disclosure is shown. In an implementation the method [400] is performed by the system [300]. Further, in an implementation, the system [300] may be present in a server device to implement
25 the features of the present disclosure. Also, as shown in Figure 4, the method [400]
starts at step [402] and proceeds to step [404].
[0096] At step [404], the method [400] comprises receiving, at a transceiver unit
[302] from a user, an access request to access a service associated with a platform,
30 wherein the access request comprises an authentication key.
27

[0097] The method [400] further explains that the access request received at the
transceiver unit [302] may come from the user which may refer to at least one of an
end user, an administrator, a developer, and any other operator associated with the
platform that may be obvious to a person skilled in the art. Further, the user may
5 directly send the access request or may send the access request to the platform via
a third-party application. Further, the platform may incorporate one or more
services and/or microservices which may be accessed by the user. The one or more
services and/or microservices mentioned herein may include one of a user profile
management microservice, content delivery service microservice, customer support
10 microservice and similar microservices known in the state of art. Further, the access
request comprises the authentication key that corresponds to a unique identifier associated with the user and that may be used in the authentication of the access request.
15 [0098] At step [406], the method [400] comprises identifying, by an analysis unit
[304], a key type associated with the authentication key, wherein the key type is at least one of an Application Programming Interface (API) key, a JSON Web Tokens (JWT) key and an Open Authorization (oAuth) key.
20 [0099] The method [400] further explains that the key type may be identified based
on analyzing one or more attributes associated with the received authentication key as each key type may have different attributes (such as different configuration, different datatype, different formats), based on which the analysis unit [304] may identify the key type associated with the authentication key.
25
[0100] In an exemplary scenario, at least one of the API key, the JWT key, and the oAuth key can be used to access a similar platform, therefore there is a requirement to firstly access the key type of the received authentication key. For example: in an event, for accessing an ABC microservice, an access request comprising an
30 authentication key is sent to the said ABC microservice, wherein the key type
associated with authentication key may be a JWT key.
28

[0101] Further, the API key may correspond to a unique identifier that may be
received by the transceiver unit [302], for accessing at least one of the
5 aforementioned microservices. The API key may primarily include a string of
characters such as “abc123def456ghi789jkl” that may be associated with a specific user, an application or an account associated with the platform.
[0102] Furthermore, the JWT key may correspond to a unique identifier that may
10 be used for a secure transmission of the access request from the user. The JWT key
may include a plurality of Java Script Object Notation (JSON) web tokens that may associate with the user.
[0103] Furthermore, the oAuth key may correspond to a unique identifier that may
15 comprise a set of oAuth tokens that allows the user to access the platform and/or a
microservice on the platform, without revealing one or more user credentials.
[0068] For ease of understanding, let us consider a platform requiring user
credentials (such as a user ID and a User password). Further, for accessing the
platform, the user sends the access request comprising the OAuth Key, then in such
20 case, during the authentication of the access request, the OAuth Key may allow a
user to have access to limited microservices on the platform such as only to a content delivery microservice without revealing or storing any user IDs or passwords.
25 [0104] The method [400] further comprises identifying, by the analysis unit [304],
a target prestored authentication key from the set of prestored authentication keys associated with the user based on the identified key type.
[0105] The method [400] further explains that the analysis unit [304] may further
30 be connected to the one or more databases [110], where the one or more databases
[110] may comprise the set of prestored authentication keys that are associated with
29

the user. Further, there may be a separate database associated with each of the one
or more API keys associated with the user, the one or more prestored JWT keys
associated with the user, and the one or more oAuth keys associated with the user.
Furthermore, in an implementation of the present the set of prestored authentication
5 keys that are associated with the user may be an authentication key that is generated
by a particular user and/or assigned to the particular user based on a request i.e., a user input and/or a signing up action of the particular user.
[0106] Further, the analysis unit [304] based on the key type of the authentication
10 key, may further identify the target prestored authentication key (i.e., the API key,
the JWT key, and the oAuth Key) from the set of prestored authentication keys, which may be stored in the one or more databases [110].
[0107] At step [408], the method [400] comprises validating, by the analysis unit
15 [304], the authentication key based on the key type and a set of prestored
authentication keys associated with the user, wherein the set of prestored
authentication keys comprises one or more of a prestored API keys associated with
the user, a prestored JWT key associated with the user, and a prestored oAuth key
associated with the user. Further, the validation of the authentication key is
20 performed via one or more gateways associated with the platform.
[0108] The method [400] further explains that the one or more gateways associated
with the platform may include at least one of an API Gateways, a unidirectional
gateway, and a bidirectional gateway, it should be noted that the above stated
25 gateways are exemplary in nature and should not be interpreted in any manner to
restrict the scope of this disclosure. The one or more gateways may include any other necessary gateways associated with the platform that may be obvious to the person skilled in the art for implementing the solution as disclosed herein.
30 [0109] Further, in an exemplary implementation of the present disclosure, in a
scenario if the key type is the API key, the authentication key is validated based on
30

the API key and the prestored API key associated with the user. Further to validate
the authentication key, an API key is extracted from an access request header of the
access request. Then, the prestored API key associated with the user from the one
or more databases [110] is retrieved. Thereafter, the prestored API key and the
5 extracted API key is verified to detect if each of the key is valid i.e., has not expired.
Further, the extracted API key may be analyzed for applicable access permissions i.e., a right to access the requested service on the platform.
[0110] Further, in another exemplary implementation of the present disclosure, in
10 a scenario if the key type is the JWT key, the authentication key is validated based
on the JWT key and the prestored JWT key associated with the user. Further to validate the authentication key, the JWT key is extracted from an access request header of the access request. Further, a signature from the extracted JWT key is retrieved. Then, the prestored JWT key associated with the user from the one or
15 more databases [110] is retrieved. Thereafter, the signature of the extracted JWT
key is verified based on the prestored JWT key to detect if the extracted JWT key is valid i.e., has not expired. Further, the extracted JWT key may be analyzed for applicable access permissions i.e., a right to access the requested service on the platform.
20
[0111] Further, in another exemplary implementation of the present disclosure, in a scenario if the key type is the oAuth key, the authentication key is validated based on the oAuth key and the prestored oAuth key associated with the user. Further to validate the authentication key, an oAuth key is extracted from an access request
25 header of the access request. Further, an access token from the extracted oAuth key
is retrieved. Then, the prestored JWT key associated with the user from the one or more databases [110] is retrieved. Thereafter, the access token of the extracted oAuth key is verified based on matching the access token and a prestored access token of the prestored oAuth key to detect if the extracted oAuth key is valid i.e.,
30 has not expired. Further, the extracted oAuth key may be analyzed for applicable
access permissions i.e., a right to access the requested service on the platform.
31

[0112] Further, the one or more gateways mentioned above may include one or
more steps or process to validate the authentication key. In an implementation of
the present disclosure, the authentication key is validated based on one or more
5 predefined key validation rules associated with the target prestored authentication
key.
[0113] At step [410], the method [400] comprises determining, by the analysis unit [304], a validation status associated with the authentication key, wherein the
10 validation status is at least one of a positive validation status and a negative
validation status. Further, the positive validation status is determined in an event, the authentication key is a successful match with the target prestored authentication key. Furthermore, the negative validation status is determined in an event, the authentication key is an unsuccessful match with the target prestored authentication
15 key.
[0114] The method [400] further explains that in an event, the target prestored authentication key is the API key, then the one or more gateways (such as the API getaway) may verify the identified API key from one or more prestored API keys
20 that are stored in the one or more databases [110]. Further, based on verifying the
identified API key with the one or more prestored API keys, the one or more gateways may generate the validation status associated with the authentication key. Further, the positive validation status refers to an event, if said identified API key is present within the one or more databases [110] of the one or more prestored API
25 keys. Further, the negative validation status refers to an event, if said identified API
key is not present within the one or more databases [110] of the one or more prestored API keys.
[0115] Further, in an event, the target prestored authentication key is the JWT key,
30 then the one or more gateways (such as the IAM gateway) may verify a signature
or claims (present in the form of JSON web tokens) from the access request and
32

based on the presence of the signature or claims, present on the one or more databases [110], then one or more gateways may generate the validation status for said JWT key.
5 [0116] Further, in an event, the target prestored authentication key is the oAuth key,
then the one or more gateways (such as the oAuth Authorization Gateway) may verify a validity (expiry) of the set of oAuth tokens present in the access request and based on the verification of the set of said oAuth tokens, the one or more gateways may further generate the validation status for said oAuth key. 10
[0117] At step [412], the method [400] comprises granting, by a control unit [306] to the user, the access to the service associated with the platform based on the positive validation status.
15 [0118] The method [400] further explains that the control unit [306] based of the
positive validation status associated with the authentication key, may further grant, or reject the access of the service associated with the platform to the user. In an event, the one or more gateways may successfully verify the authentication key present in the access request, then the control unit [306] may grant access to the
20 user, for accessing the service associated with the platform.
[0119] Further, the method [400] comprises rejecting, by the control unit [306] the user, the access to the service associated with the platform based on the negative validation status.
25
[0120] The method [400] further explains that, in an event, the validation status associated with the authentication key is the negative validation status for one or more reasons (such as the authentication key may be expired, or may be tampered), then the control unit [306] may reject the access to the user, for accessing the service
30 associated with the platform. The control unit [306] may further redirect the user to
repeatedly allow the user for sending a new access request to the platform and/or
33

the control unit [306] may further provide one or more information regarding the reason for rejecting the access request (such as the authentication key may be expired or may be tampered). The control unit [306] via the transceiver unit [302] may communicate the one or more information to the user. 5
[0121] The method [400] further comprises generating, by a processing unit [308],
one or more new authentication key associated with the user based on a user input,
wherein the one or more new authentication keys is at least one of a new API key
associated with the user, a new JWT key associated with the user, and a new oAuth
10 key associated with the user.
[0122] The method [400] further explains that the user may request for generating the one or more new authentication key, for one or more reasons. The one or more reasons may include at least one of a security concerns (such as the if the present
15 key is either tampered or expired), a necessary routine process (such as the present
keys associated for the platforms may require generation of new authentication keys after a regular interval such as every three months), an operational concerns (in case, the platforms is incorporated with new updates, then there might be requirement of generating a new authentication key for accessing the new updates
20 in the platform).
[0123] Further, the new authentication key generated based on a desired key type
provided in the user input, wherein the desired key type is one of the API key, the
JWT key, and the oAuth key. Thereafter, based on the desired key type provided in
25 the user input at least one of the new API key associated with the user, the new JWT
key associated with the user, and the new oAuth key associated with the user is generated.
[0124] The method [400] further comprises replacing, by the processing unit [308],
30 one or more prestored authentication keys from the set of prestored authentication
keys in an event the one or more new authentication keys is generated.
34

[0125] The method [400] further discloses that post generation of new
authentication key, the processing unit [308] may identify one or more prestored
authentication key (i.e., an old prestored authentication key) from the set of
5 prestored authentication keys, which is associated with said user and may then
replace the old one or more prestored authentication key with the one or more new authentication key associated with said user.
[0126] Further, the replacing the previous one or more prestored authentication key
10 from the set of prestored authentication keys by the one or more new authentication
key is required due to one or more conditions, where the one or more conditions
may include a compromised one or more old prestored authentication key, or the
user may have lost the one or more old prestored authentication key. It is to be noted
that any other conditions can be implemented in the present disclosure that is known
15 to a person skilled in the art.
[0127] The method [400] further terminates at step [414].
[0128] Referring to FIG. 5, an exemplary user interface (UI) [500] illustrating an
20 exemplary dashboard, in accordance with exemplary implementations of the
present disclosure. As depicted in FIG. 5 the exemplary dashboard may present a
set of options to the user of the UI [500]. Further, the set of options may be one of
a analytics option, a configuration option, an integration option, a customer profile
option (i.e., depicted as the customers), and any such other like options that may be
25 configured by an administrator/an operator of the platform to be associated with
said user. It is to be noted that the user interface (UI) [500] and the dashboard are exemplary in nature and should not be interpreted in a manner to limit the scope of the invention.
30 [0129] Referring to FIG. 6, an exemplary user interface (UI) [600] for generating
Application Programming Interface (API) credentials, in accordance with
35

exemplary implementations of the present disclosure. As depicted in FIG. 6 the
exemplary dashboard may present a set of options to the user of the UI [600],
wherein the set of options may be one of associated with an API access, such as a
API key, an expiry date of the API key, an authorization associated with the API
5 key, (i.e., depicted as the basic authorization), an API key help option, and any such
other like options that may be configured by an administrator/an operator of the platform to be associated with said user. It is to be noted that the user interface (UI) [600] and the dashboard are exemplary in nature and should not be interpreted in a manner to limit the scope of the invention.
10
[0130] The present disclosure discloses a User equipment (UE)for authenticating a user access based on one or more authentication keys, the UE comprises a memory. Further, a processor connected to the memory, wherein the processor is configured to transmit, to a system [300], an access request to access a service associated with
15 a platform, wherein the access request comprises an authentication key. The
processor is further configured to receive, from the system [300], at least one of a grant and a reject associated with the access request. Further, the at least one of the grant and the reject associated with the access request, is received based on identifying, by the system [300], a key type associated with the authentication key,
20 wherein the key type is at least one of an Application Programming Interface (API)
key, a JSON Web Tokens (JWT) key and an Open Authorization (oAuth) key. Further, the at least one of the grant and the reject associated with the access request, is received based on validating, by the system [300], the authentication key based on the key type and a set of prestored authentication keys associated with the user,
25 wherein the set of prestored authentication keys comprises one or more of a
prestored API key associated with the user, a prestored JWT key associated with the user, and a prestored oAuth key associated with the user. Further, the at least one of the grant and the reject associated with the access request, is received based on determining, by the system [300], a validation status associated with the
30 authentication key, wherein the validation status is at least one of a positive
validation status and a negative validation status.
36

[0131] The present disclosure further discloses a non-transitory computer readable storage medium storing instructions for authenticating a user access based on one or more authentication keys, the instructions include executable code which, when executed by one or more units of a system, causes a transceiver unit [302] of the system [300] to receive from a user, an access request to access a service associated with a platform, wherein the access request comprises an authentication key. Further, the executable code when executed causes an analysis unit [304] of the system [300] to identify, a key type associated with the authentication key, wherein the key type is at least one of an Application Programming Interface (API) key, a JSON Web Tokens (JWT) key and an Open Authorization (oAuth) key. Further, the executable code when executed causes the analysis unit [304] of the system [300] to validate, validate, the authentication key based on the key type and a set of prestored authentication keys associated with the user, wherein the set of prestored authentication keys comprises one or more of a prestored API key associated with the user, a prestored JWT key associated with the user, and a prestored oAuth key associated with the user. Further, the executable code when executed causes the analysis unit [304] of the system [300] to determine, a validation status associated with the authentication key, wherein the validation status is at least one of a positive validation status and a negative validation status. Further, the executable code when executed causes a control unit [306] of the system [300] to grant, to the user, the access to the service associated with the platform based on the positive validation status.
[0132] As is evident from the above, the present disclosure provides a technically advanced solution for authenticating a user access based on one or more authentication keys. The present solution restricts malicious users from accessing unauthorized information, and further provides optimal and efficient handling of the traffic when such systems are used at a larger level or when the systems are scaled up. Further, present solution reduces the cost and fees associated with the

usage and maintenance of the service platform, along with reducing the chances of crashing within the service platform. Further, the present solution may provide enhanced user experience, along with providing effective overall security of the service platform.
[0133] While considerable emphasis has been placed herein on the disclosed implementations, it will be appreciated that many implementations can be made and that many changes can be made to the implementations without departing from the principles of the present disclosure. These and other changes in the implementations of the present disclosure will be apparent to those skilled in the art, whereby it is to be understood that the foregoing descriptive matter to be implemented is illustrative and non-limiting.

We Claim:
1. A method for authenticating a user access based on one or more
authentication keys, the method comprising:
- receiving, at a transceiver unit [302] from a user, an access request to access a service associated with a platform, wherein the access request comprises an authentication key;
- identifying, by an analysis unit [304], a key type associated with the authentication key, wherein the key type is at least one of an Application Programming Interface (API) key, a JSON Web Tokens (JWT) key and an Open Authorization (oAuth) key;
- validating, by the analysis unit [304], the authentication key based on the key type and a set of prestored authentication keys associated with the user, wherein the set of prestored authentication keys comprises one or more of a prestored API key associated with the user, a prestored JWT key associated with the user, and a prestored oAuth key associated with the user;
- determining, by the analysis unit [304], a validation status associated with the authentication key, wherein the validation status is at least one of a positive validation status and a negative validation status; and
- granting, by a control unit [306] to the user, the access to the service associated with the platform based on the positive validation status.

2. The method as claimed in claim 1, wherein the validation of the authentication key is performed via one or more gateways associated with the platform.
3. The method as claimed in claim 1, wherein the method further comprises identifying, by the analysis unit [304], a target prestored authentication key from the set of prestored authentication keys associated with the user based on the identified key type.

4. The method as claimed in claim 3, wherein the positive validation status is determined in an event, the authentication key is a successful match with the target prestored authentication key.
5. The method as claimed in claim 3, wherein the negative validation status is determined in an event, the authentication key is an unsuccessful match with the target prestored authentication key.
6. The method as claimed in claim 1, wherein the method further comprises rejecting, by the control unit [306] to the user, the access to the service associated with the platform based on the negative validation status.
7. The method as claimed in claim 1, the method further comprises generating, by a processing unit [308], one or more new authentication key associated with the user based on a user input, wherein the one or more new authentication key is at least one of a new API key associated with the user, a new JWT key associated with the user, and a new oAuth key associated with the user.
8. The method as claimed in claim 7, the method further comprises replacing, by the processing unit [308], one or more prestored authentication key from the set of prestored authentication keys in an event the one or more new authentication key is generated.
9. A system for authenticating a user access based on one or more authentication keys, the system comprises:
- a transceiver unit [302] configured to receive from a user, an access request to access a service associated with a platform, wherein the access request comprises an authentication key;

- an analysis unit [304] connected at least to the transceiver unit [302],
wherein the analysis unit [304] is configured to:
o identify, a key type associated with the authentication key, wherein the key type is at least one of an Application Programming Interface (API) key, a JSON Web Tokens (JWT) key and an Open Authorization (oAuth) key,
o validate, the authentication key based on the key type and a set of prestored authentication keys associated with the user, wherein the set of prestored authentication keys comprises one or more of a prestored API key associated with the user, a prestored API key associated with the user, and a prestored oAuth key associated with the user, and
o determine, a validation status associated with the authentication key, wherein the validation status is at least one of a positive validation status and a negative validation status; and
- a control unit [306] connected to at least the analysis unit [304], wherein
the control unit [306] is configured to grant, to the user, the access to the
service associated with the platform based on the positive validation
status.
10. The system as claimed in claim 9, wherein the validation of the authentication key is performed via one or more gateways associated with the platform.
11. The system as claimed in claim 9, wherein the analysis unit [304] is further configured to identify, a target prestored authentication key from the set of prestored authentication keys associated with the user based on the identified key type.

12. The system as claimed in claim 11, wherein the positive validation status is determined in an event, the authentication key is a successful match with the target prestored authentication key.
13. The system as claimed in claim 11, wherein the negative validation status is determined in an event, the authentication key is an unsuccessful match with the target prestored authentication key.
14. The system as claimed in claim 9, wherein the control unit [306] is further configured to reject, the access of the user to the service associated with the platform based on the negative validation status.
15. The system as claimed in claim 9, wherein the system further comprises a processing unit [308] connected to at least the control unit [306], wherein the processing unit [308] is configured to generate, one or more new authentication key associated with the user based on an user input, wherein the one or more new authentication key is at least one of a new API key associated with the user, a new JWT key associated with the user, and a new oAuth key associated with the user.
16. The system as claimed in claim 15, wherein the processing unit [308] further configured to replace, one or more prestored authentication key from the set of prestored authentication keys in an event the one or more new authentication key is generated.
17. A user equipment (UE) for authenticating a user access based on one or more authentication keys, the UE comprising:

- a memory; and
- a processor connected to the memory, wherein the processor is configured to:

o transmit, to a system, an access request to access a service
associated with a platform, wherein the access request comprises
an authentication key, o receive, from the system, at least one of a grant and a reject
associated with the access request,
wherein the at least one of the grant and the reject associated with the access request, is received based on:
identifying, by the system, a key type associated with the authentication key, wherein the key type is at least one of an Application Programming Interface (API) key, a JSON Web Tokens (JWT) key and an Open Authorization (oAuth) key,
validating, by the system, the authentication key based on the key type and a set of prestored authentication keys associated with a user, wherein the set of prestored authentication keys comprises one or more of a prestored API key associated with the user, a prestored JWT key associated with the user, and a prestored oAuth key associated with the user, and
determining, by the system, a validation status associated with the authentication key, wherein the validation status is at least one of a positive validation status and a negative validation status.