I am making an app for the iPhone were all the users have access to the same google drive folder for uploading files. This google drive account is managed by the company and not by the users. There for I want to skip the google login form and just give the user access. Ideal the user does not even know he/she is using google drive.
I looked at the drEdit example and looked at oauth documentation. Is it possible to use one refresh_token for all the users to grand access? So I login once, grand access, somehow store the refresh_token and hard code that in the app for future use, so that all the users use that refresh_token for access. Or are there better ideas to do this?
Kind regards,
Stijn
Thought there was a similar question to this, but can't find the one I'm looking for. Short answer is you need to be very careful how you do this. Embedding the refresh token in your app like that is inviting abuse, particularly if it is authorized for write access. Once a clever user or attacker finds that value, they can use that token to call the API however they want. If authorized for the full drive scope, that means that can also maliciously modify or delete files, secretly store their own content, etc...
If you really need to have anonymous or shared access to content stored in Drive, you're better off proxying requests through your own servers so you can control the interaction with Drive.
Related
I cannot find a good working sample that calls the Graph API and retrieves the user's contacts from within an Azure Function. Part of the issue is a lack of documentation and samples as this seems new-ish. Is this even possible? I am trying to create a function that can take a phone number and check against the user's contacts to see if the contact exists. So far, the only way I can achieve authentication is to use Postman to retrieve a token manually. That token didn't even work to retrieve the contacts. I know I am doing something wrong but I think what I really need is the big picture. I'm missing something. Thank you for your help.
The auth token binding may help at least with the act of getting the token. In this case, if it's on behalf of the user invoking the function, you'll want to use the identity: userFromRequest setup. Keep in mind that for debugging, you'd still have to acquire a user token for the app and attach that to calls to your function, but you can use the function app's /.auth/login/aad and /.auth/me endpoints for that.
Make sure that your application registration has the Contacts.Read permission. This is required for the contacts API.Today, the UX for App Service Authentication / Authorization today links to the existing permissions UX, which unfortunately uses different names for things. I'd recommend navigating directly to the AAD section of the portal and selecting App registrations (Preview). Find your app registration there (defaults to same as your app name), and browse through the API permissions there. That way the right names show up and will match the Graph docs.
I have about a site with about 50 customers. They each have a user profile. They want to be able to automatically include their images which they store on DropBox in their profiles.
My idea is to make a Dropbox api that scans their folders (with their permission) and just include the images in their profile. I already know how to link directly to their images as long as I have the url.
I set up the Ruby API. Only question is : Do they have to authorize my app every time I try to access their images?
I want to somehow store authorization information for each client, then just reuse that info and access their images through the Ruby API. Is this possible? How is it done?
I think if I can just get past this authorization hurdle I can take care of the rest.
You can definitely do this. Just store the access token at the end of the OAuth flow and reuse it. From https://www.dropbox.com/developers/core/start/ruby:
The access token is all you'll need to make API requests on behalf of
this user, so you should store it away for safe-keeping (even though
we don't for this tutorial). By storing the access token, you won't
need to go through these steps again unless the user reinstalls your
app or revokes access via the Dropbox website.
I am thinking to embed google calendar in my website to achieve the following and was wondering if this is doable in google calendar. Otherwise I have to go find another solution.
I have groups of users with one super user, and rest are regular users as follows:
GroupA
Super User 1
Regular User 1
Regular user 2
etc
Group B
Super User 2
Regular User 3
Regular User 4
etc
Each group have their own calendar. Users in each group can not see the other group's calendar. Only able to see their own group's calendar.
Super users of each group have all access to the calendar (add, modify, delete) and have the ability to control how much access regular users have in their group. (read only? read/write etc)
All users are registered to my website, therefore I am thinking to use only one google calendar account (my own account) to create a calendar for each group. Which leads to a question of authenticating my website to google's API. I need the authentication process to be automatic, hidden away from the user and be done on the server side.
My site is built using PHP/Mysql
Q1:
I have tried the Javascript client library provided by google, however it require the user to type in username/password to log into google so that the authentication (OAuth2) process can work. As mentioned in previous paragraph, I only want the user's to log into my website, they do not need to login again into google account. This should be done on serverside.
I even went as far to create a login form with information prepopulated (hidden from the user, the username/password will be visible in "view page source") and send the request to https://accounts.google.com/ServiceLoginAuth, and make the form automatic submit once the user successfully login into my website. However this causes cross domain issues.
Q2:
I may potentially have 10's of thousands of groups registered on my website. each group may have couple hundred users. Can one single google account create that many calendars?
Q3:
Once the calendar is embedded into my website, it seems to be read-only. Is it possible to make it interactive so super users in each group can add/delete/modify events?
Any ideas/suggestions is much appreciated.
Thank you
No answers? It seems like your question is straightforward. If I understand correctly, you want to access calendars from several Google accounts/users. Each user needs to authorize this access, but they only need to do so once. You could generate these requests and send them out via email, for example. When the user grants permission, Google forwards a grant code to your specified callback_uri. The grant code is extremely volatile. It's used to request a token from Google that apparently lasts indefinitely. So there's no requirement that users continually log into Google.
In Google's calendar/simple.php example. The token is stored as a SESSION variable. Even though the token is persistent, the SESSION variable is not. Users have to grant authorization every time the SESSION variable expires. Storing persistent data in a volatile variable is absurd and probably gives the wrong impression about the OAuth2 token mechanism.
I spent a lot of time writing documentation that I couldn't find anywhere else. Please take a look if you think it might help: http://www.tqis.com/eloquency/googlecalendar.htm
What you're asking isn't possible in Google Calendar.
If you're looking to support thousands of groups and each group needs it's own calendar, then you're saying that you'd need thousands of calendars with access control and you'd need authentication to the calendar to be transparent.
This is a very high level question, to a high level answer too, so I'm just looking for some pointers on the right direction.
Let's say I want to build a web application to manage a user's Google Contacts. I understand this is done by allowing the user to log in with his Google Account while asking for permissions to manage his Google Contacts. So far so good.
Now I want to expose my own API layer for external browser extensions, Android clients, etc. But while I want the API clients to authenticate against Google, I don't want the applications to have full access to the user's Calendar, as the Secret Token is stored on the server.
So, how is this typically handled? I would like to do it by the book as much as possible, without having to implement a lot of security code.
Btw, while the question is too high level, feel free to point me to technical docs.
Thanks
Limited access to the user's resources can only be guaranteed by limited OAuth scopes:
https://developers.google.com/gdata/docs/auth/oauth#Scope
Some APIs, for instance the Contacts API, only provide a single scope which gives you access to all the data. In cases like this, the user can only choose between giving you access to all his contacts or none of them.
Other APIs expose different OAuth scopes, allowing the developers to only request access to a subset of the user's data. A good example of this is the Google Drive API, which has 5 different scopes for the developer to choose from:
https://developers.google.com/drive/scopes
I asked various questions about my problem (here and here) and I also asked in the #oauth & #openid freenode's channel on IRC. (this is note an "UP" question, it's an other problem)
I'll sum up my project configuration : Anyone will have the possibility to create an app that can use my API. To start, I'll work on my API and a Web based app, but the documentation about the API will be public. It's a bit like Twitter API.
The problem I face is how can I be sure which user is using the API (to retrieve his personal data, like your tweets), even if the User is using an app that I don't know who make it (again, like twitter and all the apps around).
I googled a lot and with the help of the previous answers given, I took a look at OAuth.
As far as I understood the way OAuth works, here how :
A user visit an app that use my API (web, mobile, whatever)
The apps redirect the user to the API for the authentication (I'll use OpenId) and the authorization (OAuth). This is a bit odd since the API will have a web interface for the login and the authorization (I suppose this is how it works since Twitter do that)
The API redirect the connected user to the app, with some tokens. In these tokens, there is a token representing the user that the app must store in order to indicate to the API which user is using it currently (Am I correct?)
So far, everything goes well. But what I can't figure it out, is when the user quit the app and goes again : how the app can remember the user is the one that used it before ?
(Before some of you bring me the cookie answer, I'll remark this is a simple example, it would be the same if the user clear his cookies, format his computer or change its computer.)
The only solution I can find, is when an unauthenticated user (without a remembering cookie for example) goes to the app, the app redirect him again to the API to authenticate himself, but this time, the user won't have to re-allow the app (authorization) since it already did it. The API will then return the user to the app to allow him to play with this.
Is this the proper & secure way to do it ?
The #OAuth IRC channel told me about the new protocol, WebID, but this is currently in pre-draft mode and I don't want to use something that will change continuously in the future :/
Thank you very much for your help!
Short answer: OAuth results in an authenticated access token. That access token is tied to ONE user. And as long as the access token is valid. The third application can do whatever the API allows the access token to do.
Long answer:
The thing with OAuth is that it does not "Log in" a user. OAuth gives third party applications what is called access tokens which can be used to access data on behalf of a user whether he/she is logged in or not.
Many services restrict their access tokens. Twitter for example issues two types of access tokens, read-only, and read/write. But there is no concept of logging in to use APIs. While an access token is valid, a third party application can access the user's data, and change things without a user's explicit interaction.
Most API providers have functionality to revoke access tokens. That is what happens when you in twitter look at your Connections page . See the revoke access links?
Personally I love the OAuth approach. As an API provider, you can control what access tokens are allowed to do, and the user can kill bad applications from using his/her resources. OAuth is secure as far as authentication goes. Third party applications do not get hold of user's passwords. But once authenticated they can do whatever your API allows.
if we take a look at how Twitter works, I think the missing point is an other layer to the project: The Official website:
The thing is, when you want to allow any 3rd party application to use Twitter, this application redirect you to the OAuth page of the Twitter API, IF you are connected, but if you aren't, it redirect you to the login page, which is located at http://api.twitter.com/login
(I don't know if keeping the api in api.twitter.com for loging an user, instead of just twitter.com is correct, but this is just semantics)
So, the workflow would be:
A user goes to a 3rd party application (like a website)
This third party redirect the user to the API for Authorization
The API redirect the User to the website for Authentication first
The official website redirect the User to the OpenId provider (or Facebook connect)
The Authentication is made (via multiple requests)
The website redirect the user to the API after he's successfully authenticated
The user allow/disallow the permissions asked by the 3rd party apps
The API returns to the 3rd party apps.
The User can now use (or not) the application.
This implementation have 2 problems:
Every time an User ins't authenticated (cleared it's cookies, connect himself from an other computer, etc), he will have to go through the Authentication method, by being redirected to the Official website and then being redirected to the 3rd party application (the API would be transparent, since it has already allowed the application to access his data).
All those layers would certainly lost the User on the Authentication process with too many redirections.
A possible solution would be to store the user's access_token, for example in the case of a mobile app, but with a pure html/css/js oriented app, this isn't possible. A login/password in the 3rd party web application that would match the user to the access_token of the API would be an other solution, like Seesmic (I think), but this is just useless (for us, not Seesmic) : the idea of not having the user's password become useless.
This is a possible explanation but I would require more details on how this is possible and your thought about that solution. Would it work?
(I added this as an answer since it's an (incomplete and not so sure, I agree) one.