I am building a twitter application that is currently using the classic login instead of OAuth. Does Twitter have any plans of deprecating this? I chose not to do OAuth because it is still being piloted as a beta.
I doubt there are any plans to deprecate the old API, because there are hundreds of applications which are designed to use it. Even though it's safe to use the old API, if I were you, I'd transition to OAuth due to user security concerns. OAuth is more secure than the plain API, and provides fewer ways for an attacker to obtain the user's password.
From the Twitter API documentation:
OAuth is the Twitter preferred method
of authentication moving forward.
While we have no plans in the near
term to require OAuth, new
applications should consider it best
practice to develop for OAuth. We
eventually would like to suspend Basic
Auth support. However we realize that
Basic Auth has been a large part of
the API's success, and that the
barrier to entry if OAuth is the only
solution is substantially higher. Many
applications rely on Twitter accounts
as their means of account management.
Additionally, Basic Auth allows a
developer with a command line, cURL,
and his account credentials to start
poking at Twitter data. There are
still a number of archetectural use
cases to work through before we
consider the deprication of Basic
Auth. Before any changes begin to
happen, we will discuss them with the
community through the support
channels, and give at least 6 months
lead time before making any policy
changes.
"When are you going to turn off Basic Auth?
We announced in December of 2009 the deprecation of Basic Auth. Its removal date from the platform is set for June 2010. We announced towards the end of June 2010 that we have postponed this until August 16th 2010."
--from http://dev.twitter.com/pages/oauth_faq
I believe using Oauth would be the safest bet, and its more convienet in the long run. I read an article saying that twitter is making Oauth mandatory pretty soon as well so you will have to switch over eventually.
It would be best if you provide both mechanisms to your clients, by default the classic login but if user is concerned about security they can choose the OAuth mechanism.
Mind it, many users will leave your application just because it requires them to give your application their (user's) credentials.
Related
I know it allows a third party to have access to the user's data of the another website. If I just want to make an e-commerce website with Facebook login, and it'll only be used by my customer, is it an overkill to use OAuth?
For an ecommerce website you will require stuff such as phone number, address, pincode etc.. Facebook wont give you all of these things.
As not a lot of people save such info on fb,
Its wont be an overkill, infact it is much easier, but you wont benefit from it at all.
Thr best thing would be to get an write a custom login system, make it short and simple.Maybe even get a bulk sms module/service to verify phone numbers or order confirmations.
If the Facebook login is the only way to login, it can be quite limiting for people having no Facebook account or not wanting to use it. But it's not difficult to implement and it can make your application safer (not keeping passwords in your database) and easier to use for Facebook users, which I think makes it worth the effort.
After the first successful Facebook authentication, you can ask users for all additional data you need not available from Facebook.
And if you support one OAuth2 provider, it's easy to add other ones later (such as Google).
I would host the Website on Google Cloud Platform or one of the other big players (Azure, AWS) and use their Authentication systems and APIs.
In today's Cyber Security environment it seems almost "foolish" to use any other route. Why do you want to setup a "custom login system" when using things like Firebase (Azure or AWS has things too) makes it so you can do 5 or 6 of the major Social Logins and/or a username password system while "someone else" deals with all the hassles of password management and prevention password breaches.
There is no way a "small business" can compete with the security and infrastructure that these "Big Player" provide.
I set up a project on my main domain example.com and then moved it to a subdomain sub.example.com
Now when I try to use the same (default ASP.NET MVC or on my Discourse forum) project with OpenId and click on the Google button to log in with my Google account it throws the following error -
That’s an error.
OpenID auth request contains an unregistered domain: http://sub.example.com
I have tried Googling that message but apparently I am one of the first four people to see it. Any ideas here?
According to this page,
Google closed registration to new OpenID 2.0 clients in May 2014 and will be shutting down the OpenID 2.0 service in April 2015.
The reason why some hosts work and some don't is that although Google isn't adding new hosts, you can still use the ones that are already registered.
UPDATE :
Some people have asked for a simple explanation for how to fix this, or otherwise how to proceed.
Basically, you now have 2 options.
Use OAuth 2.0 (instead of openID protocols and older versions of OAuth)
or
Use Google+ login (which Google tried to "push" you towards)
For more details check the migration guide :
https://developers.google.com/+/api/auth-migration#userinfo
I would like to add some context to this thread together with a potential solution to developers that are currently blocked.
Back in February we announced the deprecation of OpenID 2.0 (OID2) scheduled for April 2015. We also announced that new OID2 relying parties (RPs) registrations† will no longer be accepted after April 2014.
Given that the API will be shut-down in less than a year’s time, our intention is to avoid having new RPs integrating with Google's OID2 API. Instead, we suggest to use our OpenID Connect API which we consider more secure and easier to implement.
Registrations were effectively closed on May 19th (as documented in the Google’s OID2 developer documentation). All RPs already using OID2 should not be affected by this the closure.
As for developers currently working on an integration with our OID2 API (presumably because they missed the announcement and warnings in our OID2 documentation), we will do our best to minimize the friction caused by the registration closure. If you are in such situation, please let us know by posting a registration request before June 15th. The post should contain a sample OID2 request used by your application, in case you prefer not to disclose such information, please post an email address and we will reach out. We plan to look into each case and try to get you unblocked in the best possible way.
† OID2 does not have a registration procedure for RPs integrating with an identity provider. RPs are associated to the realm value (e.g., www.example.com) used when contacting Google OID2 API. Thus, a RP is considered "registered" if its realm value has been used to contact our OID2 API.
You can easily change to OAuth 2, this article shows you how to register your app with Google and add the key to MVC. Scroll down to: "Creating a Google app for OAuth 2 and connecting the app to the project."
And you may need to add the Microsoft.Owin.Security.Google package via NuGet.
I had the identical problem but when using nodejs / expressjs
I have migrate my code using below url code and fixed that issue
Passport strategies for authenticating with Google using OAuth 1.0a and OAuth 2.0.
https://github.com/jaredhanson/passport-google-oauth
The sub-domains that fail are those that had never seen any user requests before. As per https://developers.google.com/+/api/auth-migration#timetable, Google is not allowing new domains in the OpenID2 API.
I have this exact problem, we use googles login to run a platform, its a brand new problem.
A few things I have discovered if this helps
Full domains trying to use openID never fail www.example.org and www.example2.com are not having this problem
Subdomains on the platform have this problem sometimes, but the same subdomains always fail and the others always work.
It started around Monday and is still happening now.
Take a deep breath and just change Startup.Auth.cs file
app.UseGoogleAuthentication();
to
app.UseGoogleAuthentication(
clientId: "000-000.apps.googleusercontent.com",
clientSecret: "00000000000");
refer to the http://www.asp.net/mvc/tutorials/mvc-5/create-an-aspnet-mvc-5-app-with-facebook-and-google-oauth2-and-openid-sign-on page.
I'm trying to work out the best architecture for a couple of apps I'm developing.
In both apps I want to utilise google/twitter/LinkedIn/etc to provide authentication of a users identity. The app is composed of an iOS app which has an option to send data to a server which I'm writing in node.js.
I want to utilise either OAuth or OpenId to handle identifying a user against the above servers so that I don't have to put in an authentication system of my own. In other words, allowing users to re-use their ids when choosing to upload data.
I should also note that apart from identifying a user, obtaining a name and email address, I have not intention of using any of their APIs at this time.
I think I have two options:
Place the Authorisation code in the iOS client and transmit some sort of key to the server with the data which it can then verify.
Keep the iOS client fairly dumb, and handle authorisation from the node server.
I'd probably prefer the second option because it means I could centralise authentication and be able to support a web site as well. That's my current theory.
Can anyone who has done something like this give me some pointers as to the pros and cons, OAuth or OpenId, or links to some examples?
In our previous app we opted for a combination of the two approaches. We wanted to centralize our user data on our server in the event we needed to make future API calls on those services. We also wanted the native oAuth experience for the user on the client. Ie: on Android and iOS, the developer can have single sign-on / authorization run through the native Facebook app (if available), vs. popping-up a webview that serves the 'Approve' dialog. It's a better user experience in my opinion. Also for Twitter, the oAuth process may require a PIN code to be entered in the callback which should probably be handled on the client side.
You can pass the access token retrieved by the client to the server for storage and later use if you intend on making additional API calls on these services, provided you expect the token to be long-lived (ie: offline-access permission on FB).
In any case this is mostly a user experience decision.
Could anyone please summarize the differences between Twitter's REST API and its Streaming API?
And does either of them uses Push technology?
The REST API lets you query or modify a user's account. You don't need their permission to query their account, you do need it to modify their account. They provide permission through OAuth authentication.
The streaming API delivers tweets based on search terms or for specific users you request, along with info about the author, in real-time. You do not need the tweet author's permission. You must log into some Twitter account to use streaming, using either basic or OAuth authentication.
Neither uses push, but streaming is a continuous net connection, so it is real-time delivery, making it functionally similar to push.
For anybody coming to this more recently, The REST API (v1.0) has now been retired with v1.1 being the only version. This Does now require authentication for everything, including reads.
Authentication required on all endpoints
In version 1.1, we're requiring applications to authenticate all of
their requests with OAuth 1.0a or Application-only authentication. Not
only will this visibility allow us to prevent abusive behavior, but it
will also help us to further understand how categories of applications
are using the API. We'll apply that understanding to better meet the
needs of developers as we continue to evolve the platform. At this
time, all authentication requires user context, but in the coming
weeks we'll be pushing out support for a form of authentication not
requiring a user context.
Actually you can use search through the REST API as well. For example it's the only way to combine geo AND query keyword, while the Stream API can only use OR logic.
I think it's about defacto push streaming as Adam Green has said.
Can we build applications on top of the twitter user base?
Is it just another open id or something more?
I noticed when using twitpic and some MUD type game 14mafia.com that it uses my twitter login (it tweets on your behalf).
If they are using my login/password that's pretty crazy, I mean what kind of security is that?
Anyhow, just want a developers who has expereince to tell me if we can re-use their membership like openid?
Can we build applications on top of
the twitter user base?
The Twitter API is described at http://apiwiki.twitter.com/
Is it just another open id or
something more?
Twitter is neither an OpenID consumer nor provider.
I noticed when using twitpic and some
MUD type game 14mafia.com that it uses
my twitter login (it tweets on your
behalf).
If they are using my login/password
that's pretty crazy, I mean what kind
of security is that?
Awful security. Don't give out your password to third party sites. Some just use the password anti-pattern, others will steal your credentials for purposes you don't want.
Twitter supports OAuth today. If a site wants to do things with your Twitter profile, it should use that.
Anyhow, just want a developers who has
expereince to tell me if we can re-use
their membership like openid?
No, you can't.
Twitter offers both OAuth and simple username/password authentication in its API. Originally they only had the basic authentication API so many early apps were built using it. Later, they added the OAuth support, but since it was easier to use the basic authentication, many twitter clients and apps still use it.
You can tell which one an application is using, because if they are using the simple authentication they will ask for your password. You have to trust them with it in that case. You're right that it's poor security.
I imagine they are using the Twitter API.