<div dir="ltr"><div>Hello Steve.</div><div><br></div><div>Thank you very much for your great work on OAuth 1 authentication for Keystone.</div><div><br></div><div>(1) I have configured Keystone for Federation by following the instructions below.</div><div><br></div><div>Then I can log in to OpenStack through Shibboleth identity provider.</div><div><br></div><div><br></div><div>Configuring Keystone for Federation</div><div><a href="http://docs.openstack.org/developer/keystone/mitaka/configure_federation.html">http://docs.openstack.org/developer/keystone/mitaka/configure_federation.html</a></div><div><br></div><div>-----------------------------------------------------------------------------------------</div><div><br></div><div>(2) I can NOT find the instructions on Configuring Keystone for OAuth1.</div><div><br></div><div>I also can NOT find the instructions on Configuring Keystone for OAuth2. </div><div><br></div><div><a href="http://docs.openstack.org/developer/keystone/mitaka/">http://docs.openstack.org/developer/keystone/mitaka/</a></div><div><br></div><div>Instead I only find the developers' documentation on OAuth2 for OpenStack (OpenStack/Keystone?)</div><div><br></div><div><a href="http://docs.openstack.org/infra/openstackid/oauth2.html">http://docs.openstack.org/infra/openstackid/oauth2.html</a></div><div><br></div><div>OAuth2 IdP?</div><div><br></div><div><a href="https://github.com/openstack-infra/openstackid">https://github.com/openstack-infra/openstackid</a></div><div><br></div><div>Comparing the source code keystone-8.0.0.0b1.tar.gz with the GitHub repository, I discover that there has been fundemental update on oAuth 1 module. </div><div><br></div><div>(2a) For keystone-8.0.0.0b1.tar.gz</div><div><br></div><div><a href="https://github.com/openstack/keystone/releases?after=9.0.0.0b1">https://github.com/openstack/keystone/releases?after=9.0.0.0b1</a></div><div><br></div><div>keystone/contrib/oauth1</div><div><br></div><div>backends/ controllers.py core.py routers.py validator.py</div><div><br></div><div>(2b) For the GitHub repository,</div><div><br></div><div><a href="https://github.com/openstack/keystone/tree/master/keystone">https://github.com/openstack/keystone/tree/master/keystone</a></div><div><br></div><div>keystone/contrib/oauth1</div><div><br></div><div>backends/ routers.py</div><div><br></div><div>keystone/oauth1</div><div><br></div><div>controllers.py core.py routers.py schema.py validator.py</div><div><br></div><div>-----------------------------------------------------------------------------------------<br></div><div><br></div><div>Would you please shed some light on how to configure Keystone for OAuth1? Thank you very much.</div><div><br></div><div>I am trying to develop OAuth 2 client for Keystone. We will contribute our OAuth 2 client source code to the community if we can use Google/Facebook to log in to OpenStack through OAuth 2 client.</div><div><br></div><div>Thanks.</div><div><br></div><div>Best regards,</div><div><br></div><div>Winston Hong</div><div>Ottawa, Ontario</div><div>Canada</div><div><br></div><div><br></div><div>Steve Martinelli <s.martinelli [at] gmail> Jun 27, 2016, 10:57 PM </div><div><br></div><div>> So, the os-oauth routes you mention in the documentation do not make </div><div>> keystone a proper oauth provider. We simply perform delegation (one user </div><div>> handing some level of permission on a project to another entity) with the </div><div>> standard flow established in the oauth1.0b specification. </div><div>> </div><div>> Historically we chose oauth1.0 because one of the implementers was very </div><div>> much against a flow based on oauth2.0 (though the names are similar, these </div><div>> can be treated as two very different beasts, you can read about it here </div><div>> [1]). Even amongst popular service providers the choice is split down the </div><div>> middle, some providing support for both [2] </div><div>> </div><div>> We haven't bothered to implement support for oauth2.0 since there has been </div><div>> no feedback or desire from operators to do so. Mostly, we don't want </div><div>> yet-another-delegation mechanism in keystone, we have trusts and oauth1.0; </div><div>> should an enticing use case arise to include another, then we can revisit </div><div>> the discussion. </div><div>> </div><div>> [1] <a href="https://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/">https://hueniverse.com/2012/07/26/oauth-2-0-and-the-road-to-hell/</a> </div><div>> [2] <a href="https://en.wikipedia.org/wiki/List_of_OAuth_providers">https://en.wikipedia.org/wiki/List_of_OAuth_providers</a></div></div>