A follow up to Peter's earlier question (from January) that Michael Hermanto partially answered, but I think there is still an unanswered question and I'm in the same boat right now.

http://markmail.org/message/kjsk6qdrjleomgsp

I understand the security token the gadget uses (the one returned on the iframe url) is auto-refreshed when using the common-container. However, I think the other part of Peter's question was that the rpc transport uses the security token from shindig.auth and not the one from the gadget. So how do you rectify this?

My understanding is that my container will generate a security token that will be used by the rpc json requests required to get the gadget setup (by calling shindig.auth.updateSecurityToken). Once the gadget is setup it will use it's security token (different from the container one) that is returned on the metadata response (st) to make it's requests. Gadgets SHOULD NOT call shindig.auth.getSecurityToken()) is my understanding. That's a container concept.

Any understanding on the Security Token flow is welcome. I asked a previous question

http://markmail.org/message/5c2jcgnnhaxic7uk

and I appreciate Augustin's response about not confusing all this with oauth and Justin's response about how they implemented security tokens within their authenticated server. I am somewhat confused as to how the token is secure (even if encrypted), since it can be sniffed and replayed by someone else to make destructive rpc calls. Unless just the expiration timeout of the token is enough.

But I still feel like I am missing something here.

Thanks,

Doug