We are currently developing an open source OAuth 2.0 provider extension for pyramid and are aiming for full integration of draft 18 down the line.
Currently we are focusing on the "client_credentials" grant type, the most simple type of communication between a consumer and its provider, requiring no intervention of the resource owner, i.e. the user. After this, we will fine-tune all the aspects before moving on to implement the other grant types.
The docs and tests are currently lacking, but they will soon find its way on the repository.
If you are interested in helping us, don't hesitate to contact me! As always, feedback is much appreciated.
> We are currently developing an open source OAuth 2.0 provider extension for
> pyramid and are aiming for full integration of draft 18 down the line.
> Currently we are focusing on the "client_credentials" grant type, the most
> simple type of communication between a consumer and its provider, requiring
> no intervention of the resource owner, i.e. the user. After this, we will
> fine-tune all the aspects before moving on to implement the other grant
> types.
> The docs and tests are currently lacking, but they will soon find its way on
> the repository.
> If you are interested in helping us, don't hesitate to contact me! As
> always, feedback is much appreciated.
> On Aug 9, 8:29 am, Kevin Van Wilder<ke...@tick.ee> wrote: >> Hi there,
>> We are currently developing an open source OAuth 2.0 provider extension for >> pyramid and are aiming for full integration of draft 18 down the line.
>> Currently we are focusing on the "client_credentials" grant type, the most >> simple type of communication between a consumer and its provider, requiring >> no intervention of the resource owner, i.e. the user. After this, we will >> fine-tune all the aspects before moving on to implement the other grant >> types.
>> The docs and tests are currently lacking, but they will soon find its way on >> the repository.
>> If you are interested in helping us, don't hesitate to contact me! As >> always, feedback is much appreciated.
As far as I have looked into Velruse, it seems to be about easily integrating third party authentication providers in your web application. This is of course fantastic and we will be using Velruse in our own software once we introduce twitter-login, etc..
However consuming oauth(2?) very well, Velruse does not act as a provider for OAuth 2 and this is what the pyramid_oauth2 extension is about.
Is there any sample available or at least basic documentation? We would like to include oauth2 provider to a pyramid based backend application we are developing.
On Tuesday, August 9, 2011 8:29:00 AM UTC+2, Kevin Van Wilder wrote:
> Hi there,
> We are currently developing an open source OAuth 2.0 provider extension > for pyramid and are aiming for full integration of draft 18 down the line.
> Currently we are focusing on the "client_credentials" grant type, the most > simple type of communication between a consumer and its provider, requiring > no intervention of the resource owner, i.e. the user. After this, we will > fine-tune all the aspects before moving on to implement the other grant > types.
> The docs and tests are currently lacking, but they will soon find its way > on the repository.
> If you are interested in helping us, don't hesitate to contact me! As > always, feedback is much appreciated.
> Is there any sample available or at least basic documentation? We would like
> to include oauth2 provider to a pyramid based backend application we are
> developing.
> Best regards
> On Tuesday, August 9, 2011 8:29:00 AM UTC+2, Kevin Van Wilder wrote:
>> Hi there,
>> We are currently developing an open source OAuth 2.0 provider extension
>> for pyramid and are aiming for full integration of draft 18 down the line.
>> Currently we are focusing on the "client_credentials" grant type, the most
>> simple type of communication between a consumer and its provider, requiring
>> no intervention of the resource owner, i.e. the user. After this, we will
>> fine-tune all the aspects before moving on to implement the other grant
>> types.
>> The docs and tests are currently lacking, but they will soon find its way
>> on the repository.
>> If you are interested in helping us, don't hesitate to contact me! As
>> always, feedback is much appreciated.
> To post to this group, send email to pylons-devel@googlegroups.com.
> To unsubscribe from this group, send email to
> pylons-devel+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-devel?hl=en.
A few months ago I've developed an Oauth2 provider based in Pyramid too. It
works with the resource owner password credentials flow. This flow is not
the most popular oAuth flow, but it's useful in case that we want to oAuth
enable an app or a set of apps in an scenario with an already existing user
backend. Using this flow you can use Osiris as a gateway between your
existing user store and oAuth enable it. Osiris will authenticate the user
credentials against your user store and if suceeds it will issue a oAuth
token. Then, an app can use it to impersonate the user's token to access an
oAuth enabled REST API, for example.
> 2012/9/12 Andrija Frinčić <bob.rock...@gmail.com>:
> > Hi Kevin
> > Is there any sample available or at least basic documentation? We would
like
> > to include oauth2 provider to a pyramid based backend application we are
> > developing.
> > Best regards
> > On Tuesday, August 9, 2011 8:29:00 AM UTC+2, Kevin Van Wilder wrote:
> >> Hi there,
> >> We are currently developing an open source OAuth 2.0 provider extension
> >> for pyramid and are aiming for full integration of draft 18 down the
line.
> >> Currently we are focusing on the "client_credentials" grant type, the
most
> >> simple type of communication between a consumer and its provider,
requiring
> >> no intervention of the resource owner, i.e. the user. After this, we
will
> >> fine-tune all the aspects before moving on to implement the other grant
> >> types.
> >> The docs and tests are currently lacking, but they will soon find its
way
> >> on the repository.
> >> If you are interested in helping us, don't hesitate to contact me! As
> >> always, feedback is much appreciated.
> > To post to this group, send email to pylons-devel@googlegroups.com.
> > To unsubscribe from this group, send email to
> > pylons-devel+unsubscribe@googlegroups.com.
> > For more options, visit this group at
> > http://groups.google.com/group/pylons-devel?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
> To post to this group, send email to pylons-devel@googlegroups.com.
> To unsubscribe from this group, send email to
> A few months ago I've developed an Oauth2 provider based in Pyramid too. It
> works with the resource owner password credentials flow. This flow is not
> the most popular oAuth flow, but it's useful in case that we want to oAuth
> enable an app or a set of apps in an scenario with an already existing user
> backend. Using this flow you can use Osiris as a gateway between your
> existing user store and oAuth enable it. Osiris will authenticate the user
> credentials against your user store and if suceeds it will issue a oAuth
> token. Then, an app can use it to impersonate the user's token to access an
> oAuth enabled REST API, for example.
I plan to add the flow used in javascript applications very soon.
As if it is possible to use standalone, it shouldn't be too difficult
but right now it is not distributed as a separate package, you have to
extract it from Yith Library.
>> 2012/9/12 Andrija Frinčić <bob.rock...@gmail.com>:
>> > Hi Kevin
>> > Is there any sample available or at least basic documentation? We would
>> > like
>> > to include oauth2 provider to a pyramid based backend application we are
>> > developing.
>> > Best regards
>> > On Tuesday, August 9, 2011 8:29:00 AM UTC+2, Kevin Van Wilder wrote:
>> >> Hi there,
>> >> We are currently developing an open source OAuth 2.0 provider extension
>> >> for pyramid and are aiming for full integration of draft 18 down the
>> >> line.
>> >> Currently we are focusing on the "client_credentials" grant type, the
>> >> most
>> >> simple type of communication between a consumer and its provider,
>> >> requiring
>> >> no intervention of the resource owner, i.e. the user. After this, we
>> >> will
>> >> fine-tune all the aspects before moving on to implement the other grant
>> >> types.
>> >> The docs and tests are currently lacking, but they will soon find its
>> >> way
>> >> on the repository.
>> >> If you are interested in helping us, don't hesitate to contact me! As
>> >> always, feedback is much appreciated.
>> > To post to this group, send email to pylons-devel@googlegroups.com.
>> > To unsubscribe from this group, send email to
>> > pylons-devel+unsubscribe@googlegroups.com.
>> > For more options, visit this group at
>> > http://groups.google.com/group/pylons-devel?hl=en.
>> --
>> You received this message because you are subscribed to the Google Groups
>> "pylons-devel" group.
>> To post to this group, send email to pylons-devel@googlegroups.com.
>> To unsubscribe from this group, send email to
>> pylons-devel+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/pylons-devel?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-devel" group.
> To post to this group, send email to pylons-devel@googlegroups.com.
> To unsubscribe from this group, send email to
> pylons-devel+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-devel?hl=en.
I've had to integrate against oAuth a few times, and have constantly found it a hassle.
The existing 'core' Python libraries for it are rather scattered in terms of active development, maturity and "street cred" ( by which I mean that you'll often find a big name website saying "You should use this library for oAuth against our API!", yet that library is badly documented, barely functional, often really out of date with current specs , and ships with a bunch of its own tests which it won't even pass ).
I've seen a handful of oAuth plugins and "micro-frameworks" for django or uwsgi servers too. They try to be a complete plug&play solution, but then you have to worry about integrating the endpoints, skinning the views, and persisting the data. After a few minutes of playing with the modules -- if your app doesn't meet the exact specs/design requirements of these plugins, you're looking at a huge mess and really unattractive option.
So for general feedback, I would suggest this:
1- make a core oAuth library that just works , is up to date , and is designed to easily integrate against
2- create a reference Pyramid/etc implementation of the client and server functions ( ie, like your sample views )
3- create a bunch of helper functions that aid in setting up the above , which people can just call if they're lazy.
Using SqlAlchemy as a datastore is a neat feature , but there are 2 red flags to me:
- it doesn't look like i'll ( easily or at all ) be able to override your tablesnames or database structure - i'm now limited to sqlalchemy supported databases. if i'm on mysql/postgresql/oracle, that's fine - but if i'm using a mongodb or similar datastore -- forget it.
I would, personally, prefer to have some sort of "config" object that I can pass in - which defines/provides some callbacks for searching and storing data.
Having a drop-in capability and default settings of sqlalchemy are both fine –- but relying on it? that seems too much like rails/django and all that standardization/configuration restrictions which are a huge part of the reason why people choose Pyramid , Flask, or other frameworks instead of Django.
On Tue, Sep 25, 2012 at 1:13 PM, Jonathan Vanasco <jonat...@findmeon.com> wrote:
> This is purely my very opinionated 2˘ ...
> I've had to integrate against oAuth a few times, and have constantly found
> it a hassle.
> The existing 'core' Python libraries for it are rather scattered in terms of
> active development, maturity and "street cred" ( by which I mean that
> you'll often find a big name website saying "You should use this library for
> oAuth against our API!", yet that library is badly documented, barely
> functional, often really out of date with current specs , and ships with a
> bunch of its own tests which it won't even pass ).
I believe this is the purpose of oauthlib. I'd love to see a reference
implementation in pyramid.
On Tuesday, September 25, 2012 2:42:24 PM UTC-4, Michael Merickel wrote:
> On Tue, Sep 25, 2012 at 1:13 PM, Jonathan Vanasco <jona...@findmeon.com<javascript:>> > wrote: > > This is purely my very opinionated 2˘ ...
> > I've had to integrate against oAuth a few times, and have constantly > found > > it a hassle.
> > The existing 'core' Python libraries for it are rather scattered in > terms of > > active development, maturity and "street cred" ( by which I mean that > > you'll often find a big name website saying "You should use this library > for > > oAuth against our API!", yet that library is badly documented, barely > > functional, often really out of date with current specs , and ships with > a > > bunch of its own tests which it won't even pass ).
> I believe this is the purpose of oauthlib. I'd love to see a reference > implementation in pyramid.
By any chance, has anyone implemented an oauth provider example using oauthlib in pyramid?
Are there any other choices? It doesn't look like oauthlib implements an oath2 server from what I can tell, but it seems to be the only oauth solution that I have run across that is currently maintained.
On Wednesday, September 26, 2012 10:29:16 AM UTC-4, Jonathan Vanasco wrote:
> holy crap that sounds awesome.
> On Tuesday, September 25, 2012 2:42:24 PM UTC-4, Michael Merickel wrote:
>> On Tue, Sep 25, 2012 at 1:13 PM, Jonathan Vanasco <jona...@findmeon.com> >> wrote: >> > This is purely my very opinionated 2˘ ...
>> > I've had to integrate against oAuth a few times, and have constantly >> found >> > it a hassle.
>> > The existing 'core' Python libraries for it are rather scattered in >> terms of >> > active development, maturity and "street cred" ( by which I mean that >> > you'll often find a big name website saying "You should use this >> library for >> > oAuth against our API!", yet that library is badly documented, barely >> > functional, often really out of date with current specs , and ships >> with a >> > bunch of its own tests which it won't even pass ).
>> I believe this is the purpose of oauthlib. I'd love to see a reference >> implementation in pyramid.
