CN103685204A - Resource authentication method based on internet of things resource sharing platform - Google Patents
Resource authentication method based on internet of things resource sharing platform Download PDFInfo
- Publication number
- CN103685204A CN103685204A CN201210359234.6A CN201210359234A CN103685204A CN 103685204 A CN103685204 A CN 103685204A CN 201210359234 A CN201210359234 A CN 201210359234A CN 103685204 A CN103685204 A CN 103685204A
- Authority
- CN
- China
- Prior art keywords
- client
- resource
- access token
- platform
- user
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Information Transfer Between Computers (AREA)
Abstract
The invention discloses a resource authentication method based on an internet of things resource sharing platform. The method comprises the following steps: step one: a client terminal sends a sensor resource request, and if the client terminal stores an access token which is successfully applied to a user, the access token and the sensor resource request are sent to a resource provider together; and step two: the resource provider is communicated with the platform synchronously, if the client terminal provides the access toke, the resource provider inspects effectiveness of the access token via a local trust list, and if the access token is effective, the client terminal is considered to also store a client authorization certificate surely in the trust list of the platform, and the resource provider transmits resources to the client terminal if the client authorization certificate is effective. According to the method, access pressure on a sharing platform server caused by large amount of resource access token requests is alleviated so that access process is optimized, access efficiency is enhanced and system security is enhanced.
Description
Technical field
The present invention relates to Internet of Things field, especially relate to a kind of resource method for authenticating based on Internet of Things resource sharing platform.
Background technology
Internet of Things is by information sensing equipment, according to the agreement of agreement, realizes person to person, people and thing and thing and thing interconnected network comprehensively.The principal character of Internet of Things is the various information of physical world of obtaining by radio-frequency (RF) identification, sensor mode, in conjunction with networks such as the Internet, mobile radio communications, the transmission of the information of carrying out, with mutual, adopts intelligent computation machine technology to carry out analyzing and processing to information, realizes intelligentized decision-making and control.
Internet of Things resource sharing platform is to take Data-collection middleware as basis, converges the sensor resource from every profession and trade, integrate information and service, and propagate by the Internet, set up brand-new Mashup service, create new value.Resource-sharing be unable to do without security mechanism, sets up a set of efficient security mechanism, is the important leverage that promotes Internet of Things development.
Current more ripe Mashup(refers to the data integration application program based on web) security mechanism adopted authentication and authorization agreement to evade Key Exposure, the hidden danger such as malicious code attack.OpenID(Open Identity, refers to the digital identity identification framework of a customer-centric) and OAuth(Open Authentication) be the Web2.0 security protocol of two kinds of main flows.OpenID agreement is the safety authentication protocol that can share accounts information, but is easily subject to phishing attacks, and malicious websites pretends to be OpenID provider to gain user key by cheating.For fear of this potential safety hazard, need to take corrective measure.The advantage of OpenID agreement is place registration, current everywhere.In concrete application, this advantage also has the restriction of himself: i.e. and the user of any registration OpenID account, needn't pass through resource provider mandate, just addressable its resource.Yet OAuth agreement has made up the deficiency of OpenID, but also there is the problem of self, that is: the poor efficiency that token request is brought frequently; Resource access authority is uncontrollable etc.Popular trend is to merge an OpenID and OAuth agreement advantage separately, sets up the security system model of a set of mixing.This model has carried out separated to authentication key and resource authorization key, tentatively realized the differentiated control of resource access authority.But in this system, for the resource of needs mandate, its application process is comparatively complicated, and the unauthorized access risk of resource still exists.
Summary of the invention
The technical problem to be solved in the present invention is to provide a kind of resource method for authenticating based on Internet of Things resource sharing platform, the access pressure that its resource access token request that can alleviate magnanimity causes shared platform server, optimized browsing process, improve access efficiency, improved security of system.
For solving the problems of the technologies described above, the invention provides a kind of resource method for authenticating based on Internet of Things resource sharing platform, wherein, Internet of Things resource sharing platform comprises: client, resource provider and platform, and client, described resource provider and platform comprise respectively trust list; This resource method for authenticating comprises:
Step 1: client sends sensor resource request, if this client has the access token of successfully applying for to user, sends to resource provider by this access token and sensor resource request in the lump;
Step 2: resource provider and platform carry out synchronous communication, with authentication-access token validity and user identity validity; If this client provides this access token, this resource provider checks the validity of described access token by local trust list, if access token is effective, think that described client also necessarily stored client authorization voucher in the trust table of platform, and client authorization voucher is effective, resource provider is to client transmissions resource.
Preferably, in this step 2, if although exist access token expired without this access token or this access token in the trust table of resource provider, carry out following steps:
Step 3: resource provider is redirected to described client;
Step 4: this client is to described platform request authorized certificate, described platform is by the client authorization voucher of client described in trust table look-up, if there is client authorization voucher and effective, go to step seven, described platform sends authorized certificate to described client; Otherwise go to step five;
Step 5: this platform is redirected to user;
Step 6: user sends user key to described platform, for the legitimacy of authentication of users;
Step 7: platform sends described authorized certificate to described client, wherein, if the success of described platform validation client's credit, this platform sends authorized certificate to described client, and described client authorization voucher is stored in the trust list of this platform simultaneously;
Step 8: described client relies on described authorized certificate to access token described in described resource provider request;
Step 9: described resource provider sends described access token to described client, wherein, described resource provider is verified this authorized certificate, if be proved to be successful, to this client, send described access token, described client is utilized described access token request resource; Otherwise described resource provider is refused this access token request of described client;
Step 10: described resource provider is to described client transmissions resource, wherein, described resource provider authentication-access token, if described access token is effective, send described sensor resource, described token information is stored in the trust list of described resource provider simultaneously.
Preferably, described step 1 also comprises: OpenID user's registration step and OpenID user's login step, wherein,
In OpenID user's registration step, user is to one section of additional ciphertext of OP input or picture, for verify OpenID server in login process;
In OpenID user's login step, first user sends OpenID to described OpenID server, this OpenID server is searched corresponding described ciphertext according to OpenID, and this ciphertext is sent it back to described user, this user checks this ciphertext, if this ciphertext is mated with the ciphertext in when registration, input password.
Compared with prior art, the present invention has the following advantages:
Feature for sensor resource request: the i.e. frequency of single resource request and persistence, the embodiment of the present invention is introduced and is trusted table mechanism on the basis of OpenID and OAuth hybrid authentication, optimized the exchange step of client and resource provider, also optimize resource access flow process, improved access efficiency; By reducing the communication steps with platform, alleviated the access pressure that the access token request of magnanimity causes platform; Access token and resource pairing strategy in trust table, have been adopted, a token is only effective to single resource, the clear and definite access rights of access token, this is a kind of improvement to original OAuth agreement unauthorized access risk, evade the uncontrollable potential safety hazard of OAuth resource access authority, improved security of system.
Other features and advantages of the present invention will be set forth in the following description, and partly from specification, become apparent, or understand by implementing the present invention.Object of the present invention and other advantages can be realized and be obtained by specifically noted structure in claims, specification and accompanying drawing thereof.
Accompanying drawing explanation
Fig. 1 is the schematic diagram of the security system mechanism of resource sharing platform;
Fig. 2 is client without under token conditions and have under token conditions four needed latency delays schematic diagrames of resource node application resource;
Fig. 3 is resource access schematic flow sheet;
Fig. 4 is the resource method for authenticating flow chart based on Internet of Things resource sharing platform of schematic a kind of execution mode.
Embodiment
Below in conjunction with concrete drawings and Examples, the present invention is described in detail.
embodiment of the method
The embodiment of the present invention has been introduced trust table mechanism on the basis of OpenID agreement and the fusion of OAuth agreement.Fig. 1 is the Security Architecture figure of resource sharing platform (platform).In Fig. 1, simulated ServiceA(as client) to ServiceB(as resource provider) sensor resource request process.Wherein, relevant English implication is as follows:
TrustList: trust table;
Requestresource: request resource;
Sensor resource requestor in OAuth Consumer:OAuth agreement, i.e. client;
Sensor resource provider in OAuth Provider:OAuth agreement;
RP(Relying Party): supporting the web website of OpenID agreement, is here the registered user of platform;
Platform: platform, i.e. Internet of Things resource sharing platform described in the embodiment of the present invention;
Login Server: the registration of platform and login service module
OpenID Authentication:OpenID radius authentication server (being included in Login Server)
Service Management: sensor resource service management module;
OAuth Authentication:OAuth radius authentication server (being included in Service Management)
ServiceA, ServiceB: the registered user of platform, they can upload the sensor resource of oneself, also can apply for mutually sensor resource, Service A and Service B both can be used as the client of OAuth agreement, can be used as again sensor resource provider.
In resource sharing platform Security Architecture, OpenID supplier role and OAuth authorization service person role are incorporated into and in a station server, carry out unified management.In platform (platform) and each resource provider, be respectively equipped with Trusty List(trust list).The client-side information that authentication storage is crossed in the Trusty List of platform OAuth radius authentication server (client authorization voucher).The customer information that in the Trusty List of resource provider, storage has been authorized.In resource request process, resource provider is synchronizeed with platform authorization server (being OpenID radius authentication server and OAuth radius authentication server), with the legitimacy of authentication of users information.Simultaneously in the Trusty of resource provider List by the resource URI(URL(uniform resource locator) of client certificate information and client-requested) match, define the access rights of access token.If the URI resource that client-requested is identical, and the authentication information providing would not mate with the authentication information of URI pairing with TrustyList, rejects response.
The security mechanism of resource sharing platform is mainly divided into sensor resource request flow process three parts of OpenID user's registration, OpenID user's login and third party's client.OpenID agreement is the safety authentication protocol that can share accounts information, but is easily subject to phishing attacks, and malicious websites pretends to be OpenID provider to gain user key by cheating.For fear of this potential safety hazard, need to take corrective measure.
What Fig. 4 showed is resource access flow chart.Wherein, relevant English being described as follows:
Access request: client sends resource request;
Sychronize: resource provider and platform carry out synchronous communication;
Redirect over to client: resource provider is redirected to client;
Request authorization: client is to platform request authorized certificate;
Redirect over to user: platform is redirected to user;
Credential authenticate: user sends user key (OpenID/ password) to platform;
Send authorization token: platform sends authorized certificate to client;
Request access token with authorization token: client relies on authorized certificate to resource provider request access token;
Exchange for access token: resource provider sends token to client;
Exchange resources: resource provider is to client transmissions resource.
Progressively be described in detail below:
Step S1:OpenID user's registration and login:
Step S1.1:OpenID user's registration: in registration process, user is to OP(OpenID Provider) one section of additional ciphertext of input or picture, for example (" DannyAuthentication "), for verifying OpenID server in login process; , wherein OP represents the supplier of OpenID, is also OpenID server (OpenID certification authority server);
Step S1.2:OpenID user's login: in login process, first user sends OpenID to OpenID server, and server is searched corresponding ciphertext according to OpenID, and ciphertext is sent it back to user, user checks cipher-text information, if mated with the ciphertext in when registration, inputs password;
Step S2. sensor resource request flow process:
Step S2.1: client is to resource provider request sensor resource, if the access token (access token) that client is successfully applied for to user before having sends to resource provider by access token and resource request in the lump;
Step S2.2: resource provider and platform carry out synchronous communication, with authentication-access token validity and user identity validity, in addition, also can be in order to the relevant information of a data trade behavior to be provided to platform;
Wherein, user identity validity is verified by authorized certificate.The relevant information of above-mentioned data trade behavior comprises data ID, validity date and the information such as pay the fees, and these information need arrange according to user's function.
If client provides access token, resource provider checks the validity of access token by its trust list (trusty list), if access token is effective, think that client also necessarily stored client authorization voucher in the trust table of platform, and client authorization voucher is effective, and resource provider sends sensor resource to client.
Although if exist but find that this access token is expired life cycle by inspection access token without this access token or access token in the trust table of resource provider, resource provider is redirected to client.
In this step, why consider that the checking of user identity validity considers based on following reason: if the access token life cycle of application is by the end of the first date before client, and the deadline of subscriber authorisation voucher in platform trust list was the second date, the first date is early than the second date, but user had nullified before the first date for a certain reason, so, in platform, can there be again user related information, and token also should be invalid accordingly, at this moment embody the necessity of two step cards, be that resource provider is held this access token and platform is verified, find that user is illegal, access token is also invalid.
Step S2.3: client is to platform request authorized certificate, and platform checks the client authorization voucher of client by trust list, if there is client authorization voucher and effective in the trust list of platform, goes to step 2.6, and platform sends authorized certificate to client; Otherwise continue step 2.4;
Step S2.4: platform is redirected to user;
Step S2.5: user sends user's secret key (OpenID/ password) to platform, for the legitimacy of authentication of users; Whether the object of checking client credit is to detect client to have the right to resource provider application sensor resource; Testing process is: in the local trust table of detection of platform, whether have the client credit vouchers relevant to client-side information (OpenID); Detection means is whether detect client be whether first application resource or client's credit vouchers of giving while applying for be before this expired; If user is illegal, refuse user's resource request; If user is legal, continue next step;
Step S2.6: platform validation user's legitimacy; If platform validation success, platform sends authorized certificate to client, and client authorization voucher is stored in the trust list of platform simultaneously; If platform validation failure, refuses user's sensor resource request;
Step S2.7: client sends access token request with authorized certificate to resource provider, wherein in the information of access token request with authorized certificate;
Step S2.8: resource provider checking authorized certificate, if be proved to be successful, to client, send access token, client utilizes access token to resource provider request resource; Otherwise the access token request of resource provider refusal client;
Step S2.9: resource provider authentication-access token
If access token is effective, resource provider sends sensor resource to client, access token is stored in the trust list of resource provider simultaneously;
If access token is invalid, resource provider refusal sensor resource request.
Table 1 is authorization identifying platform trust list, as follows:
| Client（ID） | credentials | lifetime |
| Client1 | credential_c1 | 24h |
Relevant English being explained as follows in table 1:
Client(ID): client id, i.e. OpenID;
Credentials: client's credit vouchers;
Lifetime: the life cycle of client's credit vouchers.
Table 2 is resource provider trust list, as follows:
Relevant English being explained as follows in table 2:
Authenticated client: granted the Customer ID of token, i.e. (client OpenID);
Credentials: client token/URI(related resource indications);
Lifetime: token life cycle.
When asking for the first time, client need to carry out the entire flow from step 2.1 to step 2.10, and directly show access token while accessing next time, thereby realized the interactive step that has also reduced client and platform when having saved exchange step, slowed down the access pressure of platform.
systematic function
System has increased resource access token life cycle and has been kept at client and resource provider this locality, refer to that client has certain useful life to the token of resource provider application the life cycle of resource access token, useful life is stored in along with token information in the local trust table of resource provider.The trust of client Gains resources provider when first application resource also obtains access token, client can be directly passed to resource provider by access token when upper once connection request, first this resource provider checks that whether access token is correct, next checks that whether access token is expired, if access token is expired, represent that access token is invalid, thereby realized client and resource provider, set up and the fastest contact and shortened the interaction flow with server.By this improvement, can effectively alleviate the access pressure of server, improve resource requir efficiency., by setting up the pairing strategy of token and resource, can effectively manage the access rights of token meanwhile, improve security of system.
simulation result
A kind of execution mode provided by the invention is to use three test machines to carry out model to the request process of resource, and its test environment is as follows:
Test machine configuration: CPU:Pentium (R) Dual-Core CPU E5800,3.2GHz; Internal memory: 2G
Network environment: local area network (LAN)
Applied in network performance test instrument: chrome lower network probe card Web Developer-0.4.1
Experimentation: client is to resource provider requested image sensor resource and service provider's internal memory monitoring data resource, records respectively without token and holds in token situation resource bid time of delay as a comparison.
Fig. 2 is client under without access token condition and has under access token condition four needed latency delays schematic diagrames of resource node application resource; Wherein longitudinal axis unit is millisecond.
Without access token in the situation that, the delay analysis of request internal memory monitoring data, the stand-by period is about 9ms.
In the situation that having access token, the Mashup of application image resource and internal memory monitoring resource, through disconnecting frequently and application test again, the stand-by period maintains between 3ms-6ms substantially.
Known through contrast, during holding access token, client can effectively shorten the stand-by period.Why producing such result, is when coming from client and holding access token in essence, only needs three steps to set up and contact with resource provider in certain once connects.After having reduced client and authorization server mutual, server end performance is improved.
It should be noted last that, above embodiment is only unrestricted in order to technical scheme of the present invention to be described.Although the present invention is had been described in detail with reference to embodiment, those of ordinary skill in the art is to be understood that, technical scheme of the present invention is modified or is equal to replacement, do not depart from the spirit and scope of technical solution of the present invention, it all should be encompassed in the middle of claim scope of the present invention.
Claims (3)
1. the resource method for authenticating based on Internet of Things resource sharing platform, is characterized in that, Internet of Things resource sharing platform comprises: client, resource provider and platform, and described client, described resource provider and described platform comprise respectively trust list; The method comprises:
Step 1: described client sends sensor resource request, if this client has the access token of successfully applying for to user, sends to described resource provider by this access token and described sensor resource request in the lump;
Step 2: described resource provider and described platform carry out synchronous communication, with authentication-access token validity and user identity validity; If described client provides this access token, described resource provider checks the validity of described access token by local trust list, if described access token is effective, think that described client also necessarily stored client authorization voucher in the trust table of described platform, and client authorization voucher is effective, described resource provider is to client transmissions resource.
2. resource method for authenticating according to claim 1, it is characterized in that, in described step 2, although if existed without this access token or this access token in the trust table of described resource provider but described access token is expired, carry out following steps: step 3: described resource provider is redirected to described client;
Step 4: described client is to described platform request authorized certificate, described platform is by the client authorization voucher of client described in trust table look-up, if there is client authorization voucher and effective, go to step seven, described platform sends authorized certificate to described client; Otherwise go to step five;
Step 5: described platform is redirected to user;
Step 6: described user sends user key to described platform, for verifying described user's legitimacy;
Step 7: described platform sends described authorized certificate to described client, wherein, if described platform validation client's credit success, this platform sends authorized certificate to described client, and described client authorization voucher is stored in the trust list of this platform simultaneously;
Step 8: described client relies on described authorized certificate to access token described in described resource provider request;
Step 9: described resource provider sends described access token to described client, wherein, described resource provider is verified this authorized certificate, if be proved to be successful, to this client, send described access token, described client is utilized described access token request resource; Otherwise described resource provider is refused this access token request of described client;
Step 10: described resource provider is to described client transmissions resource, wherein, described resource provider authentication-access token, if described access token is effective, send described sensor resource, described token information is stored in the trust list of described resource provider simultaneously.
3. resource method for authenticating according to claim 1, is characterized in that, described step 1 also comprises: OpenID user's registration step and OpenID user's login step, wherein,
In described OpenID user's registration step, user is to one section of additional ciphertext of OP input or picture, for verify OpenID server in login process;
In described OpenID user's login step, first described user sends OpenID to described OpenID server, this OpenID server is searched corresponding described ciphertext according to OpenID, and this ciphertext is sent it back to described user, this user checks this ciphertext, if this ciphertext is mated with the ciphertext in when registration, input password.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201210359234.6A CN103685204A (en) | 2012-09-24 | 2012-09-24 | Resource authentication method based on internet of things resource sharing platform |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201210359234.6A CN103685204A (en) | 2012-09-24 | 2012-09-24 | Resource authentication method based on internet of things resource sharing platform |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN103685204A true CN103685204A (en) | 2014-03-26 |
Family
ID=50321530
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201210359234.6A Pending CN103685204A (en) | 2012-09-24 | 2012-09-24 | Resource authentication method based on internet of things resource sharing platform |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN103685204A (en) |
Cited By (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2016061819A1 (en) * | 2014-10-24 | 2016-04-28 | 华为技术有限公司 | Resource access method and apparatus |
| CN105991614A (en) * | 2015-03-03 | 2016-10-05 | 阿里巴巴集团控股有限公司 | Open authorization, resource access method and device, and a server |
| WO2016173303A1 (en) * | 2015-04-29 | 2016-11-03 | 中兴通讯股份有限公司 | Shared file processing method and device |
| CN106254075A (en) * | 2015-06-11 | 2016-12-21 | 佳能株式会社 | Certificate server system and method |
| CN106790283A (en) * | 2017-02-24 | 2017-05-31 | 广州华睿电子科技有限公司 | A kind of Internet of things system framework and data communications method |
| CN107925668A (en) * | 2015-07-02 | 2018-04-17 | 康维达无线有限责任公司 | The dynamic authorization frame of resource driving |
| CN107967185A (en) * | 2017-12-04 | 2018-04-27 | 深圳市英威腾电气股份有限公司 | A kind of interface call method, device, equipment and computer-readable recording medium |
| CN109756336A (en) * | 2017-11-03 | 2019-05-14 | ***通信有限公司研究院 | A kind of authentication method, V2X computing system and V2X calculate node |
| CN105208024B (en) * | 2015-09-22 | 2019-08-20 | 深圳市金溢科技股份有限公司 | Without using the data safe transmission method and system of HTTPS, client and server-side |
| CN110582772A (en) * | 2018-02-13 | 2019-12-17 | 指纹卡有限公司 | Data registration at a sensor reader and data request at a sensor reader |
| CN112368730A (en) * | 2018-06-22 | 2021-02-12 | 维萨国际服务协会 | Secure remote transaction framework using dynamic secure checkout elements |
| CN113507443A (en) * | 2021-06-10 | 2021-10-15 | 广州大学 | Internet of things access control method and device based on time capability tree |
| CN113542427A (en) * | 2021-07-21 | 2021-10-22 | 杭州华橙软件技术有限公司 | Trust relationship establishing method and device and Internet of things system |
| CN113711631A (en) * | 2019-05-02 | 2021-11-26 | 华为技术有限公司 | Mobile equipment for controlling Internet of things equipment |
-
2012
- 2012-09-24 CN CN201210359234.6A patent/CN103685204A/en active Pending
Cited By (27)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11082848B2 (en) | 2014-10-24 | 2021-08-03 | Huawei Technologies Co., Ltd. | Resource access method and apparatus |
| US10587531B2 (en) | 2014-10-24 | 2020-03-10 | Huawei Technologies Co., Ltd. | Resources access method and apparatus |
| WO2016061819A1 (en) * | 2014-10-24 | 2016-04-28 | 华为技术有限公司 | Resource access method and apparatus |
| US11812264B2 (en) | 2014-10-24 | 2023-11-07 | Huawei Cloud Computing Technologies Co., Ltd. | Resource access method and apparatus |
| CN105991614B (en) * | 2015-03-03 | 2019-07-23 | 阿里巴巴集团控股有限公司 | It is a kind of it is open authorization, resource access method and device, server |
| CN105991614A (en) * | 2015-03-03 | 2016-10-05 | 阿里巴巴集团控股有限公司 | Open authorization, resource access method and device, and a server |
| WO2016173303A1 (en) * | 2015-04-29 | 2016-11-03 | 中兴通讯股份有限公司 | Shared file processing method and device |
| CN106254075A (en) * | 2015-06-11 | 2016-12-21 | 佳能株式会社 | Certificate server system and method |
| CN106254075B (en) * | 2015-06-11 | 2020-02-28 | 佳能株式会社 | Authentication server system and method |
| US11451555B2 (en) | 2015-07-02 | 2022-09-20 | Convida Wireless, Llc | Resource-driven dynamic authorization framework |
| CN107925668A (en) * | 2015-07-02 | 2018-04-17 | 康维达无线有限责任公司 | The dynamic authorization frame of resource driving |
| US10893051B2 (en) | 2015-07-02 | 2021-01-12 | Convida Wireless, Llc | Resource-driven dynamic authorization framework |
| CN107925668B (en) * | 2015-07-02 | 2021-08-03 | 康维达无线有限责任公司 | Resource-driven dynamic authorization framework |
| CN105208024B (en) * | 2015-09-22 | 2019-08-20 | 深圳市金溢科技股份有限公司 | Without using the data safe transmission method and system of HTTPS, client and server-side |
| CN106790283A (en) * | 2017-02-24 | 2017-05-31 | 广州华睿电子科技有限公司 | A kind of Internet of things system framework and data communications method |
| CN109756336B (en) * | 2017-11-03 | 2021-09-10 | ***通信有限公司研究院 | Authentication method, V2X computing system and V2X computing node |
| CN109756336A (en) * | 2017-11-03 | 2019-05-14 | ***通信有限公司研究院 | A kind of authentication method, V2X computing system and V2X calculate node |
| CN107967185B (en) * | 2017-12-04 | 2021-08-27 | 深圳市英威腾电气股份有限公司 | Interface calling method, device, equipment and computer readable storage medium |
| CN107967185A (en) * | 2017-12-04 | 2018-04-27 | 深圳市英威腾电气股份有限公司 | A kind of interface call method, device, equipment and computer-readable recording medium |
| CN110582772A (en) * | 2018-02-13 | 2019-12-17 | 指纹卡有限公司 | Data registration at a sensor reader and data request at a sensor reader |
| CN112368730A (en) * | 2018-06-22 | 2021-02-12 | 维萨国际服务协会 | Secure remote transaction framework using dynamic secure checkout elements |
| CN113711631A (en) * | 2019-05-02 | 2021-11-26 | 华为技术有限公司 | Mobile equipment for controlling Internet of things equipment |
| CN113711631B (en) * | 2019-05-02 | 2024-04-09 | 华为云计算技术有限公司 | Mobile device for controlling Internet of things equipment |
| CN113507443A (en) * | 2021-06-10 | 2021-10-15 | 广州大学 | Internet of things access control method and device based on time capability tree |
| CN113507443B (en) * | 2021-06-10 | 2022-03-25 | 广州大学 | Internet of things access control method and device based on time capability tree and storage medium |
| CN113542427A (en) * | 2021-07-21 | 2021-10-22 | 杭州华橙软件技术有限公司 | Trust relationship establishing method and device and Internet of things system |
| CN113542427B (en) * | 2021-07-21 | 2024-05-28 | 杭州华橙软件技术有限公司 | Trust relationship establishing method, trust relationship establishing device and internet of things system |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN103685204A (en) | Resource authentication method based on internet of things resource sharing platform | |
| US10027670B2 (en) | Distributed authentication | |
| US9215232B2 (en) | Certificate renewal | |
| CN106209749B (en) | Single sign-on method and device, and related equipment and application processing method and device | |
| CN101515932B (en) | Method and system for accessing Web service safely | |
| CN104767731B (en) | A kind of Restful move transactions system identity certification means of defence | |
| EP2842258B1 (en) | Multi-factor certificate authority | |
| US8407464B2 (en) | Techniques for using AAA services for certificate validation and authorization | |
| US9172541B2 (en) | System and method for pool-based identity generation and use for service access | |
| JP6061633B2 (en) | Device apparatus, control method, and program thereof. | |
| US20140289831A1 (en) | Web authentication using client platform root of trust | |
| CN108876669B (en) | Course notarization system and method applied to multi-platform education resource sharing | |
| JP2015005202A (en) | Authority transfer system, approval server system, control method and program | |
| CN103475666A (en) | Internet of things resource digital signature authentication method | |
| US20200076797A1 (en) | System and data processing method | |
| US11924211B2 (en) | Computerized device and method for authenticating a user | |
| CN109962892A (en) | A kind of authentication method and client, server logging in application | |
| CN109088890A (en) | A kind of identity identifying method, relevant apparatus and system | |
| US20150180862A1 (en) | Method of generating one-time password and apparatus for performing the same | |
| CN105656856A (en) | Resource management method and device | |
| US20160269420A1 (en) | Apparatus for verifying safety of resource, server thereof, and method thereof | |
| Tiwari et al. | Design and Implementation of Enhanced Security Algorithm for Hybrid Cloud using Kerberos | |
| Kerttula | A novel federated strong mobile signature service—the finnish case | |
| US11595215B1 (en) | Transparently using macaroons with caveats to delegate authorization for access | |
| US11595389B1 (en) | Secure deployment confirmation of IOT devices via bearer tokens with caveats |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20140326 |