Develop Reference

standard way to handle user session in tornado

So, in order to avoid the "no one best answer" problem, I'm going to ask, not for the best way, but the standard or most common way to handle sessions when using the Tornado framework. That is, if we're not using 3rd party authentication (OAuth, etc.), but rather we have want to have our own Users table with secure cookies in the browser but most of the session info stored on the server, what is the most common way of doing this? I have seen some people using Redis, some people using their normal database (MySQL or Postgres or whatever), some people using memcached.
The application I'm working on won't have millions of users at a time, or probably even thousands. It will need to eventually get some moderately complex authorization scheme, though. What I'm looking for is to make sure we don't do something "weird" that goes down a different path than the general Tornado community, since authentication and authorization, while it is something we need, isn't something that is at the core of our product and so isn't where we should be differentiating ourselves. So, we're looking for what most people (who use Tornado) are doing in this respect, hence I think it's a question with (in theory) an objectively true answer.
The ideal answer would point to example code, of course.

Here's how it seems other micro frameworks handle sessions (CherryPy, Flask for example):
Create a table holding session_id and whatever other fields you'll want to track on a per session basis. Some frameworks will allow you to just store this info in a file on a per user basis, or will just store things directly in memory. If your application is small enough, you may consider those options as well, but a database should be simpler to implement on your own.
When a request is received (RequestHandler initialize() function I think?) and there is no session_id cookie, set a secure session-id using a random generator. I don't have much experience with Tornado, but it looks like setting a secure cookie should be useful for this. Store that session_id and associated info in your session table. Note that EVERY user will have a session, even those not logged in. When a user logs in, you'll want to attach their status as logged in (and their username/user_id, etc) to their session.
In your RequestHandler initialize function, if there is a session_id cookie, read in what ever session info you need from the DB and perhaps create your own Session object to populate and store as a member variable of that request handler.
Keep in mind sessions should expire after a certain amount of inactivity, so you'll want to check for that as well. If you want a "remember me" type log in situation, you'll have to use a secure cookie to signal that (read up on this at OWASP to make sure it's as secure as possible, thought again it looks like Tornado's secure_cookie might help with that), and upon receiving a timed out session you can re-authenticate a new user by creating a new session and transferring whatever associated info into it from the old one.

Tornado designed to be stateless and don't have session support out of the box.
Use secure cookies to store sensitive information like user_id.
Use standard cookies to store not critical information.
For storing large objects - use standard scheme - MySQL + memcache.

The key issue with sessions is not where to store them, is to how to expire them intelligently. Regardless of where sessions are stored, as long as the number of stored sessions is reasonable (i.e. only active sessions plus some surplus are stored), all this data is going to fit in RAM and be served fast. If there is a lot of old junk you may expect unpredictable delays (the need to hit the disk to load the session).

There isn't anything built directly into Tornado for this purpose. As others have commented already, Tornado is designed to be a very fast async framework. It is lean by design. However, it is possible to hook in your own session management capability. You need to add a preamble section to each handler that would create or grab a session container. You will need to store the session ID in a cookie. If you are not strictly HTTPS then you will want to use a secure cookie. The session persistence can be any technology of your choosing such as Redis, Postgres, MySQL, a file store, etc...
There is a Github project that provides session management for Tornado. Even if you decide not to use it, it can provide insight into how to structure your own session management. The Github project is called dustdevil. Full disclosure - we created this several years ago but find it very easy to use and have it in active use today.

Authenticated session handover

I'm planning to build a web app ("my app") which is accessed by users already logged into another web app run by the customer ("their app"). The goal is that users don't have to re-authenticate (re-enter their passwords into my app), rather their app should pass some information to my app that I can use to validate the user.
I know I could cook something up, like passing the user ID signed with a pre-shared secret key and some salt, but I was wondering whether there's an existing scheme or library for this use case. My app will be in Python, both apps run on different machines under different domains, and I'd like to keep required changes to their app to a minimum.

I believe the most popular protocol for this sort of deal is OAuth. There's a Python library for it as well.

SAML is another standard for SSO between disparate websites (e.g. different domains). Ping the customer to see if they already have support for it. If so, the Wikipedia page is a good place to start to gain a footing. Also check out this previous thread on Stack Overflow

Flask user authentication

I have an application that will use flask and mongodb; I will probably host it on rackspace.
I need to understand how flask authenticating works. I have not found much information on the subject. Is there a complete tutorial on how to roll your own solution? If not, I certainly would like to hear some thoughts on how you would approach it for a a flask app.
Big PS:
I just thought about it. I also need to open a real API. A part of that API will be used for AJAX on the front end. How do i secure that part of the app?
Can anyone explain API auth requests?

I would suggest using the flask-login extension, it makes session management really easy to add to your flask application, and provides a nice documentation which covers in details every aspect of the extension.

I don't think that flask has any authentication built-in, only support for tracking sessions.
Here are some snippets for basic HTTP authentication and authentication with some third-party providers. Otherwise you will need to roll your own or use a framework that has this baked in (like Django)
Here is a discussion thread on this topic with a useful link

Flask-Login doesn't, technically, do authentication - it does session management, leaving the (tricky to securely implement) authentication details to you. Something like Flask-Security actually implements both session management and authentication (also nice-to-haves like password recovery/reset and the like), at the cost of having to have explicit support for your database.

handling manual user creation with get_current_user() (GAE)

I am using GAE's Python environment and Janrain in order to provide multiple ways to login in my service.
Based on login information I receive from Janrain, I create a google.appengine.api.User object and store it to the datastore. Is there a way to handle this new object with the built-in get_current_user()? I need to be able to determine whether the requester is logged in or not and who the user is.

No, you cannot use your custom user objects with the native GAE Users API.
You could use a sessions library to track whether or not the request is coming from a logged in user (and who that user is). I recommend gae-sessions. The source includes a demo which shows how to integrate the sessions library with Janrain/RPX.
Disclaimer: I wrote gae-sessions, but for an informative comparison of it with alternatives, read this article.

OpenID or Auth in Django?

What are the pros and cons of using open id vs auth? Shoud I do both?

That depends whether you want to support Open ID. As to the reasons behind Open ID, in my view the most compelling one is that it avoids requiring your users to have an account just for your site, with all the hassle that involves (yet another username and password to remember).
If you decide you want to use Open ID, there's not need to choose between that and auth - use django-openid-auth, which adds Open ID support to the auth framework.
Definitely try and avoid using an Open ID implementation that doesn't plug into Django's auth framework - you'll lose a lot of the baked-in goodness of Django (model-level permissions etc).

OpenID and OAuth do different things. OpenID lets users log into your site. OAuth lets people give your site access to their data elsewhere. On the other side of the coin, OAuth gives you a secure way to let users access their data in your service from elsewhere.
If you implement OpenID, don't implement an OpenID producer. Everyone's already got an OpenID, whether they know it or not. Just consume openids from elsewhere. Migrating OpenIDs shouldn't be hard. Just make sure that a user account can connect via multiple OIDs, then they can add new ones as needed, and remove when they're done with them.
Edit: Just saw that you were talking about django auth, not oauth. Oops. The second paragraph still stands.