Question

我已经用Java实现了一个OpenID 1.1提供程序，但我使用来自assoc_handle associate的{{1}}智能客户端遇到了不同的签名。依赖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"));
}

调用token_contents的{{1}}来自HMAC()处理期间的以下代码。也就是说，签名正在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调用返回的mac_key的base64解码版本（例如，根据规范通过associate检索）。我已经做了大量的测试，以确保secret(assoc_handle)可以正确解密。

有什么想法？这有什么明显的错误吗？

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

Answer 1

我的案例中的问题是使用base64url encoding来输出键值（mac_key，enc_mac_key，dh_server_public）而不是标准的base64。在Apache Commons我使用的是encodeBase64URLSafeString，而不仅仅是encodeBase64String。这是以前在Open ID Connect 中工作的不幸结果，我误解了函数的性质。

无论如何，帮助我发现答案的是使用简单优秀的OpenID4Java及其simple-openid JSP示例。它立即解决了我签名上的错误，抱怨它是168位（而不是160位）。

如何基于assoc_handle生成OpenID 1.1 sig？

1 个答案: