I am currently developing an app using the Google places API..
https://developers.google.com/places/documentation/
I want to use the Events methods, so that a Place/Business owner can add events..
https://developers.google.com/places/documentation/actions#event_intro
However I obviously need to restrict it, so that only the Business owner can create events for their Business. Is there anyway of authenticating a user via a Google api, to confirm that they are the Place owner? I looked at Google+ however there is no reference to any 'Places' setup by that user in the people request.
Looks like this is possible now. The workflow would be the following:
Your user triggers a places search and selects a specific place in the result
Your user selects an option in your app to claim they are the owner of your place
Your user is redirected into an OAuth flow to Google Places where they login with their Google credentials
Once authenticated, your app is provided with an OAuth token for the user
Your app submits that token along with a Place reference to a Places API owner verification service
The Places API returns a yes/no as to whether the user concerned is the verified owner of the Place
Source - https://code.google.com/p/gmaps-api-issues/issues/detail?id=3894 - comment #3
Enjoy!
Related
Account Linking provides several ways of linking users to their own accounts such as their Google account or Twitter account.
I chose OAuth in Actions on Google website to do OAuth 2.0 Authorization Code Grant for obtaining access token in exchange for data resources. When I linked a user to a Google account Google Sign-In enabled, the fetching of user information was easy because the data is stored under payload, but OAuth implementation does not seem like it produces user data under payload inside User object.
So should I make an API call to the third party to fetch the user data and store that personal data to a database in this case? I wondered if there is a way that Google prepares on behalf of developers. If not, then greeting a user who visits my app again by saying 'Hello, {person name}' gets tedious...
You have two options with Account Linking.
In the case you describe, you're providing an OAuth endpoint and getting an auth token from the Assistant, and you are responsible for taking this token and using it to determine who the user is so you can get whatever you know about him. The token is one that you issue and control, so presumably you have that info in your database already. If you are reusing a token from another service, that service should be able to tell you who they are.
It sounds like you're using using a Google Sign In, however, in which case it is easier to use Google Sign In for Assistant. Once the user has signed into your service (either through an app or webapp) and granted permission to your service, then they will also be able to gain access through the Assistant. You will get an id token which can be decoded to get profile information about the user including their Google ID and name.
This is an API related question that applies to the APIs that I'm working on and would like to know the standard way of doing this.
say a user1 has created accounts so he can access it by
GET /accounts
but when he accesses transactions for a particular account
GET /accounts/acct1/transactions
how would this API know that the acct1 actually belongs to that user1 and is not the case where user2 is accessing user1's accounts.
This api is accessed via a Mobile app using Oauth 2.0 tokens. So while the access token control the access to API endpoints, how do we control access to only specific user's data at that endpoint. (using scopes?)
I've been looking at Spotify's apis and they seem to be doing this via v1/me end point.. Still reading...
I'm a noob at this and it looks to me that this should be documented somewhere in a standard manner in some RFC, but I couldn't find it and would appreciate direction
Can you provide more details on your use case? Why are you using OAuth?
It sounds like you need an authentication protocol - i.e. a protocol to let your server know who is accessing a particular API.
To quote the OAuth website:
OAuth 2.0 is not an authentication protocol
OAuth's main use-case is letting one application perform operations on behalf of a user of another application.
As an example, if your server wants to post a message on Facebook on behalf of a user, you will use OAuth to obtain a token from Facebook which lets you post messages on behalf of the user. Note that, in the most general case, your application does not know which user is represented by the token. Indeed, the user may not even be a (registered) user of your application - they only have to be a user of Facebook.
Practically speaking, you often can use the token you have to query Facebook for the identity of the user. So your server would extract the OAuth token from the request headers and use it to issue a query to Facebook's Graph API to obtain the user ID.
Note that the user is a Facebook user rather than a user of your app, so you will need to somehow map the Facebook user ID to your own users and permission system - i.e. check your database to ensure that the user has permissions to do what they asked to do.
This is the mechanism that is typically used when using OAuth like an authentication protocol (which, as quoted above, it is not).
I should add that if your app obtains an OAuth token and passes it to your server for the purposes of authentication, then this flow is not 100% secure, as discussed for example here, so make sure you do proper risk analysis for your case. In a nutshell, a determined attacker can theoretically impersonate your app and obtain tokens representing other users.
I'm working on an internal website for the company I work for. The website will be only available to company staff. We use Google Apps for Business, so we would like authentication to be done using our google accounts.
I've gone through 'google sign in' samples from here: https://developers.google.com/+/
It works, but the problem we run into is that it requires the user to sign up to Google+. This is a speed bump we would prefer not to have.
Are there any ways around this? Thanks.
It shouldn't be too hard to roll your own sign in using the lower levels of Oauth, eg 'email' scope. It's hard to give a more specific answer because it depends on your architecture (eg. are you predominantly server-side or client-side) and what kind of session do you want to create by the sign in process. For example, if you are client/REST based, you probably don't want any session at all as REST encourages statelessness. On the other hand, if you are more web based, serving static pages, you will want a session.
In simple terms, you will be doing something that generates an access token, and then processing that access token to determine the email address (or Google ID) of the person who created it. You will then establish some sort of session (eg. using session cookies) that identifies future requests from that user.
Feel free to add some more detail to your architecture and I'll try to finesse the answer.
For simple http servlet sessions, it will be something like.
User requests a protected page
servlet detects that there is no session and/or session has no authenticated user
servlet redirects to an Oauth page to request an access code. something like
https://accounts.google.com/o/oauth2/auth?redirect_uri=xxx&response_type=code&client_id=zz&approval_prompt=auto&scope=email
NB research the exact URL, don't rely on this to be exact
If the user isn't logged on, he'll be prompted; if he has multiple logins, he'll be prompted; if he hasn't yet granted email access, he'll be prompted. If none of these conditions are met (the normal case) he won't see anything.
Browser will redirect to the redirect_uri, carrying an access token (or an auth code if this is the first time the user has used the app)
Post the token to the Google userinfo endpoint, and you will receive a decode containing the email address
Store the email into a session object (or retrieve your own user object and store that)
redirect back to the originally requested page. You can use the OAuth state parameter to pass that around
et voila. all future page requests from that user will be within a session containing some user identification.
NB This is just an outline and I may even have missed a step. You will still need to do your own OAuth research.
Apparently not:
(..) if a Google user who has not upgraded to a Google+ account clicks
on the Sign in with Google+ button, the same consent dialog that opens
will take the user into an account upgrade flow.
Weirdly the docs for OAuth2 states:
Google+ Sign-In works for all users with a Google account, whether or
not they have upgraded to Google+.
I'm making a website for a football club. they have one google calender (and just one google account). on the website I'd like to have a list of upcoming events. So I've to access to Google Calendar via Google API. For Authorisation I've to use OAuth2. Is it possible to login with OAuth2 automatically so that the website visitors don't have login always via redirect (to google login site)? For example I make a the login via Java, instead of a user login? Because it's no so comfortable if every user of the website have to login, for just viewing the club calendar.
Not sure it is possible,
Important note concerning your design: if you login automatically to the club's account, it means that everyone that uses this website is logged in to Google Calendar on behalf of the club's user name. hence, everyone can CHANGE the calendar, delete events, etc.
Are you sure you want this to happen?
(you can set the login params to "read-only", but even then, it means that the club shows ALL his calendar to everyone. there is no privacy...)
I suggest that every user logins with his own creds, and the club's calendar can invite all registered users to his events....
Of course, you can do it, and even without giving the access to the visitor if you're doing this on the server side.
You need to do a initial step by hand.
After this step you get a refresh token, with this token you can regenerate the access token which you need to access to the calendar API, for instance to get the upcoming events.
You need to regenerate the access token if the previous access token is expired. In this case you also get an new refresh token. You need to save it, into a database or JSON file.
To get a refresh token you need to pass this options on authorization:
access_type: "offline"
approval_prompt: "force"
Without these options you only get an access token, no refresh token.
Here is the documentation: https://developers.google.com/accounts/docs/OAuth2WebServer#formingtheurl
And here a kind of tutorial: http://www.tqis.com/eloquency/googlecalendar.htm
I'm a person with a non-programming background working on a web application that must store user-generated content and always associate that content with the user who created it. I just had the developer tell me since the application must do this, using Facebook as an alternate login method is pointless because Facebook only let's a third-party web application hang on to Facebook profile information for a certain amount of time, and therefore users who login via Facebook cannot actually contribute content that would remain in the web application's databases.
I'm having trouble swallowing this. I just signed up and logged in to stackoverflow using my Facebook account, and it appears to have generated a site-specific user ID that was automatically associated with my Facebook account - thereby allowing me to save/store content on the site without having to actually create a site-specific profile.
My questions:
Where is the misunderstanding here? To what extent do alternative login options affect the ability of my application, which will consist largely of user-generated content, to store user-generated data and consistently associate it with that user? Appreciate the help!
Alternative login allows users to use an existing account to sign in to multiple websites, without needing to create new passwords. Alternate login using facebook, OpenID, gmail or any other provider doesn't affect the ability of your application to store user generated content.
When a user logs in using a login option for e.g. facebook, user enters the facebook login credential(if he isn't already logged in), facebook generates a authenticated token which is utilised by your application for future use.
In case of alternative logins only the login information (User ID/Password) isn't stored in your application, it totally depends on how you are implementing it in your application. But in any case it doesn't affect your application in saving storing and using the user generated content in your website.
Please refer to this link for more info -
http://openid.net/get-an-openid/what-is-openid/
http://oauth.net/
Hope this helps!