I have authorised multiple accounts via Google's OAuth2. How do I get a list of accounts that I have authorised? I want to be able to revoke access.
To make it clearer, I go through the OAuth2 flow multiple times, each time selecting a different account. Then, I get the access/refresh token and save it to my database. By doing that, I noticed that I still get access to resources not tied to the latest account but also those that are tied to previously authorised accounts. I want to be able to list and allow my users to revoke access to these accounts.
There is no way to get a list of the users who have authenticated your application. I have this problems as well because I have a number of users who are still using a very old version of my application who i would like to inform them they should upgrade but i cant as i have no contact to them.
Revoking access of known users:
Your application can have as many users as you want authorized to it. The refresh token gives you access to each of the users data. The access will remain until the user revokes it or the refresh token hasn't been used for six months.
You can revoke it programmaticly by revoking the token
Try using:
$client->revokeToken();
This should revoke the old access given by a user. You will have to load the old refresh token into the client of course.
Related
I am using Google Calendar API to have offline access to user calendars.
So when a user first authenticates the app, I am given a refresh token.
On subsequent accesses, no refresh token is given.
So in order to keep these, I am storing the refresh token against my own database user table. So I know when a particular user of the site is logged in, that the Google refresh token is $refresh
This works just fine when the user only uses 1 Google account, but if they authenticate the app across multiple Google accounts. There are multiple refresh tokens, but on my database side, I am storing just one.
So the first thing to do was to store all refresh tokens, tying them all to the single website user.
But even still this is incorrect, When granting access to a specific calendar, I won't know what Google account that particular calendar is associated with. (unless I am missing something)
So when they grant access to a calendar, all I have to go with, is what user was signed into my website.
So if someone grants access to say 2 calendars, which are in 2 different Google accounts, but both tied to the one website user. How can I know which Google account was used for which calendar?
Without knowing that info, the refresh token is going to fail until I pick the right refresh token. Which would have to be done by cycling though the refresh tokens until one works.
Is there some way to store something that would help me know which refresh token is tied to each calendar (rather than only tying it to a website user) they have authenticated?
Or is my methodology wrong in the way I am storing the data, and there is a better way to store this info that makes better sense.
A refresh token is obtained in offline scenarios during the first authorization code exchange. Even though user has multiple accounts, refresh token is generated for each google account(even users are same).
Also, when you are storing the refresh token in your database store refresh token along with the user ID(google account id) and calendar ID(even though both ID's are same but in few scenarios, each user can have multiple calendars).
What I'm trying to do is basically have a system that allows people to post to Tumblr via this website using Tumblr's API. I think it would work something like:
Get the user to grant our application permission on Tumblr; get the token and secret from Tumblr.
If this user has never authenticated before, store the OAuth token, OAuth secret, and the user those belong to in a database.
If the user has authenticated before, check the OAuth token and secret that Tumblr just gave us against the ones already stored in the database to re-authenticate this user.
So, do I need to re-authenticate with OAuth on every single page? Or in other words, I need to contact Tumblr every time the user loads a page to make sure they're still the person they say they are?
I have a php app where my registered users login to facebook. I use $facebook->getLogoutUrl();. Then I retieve all their albums and display their id and names in an HTML select tag. The user select one and the id of the album is stored in the DB.
Here everything works great.
Then an anonymous user visit my website and I want him to see my registered user photos (public photos of the albums selected by the registered users) (they are not logged in my site, they are not logged in facebook). At the moment it only works if the anonymous user is logged in facebook. But I want to diplay photos even if the anon is not logged in facebook.
$photos = $facebook->api('/'.$idAlbum.'?fields=id,name,link,photos.fields(id,picture,source)');
I have tried a lot for 2 weeks but nothing seems to work. I have tried without login, I have tried with an app access token, I have tried:
https://graph.facebook.com/oauth/access_token?client_id=XXXXXX&client_secret=YYYYYY&grant_type=client_credentials
Can anyone help me? or tell me if is not possible to my app to retireve photos from an album. I searched a way to login my app but I only find app access token (https://developers.facebook.com/docs/howtos/login/login-as-app/) but as it say it can make requests as the app, not as a user
In order to access a users information, you're going to need a valid access token for that user. An application access token can't be used to do anything on behalf of a user.
Access tokens expire after a while and that prevents applications from searching though the users information when the user is not actually using the application.
If you want to go all the way - just download all the photo's from the album and store them on your server... If you can't do that, then you'll have to look into extending the album owner's access token so that you can use it when querying their album. As far as the application is considered, with that extended access token, it is in actual fact the album owner who is making the request.
Taken from the Facebook docs:
Extending client-side user access tokens
When a person completes a client-side auth flow and you retrieve their
user access token, by default the token is only valid for one to two
hours.
You can exchange this token for a longer-lived one that's valid for up
to 60 days by passing it to the /oauth endpoint from your server with
a grant_type parameter of fb_exchange_token. [Note that it must be
sent from the server so that the App Secret is not exposed.] Here's
what that looks like:
https://graph.facebook.com/oauth/access_token?
grant_type=fb_exchange_token&
client_id=APP_ID&
client_secret=APP_SECRET&
fb_exchange_token=SHORT_LIVED_ACCESS_TOKEN
The response from this endpoint will include the long-lived access token. This will be a
different string to the original token, so if you're storing these
tokens, replace the old one.
Basically you'll have to do this as soon as any (registered) user performs a succesful login and store the token in your database.
I have been doing research on this Oauth concept and I am still very confused about this concept. One of my main questions is how does one register with a google account or a twitter account.
For example, lets say in order to register to my website, you must provide a Username/Password/Email/GroupName. If you register through my website, than you can provide those fields very easily. However let's say the user wants to register through google. How would those fields populate?
From my understanding once you register with your google credentials, you are redirected to a page on my website where you fill in the required fields. I am not sure if this is correct. Can anyone help me understand this more?
Basically OAuth works like this (depending on the version these points consist of multiple steps):
You redirect the user to a provider, where he logs in
The user is redirected back to you and you receive an access token
Using this access token you can then request the users data from the provider. Typically the providers provide a call which you can use to ask for the user's email address, full name and a (provider-specific) user id, but that is not part of OAuth.
How you now use this information to handle that user as if he logged in to your site is then completely on your own. You probably want to create a new user object on your side each time you see a new user id.
There are couple of basic concepts that needs some clarity before one can understand how a new user registration happens using OAuth2. These are:
Resource Owner (You, the human)
Identity Provider (Google, Facebook, Twitter, etc.)
Resource Server (Same as Identity provider, or some other service)
Resources (Things you want access to)
Client app (The app you are using to access those things)
For new user registration, you will follow the same sequence of client app requesting authorization to be granted access to the resources. This will trigger a login page, user logs in, authorization code is created (by the IdP) and sent back to the client app. The client app exchanges this code for an access token (some encryption signing is involved, read up the documentation - basically allowing client app to prove its own identify).
This access token is then used to request access to resources - in this case, the new user profile. This could be name, email, picture etc. Use this to create a new row in your client apps profile database. A new user account is created.
Then for subsequent logins, the client app will use this access token to validate its life with the Google Auth server - and then create a local session/cookie to login the user.
Hope this is clear.
I am using Oauth to create a way for users of our website to login
using their twitter account. However, It's quite annoying that
everytime they click to sign in with their twitter account they have
to grant access each and every time.
Couldn't it work so that if it has been granted once they don't have
to keep granting access? Therefore removing a step. I'm using the
steps found in:
http://net.tutsplus.com/tutorials/php/how-to-authenticate-users-with-twitter-oauth/
Thanks for any feedback!
I found the answer after talking to some developers on twitterapi irc
Bascially I was going to https://twitter.com/oauth/authorize with all my oauth, what I need to do was go to https://twitter.com/oauth/authenticate instead. That then gives forever authorization.
When the users connects, you receive an access token and a secret token, which are used every time you ask anything to the Twitter API.
If you wan't your users to stay connected to twitter, you only have to save in your database those two tokens. (They are user specific, don't use one token for every user).
When you know these tokens, you don't need to ask the user to grant access, you can directly use them to call the API.
If a user removes rights for your application, you won't be able to use his tokens any more, and you will have to ask him to grant access a new time.
You need to start the token / token secret you get in a database or other long term storage method. Then you pass it into the object that does the OAuth authentication so you don't have to keep asking your user. With PHP you can store them in a MySQL or similar database and load them into $_SESSION when the user logs in to pass the values.