HTTPS安全下的Rest API [英] Rest API under https security

查看:98
本文介绍了HTTPS安全下的Rest API的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我是新来的,需要指导,所以我可以提出正确的问题.这是交易:

I am new and need directions so I can ask the correct questions. Here's the deal:

我已经在HTTPS下开发了REST API.

I have developed a REST API under HTTPS.

用户必须提供有效的令牌才能使用API​​.

The user must provide a valid token to use the API.

令牌未使用超过5分钟后即失效.

The token expires after not being used for more than 5 minutes.

要获取令牌,客户端必须调用身份验证API,并传递其私有主密钥或辅助密钥以及用户号.

To obtain the token, the client must call the authentication API passing his private primary or secondary key, along with his user number.

每个键都是唯一的,在数据​​库中我将​​其保存为哈希值.用户将他的主密钥或副密钥通过带有密钥"pk"的标题传递给标题.或"sk"和用户号码".

Each key is unique, and on the database I save it's hash. The user passes his primary or secondary key through the header with key "pk" or "sk" and "usernumber".

服务器将获取这些密钥并将其发送到数据库,数据库将应用哈希并检查它们是否有效.

The server will get those keys and send to the database, which will apply the hash and check if they are valid.

一旦密钥有效,令牌本身就会在数据库中生成并返回给用户.

Once the keys are valid, a token itself is generated on the database, and returned to the user.

我关心的是在标头上传递主键或辅助键.我不确定是否有人可以从外部获取这些数据,也不是最佳实践.我正在尝试获得一些指导,并且介绍了基本的auth,oauth等.但是它们似乎都在HTTP上.我对API HTTPS的了解不多,因此在这里我还需要一些指导.我可以让我的API仅接受https请求吗?如果是这样,是否适用相同的安全规则?

My concern regards passing the primary key or secondary key on the headers. I am not sure if someone can obtain those data from outside and neither if it is the best practice. I am trying to get some directions, and I have came upon basic auth, oauth, and others. But they all seem to be on HTTP. I have not found much about API HTTPS, so I also need some directions here. Can I make my API accept only https requests? If so, does the same security rules apply?

提前谢谢.

推荐答案

要考虑4个安全方面.大多数框架定义了身份验证和授权的流程.一些框架也通过签名定义完整性.

There are 4 security aspects to consider. Most of the frameworks define the flow for Authentication and Authorization. Some frameworks define Integrity as well via Signatures.

但是,几乎所有人都严重依赖加密数据来确保机密性.也就是说,如果通信基于HTTP,则他们建议使用HTTPS

But almost all heavily rely on encrypted data for for Confidentiality. i.e they recommend HTTPS if the communication is based on HTTP

  • 身份验证:

  • Authentication:

识别正在与您的API通讯的人.

Identifying who is talking to your API.

授权:

一旦确定了谁正在与您的API对话,请确保他们有权与之对话.如果身份验证就像检查某人的ID并允许他们进入建筑物.然后授权就像允许他们进入有访问密码的房间.

Once you have identified who is talking to your API, ensuring they have the permission to talk to. If authentication is like checking someone's Id and allowing them into the building. Then authorisation is like allowing them to go into room for which they have access code.

完整性:一个知道您正在与谁谈话以及允许他们做什么的人,您仍然需要确保接收到的数据是来自他们的,而不是被篡改的数据.

Integrity: One you know who are you talking to and what they are allowed to do, you still need to make sure that data you are receiving is from them and not tampered data.

机密性可能是他们没有在篡改数据,而是通过有线方式读取了所有数据,以便以后他们可以使用该数据并假装成为您信任的人.因此,除了发送方和接收方之外,没有其他人可以看到数据.

Confidentiality May be they are not tampering the data but reading all the data over the wire so later they can use that data and pretend to be the person you trust. So except for the sender and receiver no one else to see the data.

注意:

  • 以上四个方面都是为了确保流程的安全性.

  • The above 4 aspects are for security on the flow.

您还必须考虑静态安全性.在这方面,您似乎在服务器端具有强大的设计.

You also have to consider security at rest. You seems to have strong design here on the server side for this aspect.

您是否考虑过令牌在5分钟后过期该怎么办.您的用户不会每5分钟输入一次用户号和主键/辅助键.而且,如果您打算将其存储在客户端以便每5分钟自动执行一次操作,那么您就必须考虑将其存储在客户端的位置以及此方面的安全性

Have you considered what would you do when the token expires after 5 minutes. You user won't be happy entering user number and primary key/secondary key every 5 minutes. And if you plan to store it on client side so you can automate it every 5 minute, then you have to think about where would you store it in the client side and security at rest aspect for that

这篇关于HTTPS安全下的Rest API的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆