OAuth Tokens: What can I link up to a user table?

I'm developing a YouTube application that needs to have a User table with the usual data associated with it in the database. I've decided to go the OAuth route for this application and have 2 tables, one of the AccessToken and one of the RequestToken.

开发者_如何转开发

I'm not sure what is to be linked up to a User table of some sort, would it be the access token or the request token?

1. If the token expires would I just lookup which user has that token then update it?
2. To sign the user out do I just delete the token for the user and clear the token from the session?

EDIT: In other words, I basically want a user to not have to register to my site but to just login via OAuth and have my application create a user entry in the User table so all of my other data can be linked up to that.

---

There are two parts to this: login and resources.

If you only want to use YouTube for login, you don't need to store the access token at all. When the user comes back from YouTube with the access token, you make one call to get their YouTube id (not sure if YouTube supports an extension parameter with the id in the token response) and discard the access token. If you also want to make other calls to access the user's YouTube data, you need to keep the access token.

A common way to implement this is:

1. When the user visits your site you set a session cookie with some random string we call state.
2. The user clicks on 'Sign In with YouTube'
3. You go and get a request token from YouTube, then either store it in some local cache (can be a database, redis, memory if this is a small scale app, memcache, etc.) or encrypt it and store it in another cookie on the client. When you make the request token call, include a 'state' parameter in the callback with the value set as cookie in #1. This is a critical security defense against CSRF. Also, your redirection endpoint should use SSL.
4. You redirect the user to YouTube with the request token (and optionally the encrypted request token secret cookie)
5. The user logs into YouTube, approves the application, then gets redirected back
6. You check that the user coming back to the redirection endpoint matches the user you originally sent over by comparing the value of the incoming state parameter with that of the session cookie from the user.
7. Fetch the request token secret from local cache or by decrypting the token secret cookie used earlier (which ever method you decided to use) and request an access token
8. Using the access token, make a YouTube API call to get the user information
9. Lookup in your database to see if you already have a user with that YouTube id. If you do, this is just a login, and if not, this is a new user registration so create a new record for them in your users table.