The more I dig into OAuth the more I realize it's about authorization for third-party consumers. A few weeks ago I asked about an allowance for in-house apps whereby they don't need to redirect customers, since practically speaking it doesn't make much sense to say something like 'The facebook app would like permission to access your information on facebook'...
Thinking this through further, why bother with OAuth at all for an in-house app?
Related
1: When it says 15 requests per 15 minute window, does this really mean I can only send 15 requests per 15 minutes?
2: Do I really need to set up a Twitter bot to send basic requests like getting a list of a user's followers? Is there a way to get the data through a URL, like in most web APIs? I'm making software that will be used by other people, so it can't have a bot auth token in the code.
I know I'm pretty much asking if what it blatantly says is true, but I'm just having trouble believing that the Twitter API is really this bad.
It sounds like you are specifically asking about the friends and followers endpoints. Yes, this is limited to 15 requests in a 15 minute window. Other endpoints / features have different rate limits.
The Twitter API requires authentication. You do not need to set up a "bot", but you will need a registered Twitter developer account, and a Twitter app, in order to use the API. If your app will be used by other people, you would need to implement Sign-in with Twitter to enable them to authenticate with your app; you can then store their access token (until or unless they revoke it) to make requests on their behalf. This is pretty standard for any multi-user web app.
I recently received an email from the Google Cloud Platform Team notifying me of a policy violation stating that we had not completed the OAuth developer verification process and we're limited to 100 new user grants of which we're already at 60% towards.
The thing is, if I view this Oauth consent screen in the Google Cloud Platform, at the top of the page, it states:
Your consent screen is being verified. This may take up to several days. Your last approved consent screen is still in use.
This page was last saved and 'submitted for verification' some months ago now.
The page itself is constantly glitchy and poor anyway I've noticed at various points in the past.
The information this page contains is correct and I am unable to re-submit for verification unless I make changes.
Nonetheless, I'll make a change, resubmit, then edit removing that change and resubmit again but it's proving to be a bit of a hassle when either their system doesn't work or we're waiting on them to approve/reject the Oauth verification.
Am I supposed to be doing something else or is there a workaround at all?
Make sure that you've taken a look at the App Verification help page:
https://support.google.com/cloud/answer/7454865?hl=en
and the much more detailed verification FAQ:
https://support.google.com/cloud/answer/9110914
From the sounds of your post, it seems like you probably just need to get your app's branding verified because you are accessing sensitive scopes. That should be a pretty straightforward process if you have everything ready for review. Make sure you haven't gotten any messages from the review team with open items you need to accomplish. If not, you can make a trivial change and resubmit.
If you are trying to access a restricted scope like Gmail APIs, the process will be much more involved. Make sure you have all your requirements taken care of as outlined in the FAQ. And be sure you look closely at what scopes your code is actually requesting. If you are asking for sensitive or restricted scopes in your app but don't have those fully registered and approved in the developer console, your users will get warnings and you'll have restricted tokens revoked.
We are trying to integrate Google adwords connectivity into our Marketing Analytics Web application, meaning we are creating an app that would allow small businesses to login to their AdWords accounts and manage them based on findings of our app.
The problem is that upon signing up for API Access AdWords is asking us to link 'our' adwords account to the app account as well. This does not make too much sense to us, why do we need to show our adwords account when we ourselves will not be the main users of the app. It almost seems that AdWords assumes only a couple of users will be using the API.
Is my thinking flawed here? Can anyone clarify?
Google does seem to assume that their AdWords API is used primarily for in-house reporting and account management (as well by advertising agencies managing accounts on behalf of their clients).
Even if you are building an app for general, public use, the app's Client ID, Client Secret, and Developer Token are still connected to your company's MCC account.
However, this does not cause a problem. Any AdWords account owner can authorize your app to access their data, without having to be your client.
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.
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.