如何根据 assoc_handle 生成 OpenID 1.1 sig?
How to generate the OpenID 1.1 sig based on assoc_handle?
我已经在 Java 中实现了一个 OpenID 1.1 提供程序,但是我在使用来自 associate
的 assoc_handle
的具有不同签名的智能客户端时遇到了问题。依赖 check_authentication
的愚蠢客户工作正常。具体来说,我正在针对 LiveJournal 进行测试,它不断返回:
signature_mismatch: Prior association invalidated ID provider response.
我的 HMAC()
函数的主体是:
public static byte[] HMAC(byte[] secret, String token_contents) {
SecretKey sk = new SecretKeySpec(secret, "HMACSHA1");
Mac m = Mac.getInstance(sk.getAlgorithm());
m.init(sk);
return m.doFinal(token_contents.getBytes("UTF-8"));
}
调用HMAC()
的token_contents
来自checkid_setup
处理过程中的以下代码。也就是说,签名是在 mode,identity,return_to
上完成的,这也是 signed
响应参数的值。
String token_contents = String.format(
"mode:id_res\nidentity:%s\nreturn_to:%s\n",
identity, return_to);
最后,secret
是由初始 associate
调用返回的 mac_key
的 base64 解码版本(例如,根据规范通过 secret(assoc_handle)
检索) .我已经进行了大量测试以确保 enc_mac_key
可以正确解密。
有什么想法吗?这有什么明显的错误吗?
或者...是否有任何人都知道的简单、独立的客户端可以执行 OpenID 1.1 并跟踪其步骤。鉴于我可能能够弄清楚我在哪里计算不同。
我的问题是使用 base64url encoding on output of key values (mac_key
, enc_mac_key
, dh_server_public
) instead of standard base64. In Apache Commons 我使用的是 encodeBase64URLSafeString
而不是简单的 encodeBase64String
。这是之前在 Open ID Connect 中工作的不幸结转,我误解了函数的性质。
无论如何,帮助我找到答案的是使用非常优秀的 OpenID4Java 及其 simple-openid
JSP 示例。它立即吐出我签名上的错误,抱怨它是 168 位(而不是 160)。
我已经在 Java 中实现了一个 OpenID 1.1 提供程序,但是我在使用来自 associate
的 assoc_handle
的具有不同签名的智能客户端时遇到了问题。依赖 check_authentication
的愚蠢客户工作正常。具体来说,我正在针对 LiveJournal 进行测试,它不断返回:
signature_mismatch: Prior association invalidated ID provider response.
我的 HMAC()
函数的主体是:
public static byte[] HMAC(byte[] secret, String token_contents) {
SecretKey sk = new SecretKeySpec(secret, "HMACSHA1");
Mac m = Mac.getInstance(sk.getAlgorithm());
m.init(sk);
return m.doFinal(token_contents.getBytes("UTF-8"));
}
调用HMAC()
的token_contents
来自checkid_setup
处理过程中的以下代码。也就是说,签名是在 mode,identity,return_to
上完成的,这也是 signed
响应参数的值。
String token_contents = String.format(
"mode:id_res\nidentity:%s\nreturn_to:%s\n",
identity, return_to);
最后,secret
是由初始 associate
调用返回的 mac_key
的 base64 解码版本(例如,根据规范通过 secret(assoc_handle)
检索) .我已经进行了大量测试以确保 enc_mac_key
可以正确解密。
有什么想法吗?这有什么明显的错误吗?
或者...是否有任何人都知道的简单、独立的客户端可以执行 OpenID 1.1 并跟踪其步骤。鉴于我可能能够弄清楚我在哪里计算不同。
我的问题是使用 base64url encoding on output of key values (mac_key
, enc_mac_key
, dh_server_public
) instead of standard base64. In Apache Commons 我使用的是 encodeBase64URLSafeString
而不是简单的 encodeBase64String
。这是之前在 Open ID Connect 中工作的不幸结转,我误解了函数的性质。
无论如何,帮助我找到答案的是使用非常优秀的 OpenID4Java 及其 simple-openid
JSP 示例。它立即吐出我签名上的错误,抱怨它是 168 位(而不是 160)。