gae channel token as general access token

Question

I have an Android app which communicates via channel and REST with the GAE server. Can I use the channel token as general access token like this:

1. client provides credentials to servlet
2. servlet creates channel and provides token
3. client does REST calls providing channel token as access token
4. other communication via channel

For 3 I would like to stay session free. So I would need to decrypt the client ID from the channel token. The client ID is probably encrypted into the token but I did not find any API call to extract it.

Is there any other API available to get the client ID for a channel token?

Otherwise I would need to maintain a mapping of channel token and client ID which reduces the value of the token. Would the memcache be the appropriate mechanism to maintain this mapping?

thx

Answer 1

This is an interesting concept. It could be made to work if you're careful.

For starters, this would only be safe if you transfer your token over HTTPS.

Tokens and channels time out, so you have to recreate your channel every so often.

Channels are a bit flaky over poor internet connections. If your lose your internet connection, sometimes the channel still works afterwards, sometimes you need to recreate it.

There's no way to validate or get your client ID via your access token. So to use this as security, you would have to NOT return any data to the original request, and just send data to the channel. Also, you'll need to store your own mapping between client ID and access token on the server. And keep in mind that it would be inaccurate since it's hard to tell on the server side whether a token has timed out. With most situations, if you actually need the data, memcache alone is not an appropriate mechanism, you'll want it to be backed by datastore in case memcache is flushed.

I think the biggest hassle with this is that you will manually need to associate your REST call requests with the data you get back later on the channel. You can probably do this easily enough with an incremental counter as an id, but you'll have to handle the cases where you don't get a reply and have to retry, etc. There's probably easier ways if you use a session id.