I have an iOS application which allows the user to use Apple's built in Accounts/Social frameworks to login via Facebook.
One question I have is, is there a way to pass user auth cookie from ACAccountStore to a UIWebView?
This will mean that, if a user clicks on a link and the built in web view page is shown, they will be able to comment/like/etc without having to login in the web view too.
Thanks,
Dan
I think it won't be possible if you don't control the service you want to be authenticated with in said webviews.
Injecting arbitrary cookies into a UIWebView is possible, as described e.g. here: Is it possible to set a cookie manually using sharedHTTPCookieStorage for a UIWebView?.
Cached auth tokens can be retrieved from ACAccountCredential. But OAuth tokens are not session-authenticating cookies.
Facebook does that. Whenever a webview is opened in their iOS client, the user will be automatically authenticated with Facebook in that webview. But they have control over their own service, so they created a mechanism for their iOS client to request session-authenticating cookies (that they then inject into webviews).
In general, though, being a 3rd party developer, you won't be able to reproduce that behavior. Unless of course given service has such mechanism for their own needs and you do some reverse-engineering.
Related
I am using Auth0 for authentication in my app, I've put the login button on the app's home screen , pressing the login button moves the user away from our app and into another location(Auth0 site), and then it takes us back after successful authentication. Is there any way of doing this with Auth0 that you stay within the app itself? That is, the user would not know that the app is using Auth0.
Yes, assuming this is a web app you can use an Embedded Login by placing the Auth0 Lock widget on your page. There are some security hoops you have to jump through if you do that (enable cross-origin authentication, use Custom Domain Names or assume your users have 3rd party cookies enabled, etc.). There's a good pro/con explanation of the two approaches here:
https://auth0.com/docs/guides/login/universal-vs-embedded
Also, there may be some ways to roll your own UI and use the Auth0 API to authenticate. The down side there is you may be introducing some security holes that Auth0 presumably wouldn't (since they're the security experts).
I assume this app is a web application.
In that case you can use a custom domain. You can specify something like login.example.com. Where example.com is your app domain. Please note that custom domain feature is not available for free plan.
I am developing one application which uses the youtube-data-api. I know it must be use with UI but I want to use it with predefined my own user credentials with back functionality in Curl or any php programming.
So I want like on one click my app should automatically get the auth access code without UI which is based on just a web server link calling from application back-end.
Can you please help to sort out my issue?
The problem you are going to have with this is that YouTube API doesn't not support service accounts.
You are going to have to use Oauth2 and authenticate your application once. Save the refresh token then use the refresh token to access the account later from your back end application.
You will have to keep an eye on it refresh tokens don't expire often but on rare cases they can expire you will need to authenticate it again if it does.
We have an ios app that uses native Facebook login just fine.
Then we also have a website (app is basically an optimized client for it) where people can login via Facebook too. When they open our website in mobile safari, they are directed to Facebook pages to authenticate there and it works, but.. it is still far from native and users have to retype credentials they often have in ios already.
So could it be possible to to somehow launch system fb authentication for just a web page (maybe using some clever URL schema?) and get granted token back to web?
Difficult way
As described here http://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#mobile-apps you could find URL scheme to trigger the native iOS app for app authorization:
fbauth://authorize?redirect_uri=[redirect_uri]&client_id=[client_id]&response_type=token
But if you call that link it's not possible to have a redirection. You could try to hack that redirection but maybe you could not find a way out.
A secure way to solve that problem is to use a SSO token to authenticate user on your App when he logs in, and next on Safari take a redirection, with a custom url to your APP, that do as bridge to FB App via Token stored in your APP. After FB authentication you can directly redirect user back to your landing page in Safari. As said by #Lego it's an alternative way to direct authenticate that could be made by going deep to custom URL used by FB.
No, it is not yet possible to directly authenticate the user via the native Facebook App, but it's possible to authenticate the user using a custom URL scheme which opens your native iOS app which then handles the authentication flow:
The user authenticates natively with your iOS App. You then store the user login (not password) in your app (i.e. using NSUserDefaults).
Then the user opens your web page in Mobile Safari. You redirect the user via a custom url scheme to your app (i.e. using myapp://authenticate). Apple documentation on implementing custom URL schemes: click
Now, if you have an active FB session in your iOS app, you can either directly redirect the user back to your landing page in Mobile Safari, passing the access token via url get parameter or you first re-authenticate the user, displaying a login view with the user name pre-filled, which you have stored in your iOS app before (step 1) and then redirect the user to your landing page, again all depending on session state and your security needs.
For opening face book app you can use Custom URL scheme. But i am not sure if u can authenticate user from it. In case if you could also then it will be confined up to the fb account which is already configured on that device app .so better try to use face book api or something
I don't get your question exactly but i think as per your question you want to create fb app Login in safari or in your custom web view.
is this perfect ?
as per my knowledge web view is different thing and native app is different thing.
if you are Login in web view then no need to check anything token or other thing because it will give you Logout thing there.
but if you are Login in your application then "developer.facebook.com" will definitely help you.
and yes, you will do most of the thing in your app as native facebook app do.
Hope it help....
we are developing an iOS App using Adobe Flex/Air. The app uses a web service that needs user authentication via facebook login. At the moment, we use server side authentication: There's a login URL displayed in a WebView where the facebook login is done. This way, we get an access_token that can be used on the server side.
This works perfectly but it would really be much better if we could use Single Sign-on with the facebook ios app. As far as I have read, this should work on the client side but I haven't found a way to authenticate the user on the server side.
facebook's access_tokens are valid either for use on the server-side or for the client side so an access_token from the client-side login won't work for the server side.
Thanks in advance for your ideas,
Henk
As far as I can see, you're making this far more complicated than it's really intended to be. Leverage the Facebook iOS SDK, and all of the heavy lifting involved with authenticating the user within your app is handled by the Facebook SDK. There's no need to independently provide sign-in sheets and manage access token exchange between the app's local storage and Facebook's servers without the convenience of the entire Facebook SDK.
This link shows you how to implement SSO natively within your iOS app. It's real simple.
http://developers.facebook.com/docs/mobile/ios/build/#implementsso
Then, I understand that you're keeping authentication information or central user database information on an external server. The best way to synchronize the information between the FB client and your own servers is to simply check the login information returned by the FB SDK with your server after you receive it.
Here's a simple breakdown:
Log the user in using Facebook's standard SDK (see the link above).
In the -didLogin method (or whatever the equivalent is in your Adobe AIR environment), check the access token returned by FB with your server. Not sure what server architecture you're using, but it's safe to say that this will go on outside of the FB SDK. Also, save the access token in your app's user defaults so that the user won't have to login again next time. This whole process should (and inherently will) feel much quicker than it sounds.
If the check with the server returns successfully, notify the user of a successful login. If not, display an error view explaining the reason the user was rejected/not logged in.
Why do it this way? The reason is fairly simple. It's safe to assume that the reason you're having a user login to your app via Facebook is so that you can make requests for the user's Facebook information (i.e. feeds, photos, likes, comments, etc.). The easiest (and best) way to do this is through the FB SDK its self. The SDK takes care of a lot of stuff behind the scenes like access token validation over time, extension of token life, validity of token, and so on. This way, you won't have to worry nearly as much about syncronizing the server information and real-time client information when changes take place. Just authenticate via the FB iOS SDK, and do the rest of your own processing afterward.
Comment below if there's anything I should clarify or even if I missed the point of your question entirely--I tend to get on a roll and may stray from the point. :)
Cheers!
The Kraken
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.