There are ways to implement the OAuth SP that don't require the same server that serves resources to be the one taking credentials or delegation from the end user. The OAuth docs and the samples at OAuth.net tend to lump these together but this is not the way I see it happening at scale. The OAuth SP code in shindig right now does not have any of these UI components and if it ever does, they will probably be very simple examples. This has been discussed (using a SAML redirect in the middle of the OAuth flow) on the oauth google group a few times.
davep On Wed, Jul 23, 2008 at 3:12 PM, Hans Granqvist <[EMAIL PROTECTED]> wrote: > Hi all > > One of the things that excite me about the RESTful API of 0.8 is > that I can implement a headless service and in a sense outsource > all the webapp UI, gadget rendering, etc., to other services. > > It seems though that the spec(*) doesn't like that. From section 4: > > "Containers MUST be an OAuth Core 1.0 Service Provider (a > web application that allows access via OAuth)" > > Am I reading this wrong, or does this mean that there simply is no > way to implement the REST APIs without also implementing some > sort of UI rendering and redirect to obtain user authorization? > > I guess you can argue that if you're a Container, then, yes, you should > implement the UI, but in an ideal world, I'd like to set up just a web > service that responds to a fixed set of requests and not worry at all > about the hard part of gadget rendering, and rather put this onus on > the client. Is this a pipe dream? ;) Why should a primary server-to- > server REST API implementation have to deal with webapps? > > Thanks, > Hans > > (*) http://code.google.com/apis/opensocial/docs/0.8/restfulspec.html >
