I'm developing an app with a team - I am on the business end (not a coder). The app calls for sign-in with google functionality.
The team integrated this, but currently it requires that the user select his/her google login account, then manually enter their password if they're not already signed into their google account in the default browser.
This is a problem, as many google users (including myself) don't know my password by heart as its complex - it also requires the user exit the app which isn't ideal. Is there a way to make this more streamlined? I believe I have seen this with facebook logins where the user only needs to click 'accept' and they are returned to the app and logged in - no need for password.
Thanks for any input.
Bonus questions:
How did the browser know the user's existing login accounts?
This sign-in with google page is loading in the language of my current country rather than language of the user's google account. Can this be changed?
As far as I am aware, the user must be signed into the default browser in order to get the behavior you looking for. Once signed in, entering a password will no longer be needed unless the login is expired. I think this behavior is by design and is for security purposes.
Bonus questions:
Most probably it is using cache/cookies.
According to Google documentation, seems like there is no way to change the language (but I might be wrong).
I want to do this because I am building an app, which is going to be used within a campaign and many people will be asked to login in their twitter account, in the same device.
Instead of using the default account of the iOS device, you can use Twitter's own OAuth tokens and then handle them independently in your application.
You can see the documentation at Twitter's Developer Site
In general, what's the best practice to authenticate a user via 3rd party (say Twitter) using iOS's ACAccountStore and then tie it to an existing user in my own service assuming that they were logged in already? Can I access and store the account credentials remotely over ssl, or is there a better way?
And if they had to re-login via Twitter, I could just search for the user with that twitter handle to know what backend user is tied to this account, yes?
And lastly if I wanted to be able to login via a browser later on, I would get new oauth credentials for the webapp as well, but could search for a user with the same Twitter account info and store these credentials as well, and know that they all refer to the same person, correct?
What you're asking involves many levels of a system "stack" that are custom to a particular environment. What is "correct" vs "incorrect" is dependent upon the environment you've set up and are connecting to from your iOS app.
So from what it sounds like you're leveraging iOS's Twitter functionality to create a Single Sign On (SSO) experience. There are several guides on Twitter's site for doing what you want to accomplish:
Integrating with Twitter on iOS: Single Sign On
Using Reverse Auth to Get OAuth Tokens on iOS - you can then store these server-side
Migrating tokens to system accounts - how you get OAuth tokens from your webapp to iOS.
The app should be uploading videos from iOS devices directly to our own YouTube account (not user's account).
In every scenario I came across you need an Access Token that you can get only from user logging in through OAuth2 (window popping up). Obviously, we can't give everyone username and password from company account. I was imagining using some key that uniquely identifies the app and YouTube user account to use.
Any solution / pointer? Thanks.
I ended up using deprecated Client Login. We still need to figure where to store passwords (either in the client app, or fetch them from backend every time), but that's already a huge progress.
Unfortunately, Google says Client Login will be removed in 2015. We can just hope they'll come up with non-interactive auth method requiring no user interaction by then.
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.