[Standards] Authorization over HTTP

anders conbere aconbere at gmail.com
Thu Nov 8 17:49:28 UTC 2007


Perhaps an example use case would be in order

I like to write socialy networked applications, I don't like to write
them for the benefit of a locked in platform (facebook, myspace,
linkedin), and I don't want to have to create my own locked in
network.

So I looked at the jabber network, it exists in an open distributed
fashion already, and stores all of my buddies in groups already!
That's pretty awesome and has some terrific potential as being the
answer to the problem of network portability. However when I write a
client to access the jabber roster api's I have two problems

1) I have to ask users for their jabber credentials, to pass them to a
jabber client on my server
2) I either have to maintain the state of that connection on my own,
or I have to continually re-authenticate.
3) if I re-authenticate I have to store the users password in memory,
or serialized (bad!)
4) if I maintain the state, I have to write a fairly complicated,
multi-threaded, stateful service that allows message passing from my
web application (I do this right now by wrapping that system in a web
server, this becomes a problem because it doesn't scale well since the
state of the connection is stored in memory, and memory space isn't
shared between web server instances).

Okay... so given that use case (and maybe this is a use case that the
xmpp foundation doesn't want to get into) the best way I can see for
easing the task for developers is creating an authorization scheme,
that allows me to pass of the authentication request via basic http to
the jabber server, and recieve from the server an authentication token
that I then use to contact the jabber server.

Not only does this allow me to create services that talk to jabber
without asking for users credentials (GOOD!) but it passes of storing
the state of the connection to the jabber server (also good!)

~ Anders

On Nov 8, 2007 9:36 AM, anders conbere <aconbere at gmail.com> wrote:
>
> On Nov 8, 2007 4:25 AM, Tomasz Sterna <tomek at xiaoka.com> wrote:
> > Dnia 07-11-2007, Śr o godzinie 15:33 -0800, anders conbere pisze:
> > > Example work flow
> > > ==============
> > >
> > > User = user logging into a web application
> > > Consumer = The Web Application
> > > Service Provider = Users Jabber Server
> > >
> > > Use requests access to an xmpp api from the Consumer
> > > Consumer redirects the user to the Service Provider
> > > The User enters their credentials into the Service Provider
> > > The Service Provider posts back to the Consumer with a unique access
> > > token
> > > The Consumer then make the xmpp api call to the Service Provider with
> > > the unique token granted to it.
> > >
> > > Future request for data from the Consumer would be done with the
> > > token, and provided access to the restricted api's
> >
> > If I understand correctly, what you are describing is
> > OpenID authorized by XMPP.
> >
> > It is already in use. Please see http://openid.xmpp.za.net/
>
> As far as I understand it XEP-0070 is for granting a user access to
> restricted resources on a /web host/ based on if they pass
> authentication with the jabber server. I'm actually interested in
> working in a way somewhat backwards to that. I want to grant a web
> server access to a users data on a jabber server if the jabber server
> authenticates the user.
>
> That is, I want to "authorize" the web server to act as an
> "authenticated" client for the user.
>
> And I /think/ that both 0101 and 0070 rely on a jabber browser plugin
> to do the authentication over sasl.
>
> Both of those restrictions make their use implausible on the web
> today. Rather I'm proposing a purely http workflow similar to OAuth
> (http://oauth.net/) that would allow anyone to tie into the jabber
> resources on the web in a secure fashion, without having to pass their
> credentials through an non-trusted service.
>
> ~ Anders
>
> >
> >
> > --
>
> >   /\_./o__ Tomasz Sterna
> >  (/^/(_^^'  Xiaoka.com
> > ._.(_.)_  XMPP: smoku at xiaoka.com
> >
> >
>


More information about the Standards mailing list