AnyOpenId site for OpenId authentication stopped working - facebook

Does anyone know if http://anyopenid has stopped existing or has be compromised as I get 404 errors and cannot use the Facebook OpenId Url i.e. http://facebook.anyopenid.com/. Is there an alternative or will I need to use the OAuth to authenticate users on my application via their Facebook, Twitter accounts.

I was emailing with one of the developers, and he told me that it has been sun-setted due to poor uptake and high maintenance costs. Too bad; it was a great service. :-( We have moved to using OAuth on our site as a result.

Related

Facebook Marketing API Authorization

I'm building an internal app for a client of mine (an ad agency) who wants to do ad performance reporting for about 30 of their clients. Part of this project is to pull down performance metrics from Facebook Ads for these 30 clients.
I've created a Facebook App and got a development token. With this token, I've been able to get the technical part of the project working -- I can pull down the metrics just fine using Facebook's Marketing API.
My question is about authorization and authentication. I'm thoroughly confused by Facebook's mechanisms for this.
What do I need to do to get access to Marketing API metrics for these 30 clients?
Do I need to publish a Facebook App? If so, do I need to go through the approval process? This seems kind of crazy because Facebook wants a login so they can test things out, but the product is strictly internal so there's really nothing they can log in and see.
I guess another question is: Is there another way I can get access to these 30 clients? With Google Adwords, it was easy. I just used oauth and am granted access as needed. Is there a simple way like that with the Facebook Marketing API?
You need to submit your app for review, if you want to be able to ask all users for the permission.
If your app is used by a limited number of people only, that you can add to a role in the app - then they can be asked for all permissions, even without review. This is mainly for testing purposes, but Facebook has it documented as a kind of “loophole” for apps that are only used by a limited user base. https://developers.facebook.com/docs/apps/faq#faq_180362122361921

What OAuth providers are safe to use as Login authorization

Recently I've been doing some research into OAuth and OpenID/OpenId Connect and it's all just left me confused as to what is best to use and what is safe.
Originally I thought you could just use OAuth2.0 to log a user in (using their ID as a way of remembering the user) but then I found out that due to how the spec of OAuth 2 works, hijacking tokens would allow a malicious user to impersonate another person. Which is why it's stated that you shouldn't use OAuth 2 as authorization.
But then I have been reading that providers as such as google and facebook have decided to go away a little from the standard and ensure that such attacks are not possible. So my question, what OAuth providers are safe to use to gather a users ID to be used to log them into my service.
Also, facebook is offering another service called facebook login. From what I can tell it's OAuth but without the impersonation issue (obviously) AND the app creator cannot do other OAuth features as such as posting on behalf of the user without getting their app reviewed by facebook. Why would I use facebook login over OAuth which gives me all those permissions without review?
Thanks a heap everone

If I use Facebook for authentication, is regular HTTP fine?

Can the Stack Overflow community sanity-check this for me?
I am working on a project that involves two components: an iOS app and a mobile website. It's for a product that will interact pretty heavily with Facebook. The website is hosted on Heroku.
From iOS land, my intention is to use the Facebook iOS SDK for authentication and then hit the web API with the user's access token at https://[myappname].herokuapp.com. Since Heroku offers piggyback SSL when using the herokuapp.com domain, and the user won't be seeing this URL anyway, I figure that's fine. And this way the request is encrypted, so the access token should be safe.
From the mobile website, users will log in using Facebook, at which point my understanding is that the access token will be in their cookies, which my server can then access without having to exchange it back and forth with each request. By this reasoning it seems to me I can just stick with regular unencrypted http:// URLs for the website (and therefore use my custom domain name without having to pay a monthly fee for Heroku's SSL Endpoint add-on).
Does this all make sense? I will be the first to admit my understanding of a lot of this stuff is in serious need of an upgrade. But for now I'm just looking for someone who can tell me, "No, you're totally overlooking/misunderstanding XYZ" or "Yeah, this is how it's generally done."
Facebook advises that you should not take a dependency on their cookie format. They have stated that the cookies are "an implementation detail" that they may tweak at any time with no notice given. You should not directly access the token or other user info directly from the cookie. I personally have had some bad experiences trying to get user information directly from the cookies, mostly due to timing -- they were not always there or updated when I expected them to be.
Client-side, you should either get the access token from the Javascript SDK via FB.getLoginStatus or other method that returns the access token, and then post it up to your server. This should really be done using ssl otherwise you are susceptible to network packet sniffing where a black hat could grab the token and be able to use all of the privileges the user granted your app.
There is also a server-side option as well which hits at ssl endpoint on Facebook's servers to return an access token.
References:
"Cookies are an implementation detail": https://developers.facebook.com/blog/post/624/
Authentication docs: https://developers.facebook.com/docs/authentication/
Website login via Facebook works totally fine via HTTP.

facebook with openid

Referencing Is Facebook an OpenID provider? here. This is kind of an additional question based on it.
I have also read the article at : What is the "openid" url of facebook? - but I am still pretty confused on the whole ordeal. The goal is for people who use facebook to easily login to our website, not to neccessarily integrate with facebook and add things to it (yet). I have read the documentation on facebook connect and am still having trouble grasping exactly what we need to do to accomplish this.
I notice that it says that facebook accepts openid logins - so in theory someone with a facebook account could login to a site that took other openid logins, correct? Or do I have to code a separate 'facebookconnect' system just to accept logins from facebook accounts?
There is a difference between an OpenID provider (who gives you a URL you can log into other sites with) and an OpenID consumer (who lets you log into their site using an OpenID URL).
Someone who "accepts openid logins" sounds like a consumer, but your description "someone with a facebook account could login to a site that took other openid logins" is describing a provider.
There's nothing stopping a site being both a consumer and a provider, but as far as I know, Facebook isn't one.
You have to code a separate "Facebook Connect" system just to accept logins from Facebook accounts, they do not use the OpenID standard.
RPX is a commercial service that offers a way to cut down on some of the confusion.

LinkedIn / Twitter / Facebook as OAuth and OpenId use

Firstly I understand OpenId is for authentication and OAuth is for authorisation and unlike other questions on the site I am not asking which should be used for which but whether anyone can advise a solution for my issue.
I want to allow users to login to my site via their LinkedIn/Twitter/Facebook account once logged in say via LinkedIn they could also then authorise their Twitter and Facebook account as a optional login method. This would allow the user to authenticate via any of the three but end up with their user account on my site as the end result.
I also want to use the authorisation they have provided to get basic user details (profile pic/name etc) and post status updates.
I don't want to ask a user to login with their account via openId then have to authorise the same account again via oauth to allow my site to publish to their service feed and have to do this for each of the 3 services.
Any ideas or issues to this issue?
If you are using ASP.NET MVC, DotNetOpenAuth is an excellent solution for supporting OpenID/OAuth sites. StackOverflow is using it, and they are quite picky for the code they use in the site.
The integration if OpenID with DotNetOpenAuth is quite straightforward. I have not tried OAuth, but I don't expect it to be of any less quality.
Unfortunately, Facebook does not support OpenID/OAuth, so you need to use a different solution for it. The one I use is Clarity Consulting's Facebook Developer Toolkit. It works, although I do have certain complaints about the quality of the code; unfortunately I haven't found anything better yet. (Note: If anyone knows a better alternative, by all means let me know)
The basic integration of Facebook Connect with the Facebook Developer Toolkit is also relatively straightforward. However, their object model is somewhat messed up, due to their attempt to stay as close to the Facebook APIs, so the HTTP API patterns are bleeding through a lot. Still, it does the work.
Update: Now that Facebook announced that they'll be supporting OAuth 2.0, DotNetOpenAuth might turn out to be the best solution.
Have you looked into RPX?
https://rpxnow.com/
I don't want to ask a user to login with their account via openId then have to authorise the same account again via oauth to allow my site to publish to their service feed and have to do this for each of the 3 services.
I'm afraid you'll have to connect the user's account to each of the 3 services individually. What platform are you using to build your app? If it's Ruby, then a gem like OmniAuth looks promising.