Deribit 渴望建立一个合作伙伴生态系统，以受益于通过结合各方的个人专业知识和增值所产生的协同效应。假设客户可以在Deribit开立账户，并授权注册合作伙伴代表他或她向Deribit发送订单
流程
合作伙伴代表客户生成的交易，Deribit 为合作伙伴提供自动返利。因此，所有客户都必须拥有一个Deribit账户，合作伙伴将代表其客户向Deribit发送订单。由于Deribit只能看到终端客户的执行情况，因此合作伙伴需要在这些订单上添加签名，以便Deribit识别这些订单，并根据其客户产生的费用发送返利。或者，对于 REST 和 FIX，对于 “隐式授权” 和 “授权码” 方法，应用程序还可以使用特殊的访问令牌，然后 Deribit 在内部使用该令牌来识别订单是由某个应用程序发送的
1。合作伙伴确认测试账户（例如 partner@gmail.com），之后 Deribit 将根据中的规格创建客户 ID 和密钥注册合作伙伴申请模型
2。合作伙伴根据测试环境 (test.deribit.com) 中的规格连接到 Deribit 注册合作伙伴申请模型
3.合作伙伴代表另一个测试账户（例如 endclient@hotmail.com）发送订单
4。合作伙伴将在世界标准时间第二天 08:05 验证其已在 Deribit 账户（交易日志）中收到付款
5。验证测试设置后，合作伙伴将在生产环境中创建相同的设置（需要新的 ID 和密钥）
6。Deribit 发送生产凭证并通知合作伙伴，通过使用这些证书，合作伙伴将自动确认已阅读、理解并同意该计划的条款和条件。
7。Deribit 激活生产收入共享
8。合作伙伴徽标和链接可以添加到我们的合作伙伴专区
9。Deribit 和合作伙伴宣布通过电子邮件通讯和社交媒体等营销渠道整合合作伙伴
技术设置-授权概述
Deribit 为合作伙伴应用程序提供了两个工作流程，用于代表 Deribit 用户执行请求。首先涉及获取特殊访问令牌，该令牌将允许识别请求的来源，例如合作伙伴应用程序。其次适用于已经依赖用户提供的 API 密钥的应用程序——但是，该应用程序需要包含额外的签名，这样 Deribit 才能将其识别为请求的来源
仅支持 REST/WebSocket APIv2 和 FIX API。
下表概述了授权方法，并进一步解释了其他详细信息：
1。获取访问令牌
|
API |
隐性补助 |
授权码 |
签名 （用户向应用程序提供的 API 密钥) |
|
休息 |
/app_授权 |
/app_authorision + /public/auth |
合作伙伴标题 |
|
网络套接字 |
/app_授权 |
/app_authorision + /public/auth |
app_user 授权类型 |
|
修复 |
- |
- |
标签 9004 和 9005 |
要让 Deribit 创建此设置，我们需要满足以下要求：
-
应在其中获得返佣的合作伙伴 Deribit 账户
-
合作伙伴重定向 URL
-
合作伙伴域名
授权概述
外部应用程序可以通过三种方法获取可用于 REST 和 WS API 的访问令牌：
-
隐性补助
-
授权码
-
'app_user'授权类型
前两个在初始步骤中使用 /app_authorization 端点。
必需的参数：
-
response_type 一个令牌 隐性补助 和代码 授权码
-
注册后收到的 client_id 客户端 ID
-
redirect_uri 应将响应重定向到哪里（必须是注册时给出的 URI 之一）
-
作用域以空格分隔的名称列表：键入对组，其中名称为-账户、钱包、交易、block_trade，类型为 read 或 read_write
-
state 一个值，该值将随响应一起返回，并应由客户端验证
可选参数：
-
user_id 在同意表中初始选择用户，必须识别当前用户或其子账户之一，如果用户更改了当前账户，则允许跳过该表单（此值是使用令牌接收的） 授权码 流量）
-
显示如果为真，则强制显示同意书，即使用户已经授权了应用程序
1.1 隐性补助
此方法适用于无法安全存储其密钥的应用程序，例如客户端 Web 应用程序。它不如授权码方法安全，因此鼓励应用程序尽可能使用 “授权码” 方法。
步骤：
-
用户被客户端重定向到带有 response_type=token 的 /app_authorization 端点。
示例：
https://test.deribit.com/app_authorization?client_id=oKtyW608&redirect_uri=localhost%3A83
21% 2fcb&scope=trade%3Aread_write%20account%3Aread&state=0&response_type=Token
-
用户授予对应用程序的访问权限。
-
用户被重定向到 redirect_uri，在 URI 片段（# 之后）中传递了以下参数：access_token、refresh_token、token_type、expires_in、state。
在用户授予访问权限后重定向：
localhost:8321/cb#state=0&access_token=1567681835306.1P66aopy.d5bP32TzVWySRWRJRCp8k12DTB2 XvD2kubl7KQYu7TH3W8DrQkbfhy3pkp-saoAJ3QOOOS6keArX2LdPtg_eMiVYhJkxcoYxmol-XMYPp7V5ooJ1f-Ti 9v-Ln2gMCdLcg6_c7eaPInZdjprozs0dPK5U3CBPSpUBgIXE4A_niTTeLamgQkrsQLpuF9OpLGhfAQxJbALMsr0F6 T81AWZ5heIOtiN4FU836iv0Wdrq3lLjC-MeoCJ-0fEWvz9XQ9D08LHUPoks&refresh_token=1568615874421.1 CL4Rqm5.UPCwi6aRYWHAq3h5dvx8vQCycC6Kr36P0d7cZ0gDzb3ofPK46Ka8U1RmLt_Wcsul4XA-e-O0m6QV_OMq9 9VySPxWfO-fZ0nIPktN5m0MjWqf9peSJ4ePzGEReogm2WR8pDb6THAanmUOFEzj1e-4Doa2krFL7oaifDMte5mbOg ti-phudF8mRZodL9vrBqu6Za2RnTWT-nH0E2ZxYB0aPpu7MiG9BEoah9AzkVGbuv26r-iUfLue_SBppYIBVj5r9kR 3Z_JSu71On_CoEdrIlwtkr87ZAFY&expires_in=900&token_type=bearer
1.2 授权码
此方法需要安全存储 客户机密 注册后收到。
步骤：
-
客户端使用 response_type=code 将用户重定向到 /app_authorization 端点。
-
用户授予对应用程序的访问权限。
-
用户被重定向到 redirect_uri，查询字符串中传递了以下参数（之后？）: 代码，状态。
示例：
localhost: 8321/cb #code =99kcas2fyfs8miqntqe6mztxtxrkzgqkegjrycm5xwohe&state=0
-
标准 /public/auth 方法用于检索访问令牌（此处描述）。但是，必须使用 APP-DERI-HMAC-SHA256 方法（与此处描述的 DERI-HMAC-SHA256 相同，使用注册后收到的 clientId 和 ClientSecret）对客户端进行授权，在这种情况下，它仅限于
必须向 /public/auth方法传递三个参数：
-
grant_type-必须是授权码，
-
代码-在上一步中检索，
-
redirect_uri-与前面步骤中使用的 URI 相同。
请求正文示例 （为了便于阅读，添加了空格):
{
"method": "public/auth",
"params": {
"grant_type": "authorization_code",
"code": "99KCas2FyFs8miQnTqE6MzTxRkZGqkegJrycm5XWOHE",
"redirect_uri": "localhost:8321/cb"
}
}
响应的形式与此处描述的相同。
1.2.1 重新获得访问权限-授权类型 app_user
如果应用程序丢失了令牌，或者由于任何原因而失效而无需用户交互即可获取新令牌，则应用程序可以使用在最终响应中返回的 user_id 授权码 流。它使用带有以下参数的公共/身份验证
-
grant_type-必须是 app_user，
-
user_id-与中的令牌一起返回 授权码 公共/身份验证方法响应。
请求示例：
{
"method": "public/auth",
"params": {
"grant_type": "app_user",
"user_id": "FIx_37_l"
}
}
user_id 是唯一的应用程序用户 ID，因此必须授权应用程序使用 APP-DERI-HMAC-SHA256 标头在公共/身份验证方法中使用它。
1.3 使用用户提供的 API 密钥获取访问令牌
此方法与前两种方法不同，因为它要求用户向应用程序提供API密钥，然后应用程序使用该密钥来获取令牌。
要获取访问令牌，应用程序调用 /public/auth 方法，其授权类型为 app_user，参数与 client_signature 授权类型相同：
{
"method": "public/auth",
"params": {
"grant_type": "app_user",
"client_id": "WOQ7igCg",
"timestamp": 1588771838265,
"signature": "c6f6e812d473582d4023ac2584a94406f15c55b1a7f627b375a6a702ca388800",
"nonce": "abcd",
"data": ""
}
}
描述了 client_signature 授权 这里：其他授权方法-签名凭证（WebSocket API）。
与以前的方法类似，需要使用 APP-DERI-HMAC-SHA256 方法对应用程序进行授权。
2。签名授权
以下方法使用用户提供的 API 密钥以及 Deribit 在注册后向应用程序提供的客户端 ID 和密钥来生成必须随请求一起发送的签名。目前仅适用于 REST 和 FIX。
2.1 合作伙伴标题
当用户使用 deri-hmac-sha256 授权标头获得授权时，可以使用额外的合作伙伴标头将请求来源标识为在 Deribit 上注册的应用程序：
-
使用用户提供的客户端 ID 和客户端密钥构造此处所述的授权标头（Deribit 签名证书）。
-
使用 form 的值构造合作伙伴标题：
合作伙伴：id=$ {appId}，sig=$ {appSig}，
其中 AppSig 是与上一步一样计算的签名（具有相同的 stringToSign 值），但使用应用程序的 clientID（AppId）和 ClientSecret。
或者，可以将 appID 和 appSig 作为 appid 和 appsig 值放入 deri-hmac-sha256 授权标头中，而不是合作伙伴标头。
授权示例：
deri-hmac-sha256 id=h4jakxW6F4,ts=1569934139312,nonce=abcd, sig=53150ab0fd7ecfcee65e8d338232fbe527f066baE2e01bcf8b992757283fcc26, appid=WOQ7igCg,appsig=ba610e2b1b2551a24a910a0e411e32aa3e19913177d2376399377167b2e3f232
注意： 此方法不能像以前的方法一样用于获取访问令牌——在每个请求中，必须使用 deri-hmac-sha256 授权标头对用户进行授权。
2.2 修复-标签 9004 和 9005
作为FIX应用程序的 “合作伙伴” 标题的替代方案，我们在登录 (A) 消息中提供了两个自定义标签9004和9005。