[Standards] oauth and xmpp server responsibility

Jason jeacott at hardlight.com.au
Tue Nov 3 01:39:40 UTC 2009


Hi all,
    I've returned to this because my usecase seems to warrant some 
ownership by the server.

in my setup I have an xmpp component acting as my server application.
each server maintains data for the users on that server.
but 'users' never log in directly to these servers, but always via some 
3rd party application which connects as a simple xmpp client and makes 
oauth requests on behalf of users.
so user->http etc->3rdpartyapp->xmpp client->somexmppserver->needs to 
route the message to the appropriate server based on the oauth user.

since the users all have real xmpp addresses, it seems it could be a 
reasonable to have the xmpp server itself accept the oauth request 
(instead of my server component) and vet it against data that could be 
stored in users private storage (or a new xep just for auth keys & 
permission option storage and matching).
If this were in place then any individual (or app with suitable oauth 
permission) could save tokens & permission data to a users private 
storage. Then an app with granted authority could send an oauth message, 
which would be vetted and forwarded to the users own xmpp server for 
processing (or sending again if its a message to elsewhere I guess).
The forwarded message should have a new xml fragment included to 
indicate the original sender, and the various tokens that were included.

of course this is all doable with custom components for everything, but 
why not allow developers to actually use all of the existing xmpp 
infrastructure and any custom apps, via oauth without having to reinvent 
everything.

One last thing. the existing oauth spec doesnt support the idea that a 
message may need to carry nested authorities (or messages with 
authorities).
If I have a proxy setup something like user->serverapp1->mule 
ESB->serverapp2
where muleESB is acting as a proxy for messages from app1 to app2, but 
it has its own xmpp identity> Then to avoid mule needing to check 
authorities itself, 'app1 oauth user' needs to be wrapped by mule and a 
new auth added for 'mule oauth app1'. I dont know how this should best 
be done. If the existing oauth xml spec allowed for arbitrary stanza 
subelements then a sensible nesting of messages could be sent and 
processed without the need to change architectures or create other 
custom message formats & workarounds.

Thoughts?
thanks
Jason.









More information about the Standards mailing list