其中知名的OpenID提供商预计将支持一个新的网站？ [英] Which well-known OpenID providers is a new site expected to support?
问题描述
我打算开发一个支持OpenID的作为连接依赖方，从而使应用程序的用户可以注册并登录使用他所选择的身份提供商的Web应用程序。 （这是每个堆栈Exchange站点我的登录使用相同的技术。）该应用程序将可用于下载和安装由服务器操作员，就像字preSS，phpBB的，并且链接到MediaWiki软件可用。与之连接的OpenID提供商应的服务器运营商期望有手动注册？
返回时的OpenID 2.0是最常见的协议版本，大部分身份提供者（国内流离失所者）允许任何依赖方（RP）使用其身份服务。只有少数国内流离失所者操作的RP的白名单;我跑进一个是贝宝接入（现在称为登录在使用PayPal ）。有商业上的原因近距离接触，但需要一个封闭的政策，对国内流离失所者额外的努力，所以大多数没有打扰。
在2015年4月，谷歌在支持OpenID的连接，其中每个RP是由供应商发出了自己的客户端ID和客户端密钥一个OAuth 2.0客户端应用程序的下降了OpenID 2.0。通常情况下，的OAuth要求每个客户机与每个提供者进行带外，这是细时每个提供暴露具有唯一的API受保护的资源来注册。但OpenID的连接是一种常见的验证API，所有的国内流离失所者预期将揭露当用户输入相应的OpenID识别URI到RP的登录页面，以同样的方式。因此， OpenID的连接规格描述了一个可选的动态客户注册（DYN-REG）功能，该功能允许以RP自动注册为OAuth客户端，如汉斯Z.的回答提到了您可以使用OpenID的连接没有获得OAuth认证？。然而，每个IDP必须作出实施达因 - 章的努力。谷歌和PayPal是选择不这样做的OpenID连接国内流离失所者的例子。即使供应商确实实现DYN-章，该规范仍然允许IDP要求的RP第一present由提供者签发的有效首次访问令牌。因此，如果有 N 的RP和 M 的公共境内流离失所者，人有阅读并接受合同的 N 的*的 M 倍。
要换个说法，在OpenID的2.0默认是打开的;在OpenID的连接默认是关闭的。
所以，随着越来越多的OpenID提供商效仿谷歌的领先地位，并有利于OpenID的连接的下降了OpenID 2.0，如果我走了RP的活，我希望谁在标识符URI粘贴到被拒之门外一个错误消息影响最终用户该标识的供应商是未知的Example.com，不支持动态客户端注册。然后运行我的Web应用程序的服务器的运营商将要读这样的错误日志和手动登录了每一个这样的IDP获取客户端凭据。我也要建造配置变量到这个Web应用程序让服务器运营商指定的客户端凭据在每届流行的供应商，从而使该网站的用户转换，而不是失望。
我想很容易让谁下载了我的应用程序在他的域中的Web服务器上安装它，去现场为RP服务器运营商。所以，我想它的安装过程中提示公众对国内流离失所者的服务器运营商很可能会遇到这个问题，而不是只是一个空白加入OpenID的连接提供者的形式留下管理员对自己的。
其他相关问题（的OpenID提供商连接并的的OpenID提供商连接的列表）有一个列表过短，过时的，不能分离为其手动注册国内流离失所者预计，而不是从那些小众流行的分离境内流离失所者。例如，Salesforce.com是一个利基IDP的只允许自己的客户要的RP ，我不认为最终用户希望能够在一个公共的Web应用程序从一个利基IDP输入一个标识符。
我想从什么资源，我可以收集关于广泛使用的国内流离失所者自己的信息了解并不断更新。
所以，我将如何去之前的发现，不支持动态开放注册客户端知名通用的OpenID提供商连接的拍摄现场活？
- 要检查的OpenID提供商连接最佳位置是在这里： http://openid.net/developers/libraries/ 和多达最新认证的供应商名单是在这里： http://openid.net/certification/
2。如果我理解正确的话，你的使用情况完全由OpenID的支持连接
3。我建议你考虑一下IdentityServer3： https://github.com/IdentityServer/IdentityServer3 ，因为我我相信这将回答您的要求。我使用它亲自及其伟大的开源项目在安全领域专家维护和开发。
更新：
我不知道，如果你真的需要动态客户端注册，在OIDC整个应用程序视为单一的客户端/ RP。您的应用程序的客户/用户（和设置每个应用程序的每个客户端的用户）完全由最OIDC供应商的支持，而不需要动态客户端注册。你需要DCR如果你的应用是动态门户伞。
I plan to develop a web application that supports OpenID Connect as a relying party, so that a user of the application can sign up and log in using the identity provider of his choice. (This is the same tech that "My Logins" on each Stack Exchange site uses.) This application would be available for download and installation by server operators, much as WordPress, phpBB, and MediaWiki software are made available. With which OpenID Connect providers should a server operator expect to have to sign up manually?
Back when OpenID 2.0 was the most common protocol version, most identity providers (IDPs) allowed any relying party (RP) to use their identity services. Only a few IDPs operated a whitelist of RPs; the one I ran into was PayPal Access (now called Log In with PayPal). There are business reasons to close access, but a closed policy required extra effort for IDPs, so most didn't bother.
In April 2015, Google dropped OpenID 2.0 in favor of OpenID Connect, in which each RP is an OAuth 2.0 client application with its own client ID and client secret issued by the provider. Normally, OAuth requires each client to register with each provider out of band, which is fine when each provider exposes a protected resource with a unique API. But OpenID Connect is a common authentication API that all IDPs are expected to expose the same way when the user enters a corresponding OpenID identifier URI into a RP's login page. So the OpenID Connect spec describes an optional Dynamic Client Registration (dyn-reg) feature that allows an RP to automatically register as an OAuth client, as mentioned in Hans Z.'s answer to "Can you use OpenID Connect without obtaining OAuth credentials?". However, each IDP has to make the effort to implement dyn-reg. Google and PayPal are examples of OpenID Connect IDPs that have chosen not to do so. And even if a provider does implement dyn-reg, the spec still allows the IDP to require that the RP first present a valid Initial Access Token issued by the provider. Thus if there are n RPs and m public IDPs, a human has to read and accept a contract n*m times.
To put it another way, the default in OpenID 2.0 is open; the default in OpenID Connect is closed.
So as more OpenID providers follow Google's lead and drop OpenID 2.0 in favor of OpenID Connect, if I take an RP live, I expect end users who paste in an identifier URI to be turned away with an error message to the effect "The provider of this identifier is unknown to Example.com and does not support Dynamic Client Registration." The operator of a server running my web application would then have to read the log of such errors and manually sign up with each such IDP to obtain client credentials. And I would have to build configuration variables into this web application to let the server operator specify client credentials for each popular provider in advance, so that the site's users are converted instead of disappointed.
I want to make it easy for a server operator who has downloaded my application to install it on a web server in his domain and go live as an RP. So I want its setup process to suggest public IDPs for which server operators are likely to run into this problem, as opposed to just a blank "Add OpenID Connect Provider" form that leaves the administrator on his own.
Other related questions (OpenID Connect providers and List of OpenID Connect providers) have a list that is too short, out of date, not separating IDPs for which manual registration is expected, and not separating popular IDPs from niche ones. For example, Salesforce.com is a niche IDP that allows only its own customers to be RPs, and I don't think end users will expect to be able to enter an identifier from a niche IDP on a public web application. I'd like to know from what sources I could gather information about widely used IDPs myself and keep up to date.
So how would I go about finding well-known general-purpose OpenID Connect providers that don't support open Dynamic Client Registration before taking a site live?
- Best location to check for OpenID connect providers is here: http://openid.net/developers/libraries/ and up-to-date list of certified providers is here: http://openid.net/certification/
2. If I understood correctly, your use case is totally supported by OpenID Connect.
3. I recommend that you take look at IdentityServer3: https://github.com/IdentityServer/IdentityServer3 , as I am sure it will answer your requirements. I am using it personally and its great open source project maintained and developed by experts in the security domain.
Update:
I am not sure if you really require Dynamic Client Registration, in OIDC your whole application considered as single client/RP. your application clients/users (and set of users per each client of your application) is totally supported by most OIDC providers without requiring Dynamic Client Registration. you would need DCR if your application is umbrella of dynamic portals.
这篇关于其中知名的OpenID提供商预计将支持一个新的网站？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
