[openspending-dev] api key
Nick Stenning
nick at whiteink.com
Fri Sep 6 10:36:31 UTC 2013
Hey all,
Thanks Stefan for pinging me on this one. Yes, I have some ideas about
authentication and identity across the OKF estate, with two related
goals:
1) Making it easier for those who need to run some kind of web service
affiliated with OKF to do so with the minimum of fuss, allowing them to
focus on the original aspects of their application rather than
boilerplate user management and login code. Stuff like email
verification, email login links, password reset, etc --- it's the same
for everything but takes a long time to do properly if you're doing it
from scratch every time. This will entail building some shared services
(SSO, OAuth provider, etc.) and shared code (or at least patterns) for
building authentication and account management.
2) Making it easier for users of OKF applications to manage their
accounts and passwords. Both with a view to reducing overhead for them,
and reducing overhead for those supporting OKF services (fewer support
requests for locked-out accounts, etc.)
I haven't really thought too much about APIs yet, but perhaps we should
also be thinking about common recommendations for API authentication and
authorization techniques. I'm less opinionated on this topic, because
APIs tend to come in all kinds of shapes and sizes (unlike website login
systems), and thus the commonality between services might not be
substantial enough to justify a specific effort to share techniques or
code.
-N
On Wed, Aug 28, 2013, at 02:05 PM, Stefan Wehrmeyer wrote:
> Hi everyone,
>
> Nick Stenning is starting as technical director at OKF in September. He
> has plans, e.g. federated login for OKF is one of them.
>
> He may have also ideas about API authentication and possibly how to
> centralize this across services(?).
>
> I looped him in.
>
> Cheers
> Stefan
>
> On 28.08.2013, at 14:15 , fukami <odn at foo.io> wrote:
>
> > Hi Tryggvi!
> >
> > On 22.08.2013, at 10:06, Tryggvi Björgvinsson <tryggvi.bjorgvinsson at okfn.org> wrote:
> >> On þri 20.ágú 2013 07:49, fukami wrote:
> >>> In my point of view OpenID seems to be more robust. It's also better
> >>> understood by devs and users (although it has also problems, i.e. it's
> >>> more susceptible to stuff like phishing).
> >>
> >> I think since OpenID still relies on passwords it wouldn't be suitable,
> >> at least not for an API interface. It might actually be worth looking
> >> into supporting OpenID as a login mechanism for OpenSpending.
> >
> > You are right: OAuth is much better suitable for APIs than OpenID.
> >
> >>> But I can help with a review if you like.
> >>
> >> Since OpenSpending is an open source project we still go by the rule of
> >> thumb that implementor gets to choose how a problem is solved. Those
> >> solutions can't be rejected unless they are insecure, introduce bugs,
> >> break tests etc. and the implementor then has a chance to fix that
> >> thanks to constructive criticism.
> >
> > Yeah, and that's the right way to go.
> >
> >> If not then we go with Alberto's solution. Fukami, would you still be
> >> interested in reviewing Alberto's solution?
> >
> > Of course! :)
> >
> >
> > Cheers,
> > fukami
> >
> >
> >
> >
> >
> > _______________________________________________
> > openspending-dev mailing list
> > openspending-dev at lists.okfn.org
> > http://lists.okfn.org/mailman/listinfo/openspending-dev
> > Unsubscribe: http://lists.okfn.org/mailman/options/openspending-dev
>
> --
> Stefan Wehrmeyer
> Projektleiter FragDenStaat.de
> stefan.wehrmeyer at okfn.org
> +49 151 15550559
> Open Knowledge Foundation Deutschland e.V.
> Gneisenaustr. 52
> 10961 Berlin
> http://www.okfn.de
>
> Spenden Sie für FragDenStaat.de:
> https://fragdenstaat.de/hilfe/spenden/
>
>
>
>
> _______________________________________________
> openspending-dev mailing list
> openspending-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/openspending-dev
> Unsubscribe: http://lists.okfn.org/mailman/options/openspending-dev
More information about the openspending-dev
mailing list