i've been doing this kind of thing for a while now. the original impetus was a quiz building tool. we wanted users to be able to build an online quiz/survey (similar to survey monkey) that could be tied in to other applications (potentially written in any language and running on any machine). so i set up little REST services. when a quiz is created, the author fills in urls for login, verification, etc. services with little placeholders for variables in the urls. when a user goes to the quiz, they get redirected to the login service, they login there, and it sends them back to the quiz app along with a ticketid and username. the quiz app will then, on each subsequent request, ask a verification service if that ticketid/username combo is valid on a backchannel. so now, if we have an application that could use a quiz but has its own notion of users and authentication, the developer on that app just sets up login and verification services against the app's user database, creates a quiz, and plugs those service urls into the quiz's configuration. then we also have a couple stock services that can be used (one that authenticates against the university's id system, a "public" one that essentially allows anyone in, one that checks that the IP address is on campus, etc.)
it was mostly just expanding on the ideas of the CAS single-signon system: http://www.yale.edu/tp/auth/cas10.html (actually, on WIND, which is Columbia's clone of CAS).
the really nice thing about building systems this way is the complete flexibility of policy. if someone comes up with some crazy new authentication system that i couldn't have thought up, the quiz tool can still use it as long as they can encapsulate it in a couple simple services.