When my application authenticates users using their google account, I use scope as "email", but for some reason, google still tells them that my app can see "who you are on google". Is there a way to avoid that?
You cant change how the Authentication screen. It displays what it does depending upon what scopes you send.
Just be sure that you are only sending the scope https://www.googleapis.com/auth/userinfo.email. If you are then it may be that https://www.googleapis.com/auth/userinfo.email automatically includes the permissions https://www.googleapis.com/auth/plus.me but I am not seeing anything in the documentation that states that. I would have to test.
Related
I'm using omniauth to authenticate a user via Google. When the user logs in via Google, I check if an account already exists with the same email (if it does, I reject sign in).
When I create the new User model, I give it the name, email, and the URL of the user's 'image'. I am not sure how to dynamically update the information in my database when the user changes their settings on Google, including the image_url when they change their profile image.
A good example of this scenario is this Stack Overflow; I signed up to SO with Google. Having changed my profile image (recently), I was surprised to find that my old Google image remains attached to my SO profile. Maybe it takes time for Google to change the old URL to represent the new image. I have noticed that some parts of Google use my new image, and other parts continue to use my old. Of course, this question doesn't have much to do with Google's profile image mechanism, I just think this is a perfect example.
My questions are:
Should I want to do this, or should I instead provide the user the ability to change their details through my site, completely ignoring what happens to their Google profile?
If I should do this, what is the best way? Checking on every login isn't ideal as the user might not log out for days or even weeks.
Should I be storing the Google auth token? Currently, I'm not as I don't need to make any Google API calls -- I only use OAuth for the 'uid' to ensure it's the same account logging in (the email isn't used at all).
I don't think the answer will be "don't store user info, query Google instead", so I'm not really sure what best practice is in this scenario. A brief walkthrough on proper procedure would be very helpful.
Normally, oauth applications will use the endpoint /me.json as part of the login process: After the user is signed in, the app uses that fresh token to query their profile info right away and update data. In your case, I understand you ignore when email already exists. You should probably add a new step there, to update your local record if it already exists instead of purely ignoring it.
In other words, your app wont be automatically notified if users change their profile pictures. But you can always use their log in action to fetch the latest image (or use their token in a background job that runs every n periods of time using something like cron + whenever, assuming the oauth scope authorizes offline access)
I have a Google Apps Marketplace (v2) app I am working on setting up Oauth2 for.
I've got everything working, but for some reason when I do a redirect to the authentication page, after, after you select which Google account to use (if like you're me and are testing, you have to pick one of several Google accounts you're currently signed into), I get sent to another page which seems utterly pointless:
This is bizarre and annoying, because I am logging in as the domain administrator!
Does anyone know a way to skip this screen, or what I might be doing to be cursed with this terrible user experience?
I just confirmed that having access_type=offline will always display this page, even with approval_prompt=auto. You will always get back a refresh token as well.
The only way to hide it is to remove access_type=offline on future login requests (ask only on signup).
I believe this shows up only if app requests refresh token for offline access. Also this should only appear first time you access the app after installation.
In order to skip this you need to update app to not request refresh tokens.
I have Oath working with Facebook, Google, and Twitter; however, I am having an issue with the latter where it uses an "authorization" URL each time rather than "authentication". The result is that the user is asked to authorize my app each time. With both Google and FB once the app is authorized they are not asked again when they log in. It is aware behind the scenes if the user is logged into one of those services and if so (and they already authorized my app) it logs them immediately into my app. With Twitter it will take them to an authorization screen each time.
I know this is due to the flow I have with Twitter which which says: redirect_url = auth.get_authorization_url() followed by a self.redirect(redirect_url)
The key above is "authorization" which is unaware of the user's acceptance of my app previously. In Twitter I know there is a checkbox to "allow this application to be used to sign in with Twitter". This is checked. What I am not able to find is the correct path with Tweepy that checks whether the user is already logged into Twitter and has already authorized my app.
I do save the tokens that Twitter sent back with the user at first authorization, however, I have no idea who the user is until they login so I cannot try to use these tokens for this initial part of the exercise. I should note that I don't have to use the tokens from Google or FB either at this stage.
Can Tweepy be used in the manner described above or do I need to do something else?
Thanks!
Fortunately, there is a very simple solution. When calling api.get_authorization_url, simply specify signin_with_twitter=True as a keyword argument. Your call should look like this:
api.get_authorization_url(signin_with_twitter=True)
This causes Tweepy to use the 'authenticationendpoint you mentioned, instead of theauthorization` endpoint.
I'm working on a cloud-storage API, authorized via OAuth. Users of third-party applications can permit said application to access their files/data via our RESTful API.
Currently, we are limiting a third-party app access to a users account once. E.g., the Access Token table has a UNIQUE on the consumer column and the user column. This makes sense at first glance, as the user should never be sent to our service to authorize a third-party application twice, since the third-party would already know their user is already tied to our service and wouldn't need to be re-authorized.
However, what if this user has two accounts on the third-party app, and they want said app to connect to their single account on our service twice? This seems likely, given the prevalence of multiple accounts on services such as Reddit.
Here are the possible solutions I've come up with so far, none of them being perfect:
Display an error during the second auth request: This seems like a frustrating experience for the user, a "cop out" of sorts.
Delete the previous token: This would likely annoy the user, as their previous accounts stop working. Even if we display a warning, it would likely be hard to explain what exactly is happening.
Return the same access token as the first request: Each time the access is requested, a set of permissions are also passed along. The permissions for the second request could be different than the permissions for the first request. Also, not sure if this will violate the OAuth spec, as the secondly generated Request Token isn't tied to the Access Token properly.
Allow two to be generated: This would be confusing, as when the user visits their screen full of authorized applications to revoke one, they don't know which authorization is tied to which third-party account. We could ask for an optional third-party username parameter when the Request Token is generated to identify the different auth's (we currently ask for a non-OAuth-standard permission parameter already). But, this seems like it wouldn't be used by 99% of developers and could make application development more confusing.
What is the best way to handle this situation? Is there a standardized practice for handling this use-case?
I think your last case is the right way to go - Allow two to be generated
When the user visits his screen full of authorized application, it's not necessary to show him one and the same Application twice - you just have to delete the tokens associated with the app if the user revokes application access. That is, all his authorizations to the app with all tokens will go away with the revoke, which is fine.
I am currently developing an app that will use the FB SDK (for the first time) to log a user into the app. The flow is typical, I assume. User taps "log in with facebook", facebook graph authenticates, then we do a call to our api and log the user in via their facebook email (only) we have on file.
However, whats freaking me out here is, theoretically if some knew our api_token, and knew that calling a POST to a login url with only a valid existing email to log them in, isn't that a security issue since they could actually log in as someone else. Am I over thinking this? Understandably, they'd have to know every aspect of the api to do any damage. But still, I'm not feeling comfortable with this flow. Am I missing something?
This shouldn't be something you have to worry about. Facebook first protects you by having the requirement for the user to be logged into Facebook. Next, the user's UID(readily available to anyone) and your API Key isn't enough. They'd still need your API Secret Key (which if someone has is a bad thing) to sign requests as you.
What you're really using is OAuth (though Devise, through OmniAuth). I'm not an expert but you can read more here: http://hueniverse.com/oauth/guide/security/
When a user registers via OAuth, you aren't going to have a password set for them, and that's not a huge deal as they have to also first log into Facebook. It might be a good idea though to ask them to set a password if they ever edit their account, that also means they can sign in the old fashion way if they desire/delete Facebook/etc.