API

基于JWE的API接口加密方案设计

前言

在这个互联网和移动互联网高速发展的时代,数据安全成了企业的头等大事。数据安全的范畴很大,包含:技术安全、服务安全、存储安全、传输安全等,本文主要是从传输安全的层面,设计一种基于JWE的API加密方案。

名词说明

**JWE **

JSON Web Encryption ,详细资料:http://self-issued.info/docs/draft-ietf-jose-json-web-encryption.html

目录

(一) 安全算法扫盲

(二) 安全方案演变

(三) JWE的介绍

(四) 基于JWE的API加密方案

本文主要讲解相关理论,后续会有实践的更新


(一) 安全算法扫盲

1.信息安全算法

1.1 加密相关算法

现代密码学中,把算法的加密技术主要分为:

单密钥模式

双密钥模式

无密钥模式

单密钥模式,也称为对称密钥模式,加密和解密方采用同一个密钥。采用这种模式的算法就叫做对称加密算法。

双密钥模式,也称作非对称密钥模式,加密和解密方采用不同的密钥。采用这种模式的算法就叫做非对称加密算法。

无密钥模式,也称作随机密钥模式,每次的密钥都是随机生成,使用一次之后失效。这是一种理想的加密模式,由于设计难度大,目前未得到广泛应用。

本文中主要针对前两类加密算法进行简单介绍。

1.1.1 对称加密算法(Symmetric Encryption)

对称加密算法,又称私钥加密算法,顾名思义加密和解密过程中只用到一个密钥,该密钥也称作私钥。

常见的对称加密算法有:DES、IDEA(基于DES)、3DES(基于DES)、RC4、RC5、RC6、AES。

特点

Feature

关于 php json API接口开发的注意问题

关于 php json接口开发的注意问题

一是注意跨域问题.需要加 Access-Control-Allow-Origin:*  http头.(针对于前端浏览器脚本调用接口)

二是如果请求的header里  Content-Type: 是 application/json,则需要用 file_get_contents(“php://input”);接收.如果用 swoole 框架的话,需要用$request->rawContent()接收.

如果请求header里Contente-Type是 multipart/form-data,或application/x-www-form-urlencoded或application/octet-stream
则需要用 $_POST($_GET)或$_FILES来接收.

Ps :js 代码调用接口示例如下

1.要加contentType: “application/json; charset=utf-8”,

2.需要使用JSON.stringify 转换json对象或把对象转为字符形式,如'{“aa”:22}'(json两边加单引号)

var submit_sync = function() {  
    $.ajax({  
        type: "post",  
        url: 'add-post-json.php',  
        async: false, // 使用同步方式  
        

服务端指南 | 良好的 API 设计指南

设计一套良好的 API 接口。

版本号

在 RESTful API 中,API 接口应该尽量兼容之前的版本。但是,在实际业务开发场景中,可能随着业务需求的不断迭代,现有的 API 接口无法支持旧版本的适配,此时如果强制升级服务端的 API 接口将导致客户端旧有功能出现故障。实际上,Web 端是部署在服务器,因此它可以很容易为了适配服务端的新的 API 接口进行版本升级,然而像 Android 端、IOS 端、PC 端等其他客户端是运行在用户的机器上,因此当前产品很难做到适配新的服务端的 API 接口,从而出现功能故障,这种情况下,用户必须升级产品到最新的版本才能正常使用。

为了解决这个版本不兼容问题,在设计 RESTful API 的一种实用的做法是使用版本号。一般情况下,我们会在 url 中保留版本号,并同时兼容多个版本。

GET】 /v1/users/ // 版本 v1 的查询用户列表的 API 接口

写一个接口应该考虑哪些内容?

我觉得写一个接口应该考虑如下的内容:

  1. 确定 url:是否符合 Restful,是否要符合公司确定的规范?
  2. 确认操作人的权限
  3. 确定要操作的资源的权限
  4. 验证传入的参数:不要相信外面传进来的任何数据
  5. 操作失败的提示
  6. 操作成功的提示
  7. 写文档:如何按规矩写好文档是一件值得花时间和精力梳理的事情
  8. 如何测试接口,用什么数据测试

App架构设计经验谈:接口的设计

App与服务器的通信接口如何设计得好,需要考虑的地方挺多的,在此根据我的一些经验做一些总结分享,旨在抛砖引玉。

安全机制的设计

现在,大部分App的接口都采用RESTful架构,RESTFul最重要的一个设计原则就是,客户端与服务器的交互在请求之间是无状态的,也就是说,当涉及到用户状态时,每次请求都要带上身份验证信息。实现上,大部分都采用token的认证方式,一般流程是:

  1. 用户用密码登录成功后,服务器返回token给客户端;
  2. 客户端将token保存在本地,发起后续的相关请求时,将token发回给服务器;

REST API 安全设计指南

REST API 安全设计指南。REST的全称是REpresentational State Transfer,它利用传统Web特点,提出提出一个既适于客户端应用又适于服务端的应用的、统一架构,极大程度上统一及简化了网站架构设计。

目前在三种主流的Web服务实现方案中,REST模式服务相比复杂的SOAP和XML-RPC对比来讲,更加简洁,越来越多的web服务开始使用REST设计并实现。但其缺少安全特性,《REST API 安全设计指南》就是一个REST API安全设计的指南,权当抛砖引玉,推荐网站后台设计及网站架构师们阅读。…

设计不使用oauth身份验证的安全restful api

调用api客户端程序,需要在header处发送 

API_ID: 1

API_TIME: 时间戳

API_HASH:  $clienthash

$user=”username”;

$publicKey=’hello’;

$privateKey=  hash_hmac(‘sha256’, $user, $publicKey); 需要先把客户端程序的privateKey存入数据库.

$data=json字符串.

$clienthash = hash_hmac(‘sha256’, API_TIME.API_ID.$data, $privateKey);

API端验证:

$serverHash = hash_hmac(‘sha256’, API_TIME.API_ID.$data, $privateKey);//到数据库查找此客户端的privateKey;

第 1 页,共 2 页12