I always wonder how can the Twitter and many social network application provides the API for developer via registered app key. How can it granted and track the using of those external application?
Can you answer me this question? because I alway wondering about this.
Twitter, Facebook, Google Apps, and others often use OAuth to provide this authentication and tracking. There is a lot of information to be found at http://oauth.net/ and you can play around with OAuth in general at Google's OAuth Playground.
Generally speaking the service would generate an API key for you when you sign up for developer access. This key is then associated to your account.
Whenever you make a call to an API, you would be required to pass that key as one of the parameters. That method would then verify that you passed a valid key and would know who was making the call based on the key -> account association created when you signed up.
For Ruby on Rails:
Easy Rails API Authentication Using restful-authentication
http://www.compulsivoco.com/2009/05/rails-api-authentication-using-restful-authentication/
Related
When creating chrome extensions that play with the youtube data api, the api key is used. But is there any other way to get data from google servers instead of exposing our personal api key in the xmlhttprequest, apart from the naive way of asking the user to create his/her own api in their account and input that to use it in the extension?
I would refer to Google for best practices.
https://support.google.com/cloud/answer/6310037?hl=en
You could use OAuth 2.0 credentials, obtain an access token through chrome.identity API, and then use that token in the XMLHttpRequests.
I've been reading a lot lately about WEB API authentication mechanisms and I'm a little bit confused regarding how to implement my Web API authentication mechanism, I'm thinking on using Token based authentication but I'm not sure if it is the right choice.
Basically my Web API will manage all the operations needed and it will store the users of my website as well the API users(in case they have to be separated).
I want to support the following
User can register on my website and apps using their G+ or Facebook account or an already created username from my service, as well they will be to login using their social account.
If the user is not logged in they won't be able to post Items but they will be able to see the Items, think something like Craiglist.
Let's say the user is a developer and they want to post the items through some software they created instead of going through the website and posting one item at a time, how do I allow this?
Now, my questions are: 1) When a user registers on my website, do I have to create a (public key/ secret key) for it subsequent access token , so I can use my API from the website as the user checking if they have access to certain endpoints?
2) Do I have to assign a (public key / secret key) for my website so I can consume the API when the user is not logged in?
3) The same as above for mobile apps
4) How do I allow users to (sign up / sign in) using G+ or Facebook?, if they log in using any social network how am I going to secure my api?
Please, any answer will be really appreciated.
Thanks
For ASP.NET Web API 2, I would recommend you to use the default Owin OAuth2 authentication. It's a standard form of authentication well documented enough. If you do not have enough knowledge about OAuth2, read the RFC.
With Web API 2, ASP.NET moved to a new security model, called ASP.NET Identity. There is this really good video that explains the basics. The point is that starts from scratch, ignoring traditional basic, forms, or windows authentication.
A lot of learning material is on the ASP.NET website.
For local, individual accounts (questions #1, #2, and #3), look through this tutorial - here basically your own server will act as an OAuth authorization server, and the Owin OAuth2 implementation will take care of generating access token and authenticating them. Since you'll be using the OAuth 2 standard, it will be basically the same for mobile as well.
For external accounts (question #4), read through this tutorial. There are official libraries for third-party authentication for the major providers:
Microsoft.Owin.Security.Facebook
Microsoft.Owin.Security.Google
Microsoft.Owin.Security.Twitter
Microsoft.Owin.Security.MicrosoftAccount
It would helpful to also learn more and understand the new OWIN specification, that describes how web apps need to created for the .NET framework, and the Katana project (Microsoft's OWIN implementation).
Follow this tutorial for most of your requirements http://bitoftech.net/2015/01/21/asp-net-identity-2-with-asp-net-web-api-2-accounts-management/ Logging in via facebook/G+ MVC already has the helpers commented out. You would get the credentials by setting up key's via the third party apps and then store the identity.
I wish to create a single application registered with Google that uses Google's OAuth2 mechanisms to authorize read access to a user's Google Drive content. Then on behalf of that user I want to take that data and expose it via my application as a webservice (proprietary REST API). The webservice can then be consumed by arbitrary 3rd party applications that know nothing about the authorization of my application to access the user's Google Drive.
This is technically possible and not very difficult. My question is whether or not this is an acceptable use of Google's APIs and Google's OAuth2 offering?
OAuth 2 requires an user to affirmatively say yes to your request. As long as you properly describe what you'll do with it (and what is the nature of these third party apps) then I don't see why you can't.
If you just try to slip in the read scope on a generic-looking request form, than I would say that's a no-no.
I've been researching PASTEBIN type API's that would enable storage of code snippets for a project I'm working on. The problem is that most if the API's I've found do not support edit/update of existing pastes.
I found that the Snipt.org API does support snippet updates. However, authentication for the snipt.org API is done using your Twitter account. The snipt.org API docs (https://code.google.com/p/snipt-org/wiki/REST_API_Docs?tm=6#Authorization) suggest using a GET '/auth' call (providing a Twitter uname/password in the URL) to obtain an API token to access the API. Is it just me or does this seem like a good way to compromise your Twitter credentials?
I have used other sites that authenticate via Twitter, but I get authenticated on the Twitter site first which in turn sends a token to the authorized app.
Well, obviously this API has some serious flaws.
But if you use https, the URLs of GET requests will get encrypted along the way. (But still get logged in the cache of your browser. do clear it.)
So if you really like snipt, you could use a new twitter account created simply for the purpose of authenticating to snipt.
It won't feel particularly good. And I have some serious doubts about the rest of their security code based on this part of the API. But I do not see how exactly your credentials could be stolen using this part of it by others than the snipt maintainers who already have access to your snipts. So if you protect only snipts with the credentials, and no tweets, you should be alright.
I am writing an API to use with my mobile app. I want to use Api Key authentication.
In this kind of system, should I give an api key to each user? Or should I only give Api Key per application that connects to the API?
The reason that I asked that is:
If I give every user api key and authenticate them by their api key, authenticated user will be only one, and I can make requests like /reviews/ and server will return all reviews which are done by authenticated user.
On the other hand, the app will authenticate to use the api, and I should make request like "/reviews?userId=23842374283423".
Which one is the most used type of authentication?
Normally the API keys are issued to the developer who consumes the API rather than the application. Although in most cases each key is used only for one application, in theory you could have another one using the same key. I would recommend going for the second approach.