0

assoc_handle我已经用 Java 实现了一个 OpenID 1.1 提供程序，但是我在使用来自associate不同签名的智能客户端时遇到了问题。依赖check_authentication工作正常的愚蠢客户。具体来说，我正在针对 LiveJournal 进行测试，并且它不断返回：

signature_mismatch：先前的关联使 ID 提供者响应无效。

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"));
}

for的token_contents调用HMAC()来自于处理 for 期间的以下代码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的 base64 解码版本（例如，根据规范检索）。我已经进行了大量测试以确保可以正确解密。mac_keyassociatesecret(assoc_handle)enc_mac_key

有什么想法吗？这有什么明显的问题吗？

或者......是否有一个简单的、独立的客户端，任何人都知道它会执行 OpenID 1.1 并跟踪其步骤。鉴于我可能能够弄清楚我在哪里计算不同的东西。

4

1 回答 1

0

我的问题是在键值（、、、）的输出上使用base64url 编码，而不是标准的 base64。在Apache Commons中，我使用的不是简单的. 这是之前在 Open ID Connect工作的不幸遗留问题，我误解了该功能的性质。mac_keyenc_mac_keydh_server_publicencodeBase64URLSafeStringencodeBase64String

无论如何，帮助我找到答案的方法是使用简单出色的OpenID4Java及其simple-openidJSP 示例。它立即在我的签名上吐出错误，抱怨它是 168 位（而不是 160 位）。

于 2016-11-12T01:32:15.840 回答