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?
If the token expires would I just lookup which user has that token then update it?
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:
When the user visits your site you set a session cookie with some random string we call state.
The user clicks on 'Sign In with YouTube'
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.
You redirect the user to YouTube with the request token (and optionally the encrypted request token secret cookie)
The user logs into YouTube, approves the application, then gets redirected back
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.
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
Using the access token, make a YouTube API call to get the user information
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.
Related
I am not clear on what exactly I should do with the id token from Google after the initial verification.
I'm developing on expo/react native and get the id token locally. Then, I send it to my server and verify it using google client libraries. Once it's verified what should I do with it?
Ideally I could use it to protect my api routes (express) but id tokens expire after 1 hour and I'm not sure how to refresh them with the client library. So, I don't know how I would do this.
Is that the intended use for id tokens? Should I instead be signing my own jwt and sending that back to the client? Then, the client could send that in the auth header of each request to a protected routes.
Google says:
After you have verified the token, check if the user is already in your user database. If so, establish an authenticated session for the user. If the user isn't yet in your user database, create a new user record from the information in the ID token payload, and establish a session for the user. You can prompt the user for any additional profile information you require when you detect a newly created user in your app.
https://developers.google.com/identity/sign-in/ios/backend-auth
Do I use the id token to "establish a session for the user"?
Yes, the ID-token is only used to create the local session, perhaps also create a local entry in your local database if that is used.
The ID token also have a very short lifetime, like 5 minutes in some systems. So it has no long-term use.
The ID token is intended to authenticate the user. It gives you information about the authenticated user, it should not be used to allow access to your endpoints. Access tokens or sessions are intended to do so. So in your case, you should do exactly as your gut feeling tells you - create a session for the user basing on the data you got in the ID token.
If you have your own Authorization Server you can use the ID token to issue an access token and return the token to the frontend app, then use the access token to access your backends. Have a look at OAuth flows if you would want to go this way.
How to correctly implement abstract getUserId(request) method in these Google OAuth2 abstract servlets?
As code says, it is used to lookup and store google credential. I've seen example which returns session id, but that won't work correctly after session expiration:
User visits auth url, his access and refresh token are stored in storage under sessionId key
Within session lifetime, everythings works fine, so if this user visits auth url again, his stored tokens are found with the same sessionId key
But after session expiration (server restart etc) when this user visits auth url again, he gets new sessionId, no stored tokens are found, so new tokens (this time only access token) are requested and stored again under new sessionId key
So the question is - how to generate userId that will work in all cases? GoogleAppEngine implementation uses logged user, which is perfectly fine - but how do I generate such userId from just HttpRequest parameter?
BTW this (https://developers.google.com/gmail/api/auth/web-server) python implementation seems to generates parallel userinfo request to get user email manually...
First, make sure you need offline access to the user's credentials.
The reason all of these examples you cite use logged in user is because the user id is necessary to store the credentials against the correct user in the credential store.
In those use cases, Google OAuth is used to authorize the web server to undertake some action in the user's Google account.
One idea for user id to create a long lived coookie (using secure random generator) and use that to identify the user, so you know who they are when the visit the site again, and can reuse the credential (if you asked for offline access). This is not very robust, as the user can clear their cookies, but there is no other way short of logging the user in.
(Yes, Google Oauth can be used to log in the user, but you are still looking at a sending the user to Google every time, so you really gain nothing by doing that).
I'm building an iOS app that will use instagram photos in a slide show as the background of the app.
What I want to do is just set up a specific account that I can upload pictures to, and then the app will pull in the most recent photos from this account.
So far, I've set up the account and have been able to generate an access token manually by inserting my client id and redirect URI into this URL
https://instagram.com/oauth/authorize/?client_id=[CLIENT_ID]&redirect_uri=[REDIRECT_URI]&response_type=code
However, I've read that the access token generated from following this procedure is not permanent. I do not want the users of my app to ever see the authentication going on in the background. They themselves will never actually login into Instagram.
What would be the best way of making sure my app is always authenticated at launch and that the access token is always valid?
Thanks
A typical OAuth flow has the resource owner (a user) approve or deny requests from a client application. When you first got an access token, you had to complete a form approving access to Intsagram by your app.
Since you want to hide the auth_server/resource_owner interaction from your end users, you'll have to automate the role of the resource owner. The access token should tell you when it expires. Since it's your redirection endpoint that has the access token, that's where you'll need code to detect the token will soon expire and request a new one. Your code will need to
Simulate a request from the client app by going to https://api.instagram.com/oauth/authorize/?client_id=CLIENT-ID&redirect_uri=REDIRECT-URI&response_type=code
Respond to the HTML page that is returned. Approve the request.
The server will respond with an authorization code that you can exchange for
a new access token.
There are some hoops to jump through because OAuth is designed for the resource owner to approve or deny each request.
I don't think you would want to do this by logging into the target account because having your app's user log in to Instagram as the account you are talking about may be unnecessary.
While I am not an expert on the Instagram API, it looks like you can avoid using an access token for getting the feed of a particular user.
Here is some support for this:
Do you need to authenticate?
For the most part, Instagram’s API only requires the use of a client_id. A client_id simply associates your server, script, or program with a specific application. However, some requests require authentication - specifically requests made on behalf of a user. Authenticated requests require an access_token. These tokens are unique to a user and should be stored securely. Access tokens may expire at any time in the future.
http://instagram.com/developer/authentication/
If a client ID is only associated with your application and does not require the user to authenticate, it appears that this endpoint should work:
GET /users/user-id/media/recent
https://api.instagram.com/v1/users/3/media/recent/?client_id=YOUR-CLIENT_ID
The functionality is the same with the previous one, but use client_id
instead of access_token
PARAMETERS
COUNT Count of media to return.
MAX_TIMESTAMP Return media before this UNIX timestamp.
MIN_TIMESTAMP Return media after this UNIX timestamp.
MIN_ID Return media later than this min_id. CLIENT_ID A valid client id.
MAX_ID Return media earlier than this max_id.
http://instagram.com/developer/endpoints/users/#get_users_media_recent_with_client_id
I am trying to impliment Oauth for my webapplication for google.I am worked upon a POC and it working fine but i have a confusion and not sure how best it can be achieved.
I am using scribe java API for Oauth.
here are the steps i am performing.
Getting request token from Google.
Redirecting user to Google to authenticate them self and authorize my serivice to access his/her few details.
get Access Toekn from google by providing request token and verification code given by google.
Accessing user info once google provide Access token.
now my main confusion is at step no 3, since i am working on a web-application so it will be a 2 step process.
Redirecting user to google
Handling back google redirect.
In order to get an Access token i need to provide same request token which i got at step1 else my request being rejected by the user.
The request token contains 2 things
Toekn -->which is based on the registered application so not an issue
Secret-->This is always being a random string so it should be same when asking for access token
that means i need to store this secret either in my session or some where so that i can access this secret when user is being redirected back to my application.
My confusion is,since in order to save it in session i have to create a unique key and some way to access it in the other action class which will handle Google Redirect back how can i achieve this since at a given time so many user can ask to login using google.
any help in this regard will be much appriciated.
Thanks in advance
When you receive the request token + token secret, use the request token as the unique key of your session to store the token information. After the authorization process, in the callback url, you have access to the request token (it's one of the parameters passed to the callback url). Using this parameter as the session key, you can restore the token information from session, including the token secret, and use it to sign your request for changing the request token for access token. After receiving the access token, a new token secret is returned to you and you can delete the old one from session.
how can i achieve this since at a given time so many user can ask to
login using google
This is not of any problem because for every single user on your site, you are given a different request token.
I have a Twitter web app that allows users to submit tweets from my site. However they have to re-login every time they submit a new tweet. Is there a way to save the OAuth session and don't prompt the login screen until users clear their browser cache?
When you get the callback from Twitter after the user has validated you, you'll receive an auth_token in the headers of the request; you're meant to cache that token, and supply it every time the user makes a request.
It sounds like you're not caching that token and supplying it when the user makes a request.
You need to store the oauth_token, you can use the same for all requests.
On the FAQ of Twitter API
How long does an access token last?
We do not currently expire access
tokens. Your access token will be
invalid if a user explicitly rejects
your application from their settings
or if a Twitter admin suspends your
application. If your application is
suspended there will be a note on your
application page saying that it has
been suspended.
you need a db tables called user and user_tokens. Inside the user you have: id, user_oauth_secret, user_oauth_token. Inside the the user_token you need this columns: id, user_id, token, created, expires. make sure this token is unique (and long) with some random hash. now you can save this token to the user's cookie and find the right oauth data later.
You need to store two tokens.
When you make the OAuth request the first time, it will show the Twitter auth screen. After auth, your OAuth callback page will get two query string parameters, "oauth_token" and "oauth_token_secret" for the user. You need to store these (probably in a database) somewhere.
Then, when you request OAuth permission again from Twitter, send the two tokens, and the user will automatically be authorized.
You shouldn't have to code this yourself. There are plenty of OAuth libraries out there.
You have to maintain a long session with the user and save the access tokens. Cookies are commonly used to recognize users.