Re: token handling for the java social-api server

[Brian Eaton <be...@google.com>]

OK, I'll yell briefly.

Gadget Security Token: used for authentication between the container
and the rendering server.  Proprietary format that is not part of any
specification and never will be.  No keys are shared across
organizations.  All tokens are short lived.

OAuth tokens: used by the OAuth spec to convey both authentication and
authorization information.  Must be transferred in the specific manner
defined by the OAuth specification. Complex key distribution problems.
 Tokens are long lived (years is not a stretch.)

Sorry for the short e-mail, I'll be happy to be more verbose once I'm
back in town.  Just wanted to clarify that the only things the two
tokens have in common are that they are both called "token".

Cheers,
Brian

On Wed, Apr 30, 2008 at 3:02 PM, Kevin Brown <et...@google.com> wrote:
> From what I understand about OAuth (and Brian or Dirk can yell at me if I'm
> giving out misinformation), I think we can just wire up an abstraction
> covering both types of tokens, and no additional work is necessary to make
> the existing stuff work.
>
> On Wed, Apr 30, 2008 at 11:45 AM, David Primmer <da...@gmail.com>
>
> wrote:
>
> > Thanks for the clarification. I'd assumed we needed an Oauth SP for
> > the api server. I'll probably look to pulling in the oauth.net sample
> > code for the time being. I'm familiar with OAuth and how it's used in
> > shindig. Brian's post from last Friday being a good summary.
> >
> > What I wasn't so sure about was the use case overlap of the Gadget
> > Token and the Oauth token. If you search for 'token' in the gadgets
> > project, it's hard to sort out the differences between the oauth
> > tokens and the gadget tokens. Sometimes the gadget tokens are referred
> > to as 'auth tokens' and it's all rather confusing if you're just
> > coming upon it. Are there docs that explain what tokens are used when?
> >
> > For example OAuthStore.TokenKey seems to have many of the same fields
> > as the GadgetToken. I'm pretty sure they don't overlap but it is
> > confusing from the perspective of the api server, which to use.
> >
> > Did I just miss the emails where all this was explained? I wasn't
> > paying total attention at the time.
> >
> > Anyone have a preference for which is implemented first? I'd lean
> > toward Oauth support since that's more natural for the api server and
> > the GadgetDataServer already handles the one kind of token.
> >
> > davep
> >
> > On Wed, Apr 30, 2008 at 2:56 AM, Kevin Brown <et...@google.com> wrote:
> > > On Wed, Apr 30, 2008 at 2:22 AM, Cassie <do...@apache.org> wrote:
> > >
> > >  > This should be fairly straightforward as you can just look at what
> > the
> > >  > current json social code is doing. In GadgetDataServlet it grabs the
> > >  > security token "st" from the url, parses it and then passes the
> > gadget
> > >  > token
> > >  > around to all of the interfaces and such.
> > >  >
> > >  > You should be able to do exactly the same thing.
> > >  > This does mean that users will have to pass in st=xxx and I don't
> > know how
> > >  > that works when third party servers call you... it'll be easy for my
> > js
> > >  > restful code though :)
> > >
> > >
> > >  That's only half of the story (the opensocial-0.x feature using the
> > RESTful
> > >  API). The other half is the external usage of the APIs, which is based
> > on
> > >  OAuth.
> > >
> > >  Right now, OAuth is only used for calls from container -> service
> > provider.
> > >  What you need is for Shindig to also be a RESTful service provider. It
> > was
> > >  never clear to me how this fit into the spec, but I'm going to assume
> > that
> > >  it's already been covered and we don't have t othink about it.
> > >
> > >  I assume we can reuse the container -> service provider code for the
> > most
> > >  part. We still need to migrate org.apache.shindig.gadgets.oauth from
> > gadgets
> > >  to common, though.
> > >
> > >
> > >
> > >
> > >  >
> > >  > I hope that helps.
> > >  >
> > >  > - Cassie
> > >  >
> > >  >
> > >  > On Tue, Apr 29, 2008 at 11:16 PM, David Primmer <
> > david.primmer@gmail.com>
> > >  > wrote:
> > >  >
> > >  > > I'm curious how I can start to implement the handling of the tokens
> > >  > > used in opensocial for the rest server. Do we have social token and
> > >  > > oauth token? Maybe Brian or Louis can chime in here?
> > >  > >
> > >  > > Can I get a pointer to how to get going? Our server framework has
> > >  > > methods for getting the user and other parameters from the context
> > and
> > >  > > we'd like to use this to help with the processing of the requests
> > that
> > >  > > take the auth context into account. I'm assuming we'll share what's
> > >  > > already in use.
> > >  > >
> > >  > > davep
> > >  > >
> > >  >
> > >
> >
>