有java写的openid 服务器吗

你好，这个是有的

JOIDS (Java OpenID Server) 是一个支持多域名、多用户的 OpenID 提供者，基于 OpenID4Java, Spring Framework, Hibernate, Velocity.开发。

特性：

OpenID Identifier in the format http(s)://username.example.com or http(s)://example.com/username etc.

Multi-domain support.

Multi-user support.

Account management.

Multilingual support (now ba, de, en_US, es, hr, ja, pt, sr, zh_CN, zh_HK, zh_TW are available)

我们知道，服务号有获取用户基本信息的接口，通过oauth2.0网页授权获取的。但是认证的订阅号也有获取用户基本信息的接口了，但是与服务号不同的是，这个需要用户主动触发才可以获得，需要用户发送任意关键词或者点击菜单。

1、先获取openid，用户主动触发，获得openid

2、获取access_token

3、通过这两个获取用户基本信息，头像，昵称等

接口调用请求说明

http请求方式: GET

https://api.weixin.qq.com/cgi...

先在基本配置服务器地址填写下面php文件路径，其中php文件需要修改token

cheeck.php

然后去公众号回复任意关键词即可。

openid拿到了，该去拿access_token了。

也很容易。接口是：

https://api.weixin.qq.com/cgi...

把上面这两个参数（appid=修改，secret=修改）改成你公众号的即可，然后打开公众号基本配置，ip白名单，然后就可以正常获取access_token了。

接口调用请求说明

http请求方式: GET

https://api.weixin.qq.com/cgi...

把上面两个值加上去，访问这个链接即可。

转自： https://segmentfault.com/a/1190000014963408

认证 （ authenticate ）和 授权 （ authorize ）是两个容易被弄混的概念，尤其是只看英文。

由此可见，应用需要先认证用户身份，然后依据用户身份再授权，二者需要联合使用。

对于QQ或者微信这样的应用，用户在登录后会得到该账户的身份凭证。如果其他第三方应用信任并接受QQ或者微信的身份凭证，就可以直接使用该凭证通过第三方的 认证 而登录。登陆之后用户能有权限去做什么，这就是第三方应用根据自己政策而进行的 授权 。我们常遇到有网站在第一次使用QQ或微信账户登录之后需要绑定已用账户，就是因为虽然网站能够通过QQ账户的身份认证，但是对于这样的账户没有对应的授权。

同理，对于一个面向公司内部的服务环境，该公司可能有邮箱系统、网上办公系统、财务系统等等。如果这些系统都是独立的，那么公司的员工就需要每一个系统都分配一个账户，每个系统都需要单独登录。这样显然是低效而麻烦的，更好的解决方案应该是用户在内网中只需要登录一次，所有的子应用系统都能认证其身份，而免去重复登录，这样的方案就被称为单点登录（ single sign-on， SSO ）。

这样做的最明显的好处就是提高用户体验，用户只需要维护一对用户名和口令可以在公司内部畅通无阻。同时，因为是单点登录，所有的用户身份的都被 统一认证 ，也就是说用户的身份凭据（比如口令）只被保存在一处，其他子系统并不直接获得用户的口令等敏感信息，而是接收来自可信来源的身份证明。

单点登录和统一认证中主要的三个协议是 OpenID , OAuth , 金和 SAML ，被称为单点登录的三驾马车。这些协议已经有了各种语言版本的实现，本人也在其他文字做了详尽的介绍，这里专门对比下三种协议的异同。

OpenID是一种 认证 标准，互联网上有很多账户都是支持OpenID比如谷歌、雅虎、PayPal等等。

用户要使用OpenID就必须先在OpenID身份服务器（Identity Provider， IDP）获得OpenID 账号（比如Google账户）。用户可以使用OpenID账户来登录任何一个接受OpenID认证的服务应用（the relying party，RP，依赖方）。OpenID协议标准就是提供一个框架用来IDP和RP之间通信。

本质而言，用户的OpenID是一个为用户个人所拥有的特殊URL(比如 alice2016.openid.com)，所以有些网站甚至会提供选项让用户自己去填写OpenID。

FaceBook曾经也是使用过OpenID的，后来转而开发FaceBook Connect.

OpenID的最新版本是OpenID Connect。具体协议信息请见这里 OpenID Connect 协议入门指南

准确来讲，OAuth2是一个授权的标准协议。也许会令人困惑，OAuth2是OpenID-Connect的基础，但是OpenID-Connect是认证协议（在OpenID-Connect中，ID-Token也被当做是一种资源）。

让我们回到OAuth2，OAuth2提供了一种代理访问机制，也就是说一个应用（可以被称为客户端）可以代替用户到资源服务器上获得属于用户的资源或是进行符合用户权限的操作 ，而用户不用将自己的用户名和口令等身份凭据分享给客户端。OAuth2是通过IDP给第三方应用颁发令牌（Token）来实现以上功能的，第三方应用通过使用令牌向资源服务换取对应的资源。

在Twitter的OAuth指导手册中说OAuth2是一种认证协议，实际上，这是基于授权的“伪认证”。

OAuth协议的认证过程可以类比为如下流程：Alice要外出一段时间，让自己的朋友Bob代为照顾她的房子，所以Alice把自己房子的钥匙交给了Bob，而Bob也就可以任意的进入房子。这里的钥匙就是一种授权的体现——Alice授权Bob进入房子。在这里例子中，房子的所有者Alice就是用户，Bob是客户端，而门锁就是IDP，房子是资源服务器。

如果假设房子钥匙的拥有者就是房子的所有者，那么这个授权的过程也是一种 伪认证 ，之所以加一个伪字，是因为

这个假设并不是总是成立的，比如Bob虽然有钥匙，但是并不是房子的所有者Alice。

更多OAuth的内容，请参见我之前的文章。 OAuth2.0 协议入门指南

SAML协议是三者中时间最长的协议，最初版本制定于2001年，并于2005年修改。作为一种安全性断言标记语言，SAML协议既可以用于认证也用于授权。

所谓的安全性断言，就是关于认证、授权以及用户属性（比如用用户的有效或者住址等信息）的声明集合，在SAML中，这些断言以XML的格式传输。

当要验证一个用户身份时，服务提供商（Service Provider, SP，即RP，应有依赖方）会向IDP发出SAML认证请求，该请求中会以XML格式说明认证方式的设置，比如希望IDP以何种方式验证用户；IDP在认证通过用户身份之后，会返回SAML请求响应，同样以XML格式返回断言表明用户身份和相关属性，此外SAML安全性断言信息必须要使用数字签名以保证其完整性和不可抵赖性（没有强制要求对SAML断言加密）；SP接收到SAML断言之后，验证其消息来源是否费受信任的IDP，验证通过之后解析XML获得认证信息。

除了断言，SAML还定义了如下概念：

更为详细的内容请见：

以下是三种协议的相关对比和总结，便于读者根据自己实际情形来选择下一步要继续去了解哪一种协议。

如果想进一步以上协议的具体，欢迎阅读我的其他文章：

---