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.
