I have been reading google+ API and domain API and found out that google+ API are read-only. And domain API is only for domain users. But somehow I just tried buffer, connected my google+ profile and shared some text. It appeared in the posts section. Now my profile was not a part of a domain, it was username#gmail.com. Also, there are other social products which give the same functionality.
How do this work?
Your app can share post on the behalf of the user on Google plus. All you need to do is take the appropriate permission from the user.
https://www.googleapis.com/auth/plus.stream.write Required - Grants
permission for the app to create posts or comments on behalf of a
user. The Google+ Domains API only allows creation of restricted
posts, and only allows comments to be added to restricted posts.
Ref : https://developers.google.com/+/domains/posts/creating
There is an open authentication specification called oAuth that utilizes public api's, for instance: GitHub. Facebook, LinkedIn, Twitter, Google, Slack, etc. I believe the easiest way to implement this strategy is either with a bot, webhook, or my choice api framework Express.
Express has a middleware library called Passport that enables a quick setup of the necessary steps to implement the correct api keys, secrets and callbacks. Essentially what you have to do is create an app with each provider and they will give you the api information necessary for your Passport configuration.
Once you've got that done, then you just hook up a simple router and server, then you've got an app that can allow your users to sign into whichever provider they choose. The beauty behind the solution is their password information is serialized inside a JSON store to prevent security issues.
https://developers.google.com/+/web/api/rest/
Related
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.
And how do they get information from these sites? Is there some common way of exposing this information with the users consent? How can they tell if you've authenticated with the external webpage? Is it several different APIs?
Social Networks makes use of OAuth.
Quoting from wikipedia:
OAuth is an open standard for authorization. OAuth provides client
applications a 'secure delegated access' to server resources on behalf
of a resource owner. It specifies a process for resource owners to
authorize third-party access to their server resources without sharing
their credentials.
You can have a look at these:
Facebook : https://developers.facebook.com/docs/reference/dialogs/oauth
Google: https://developers.google.com/identity/protocols/OAuth2
You can get list of libraries for different languages here: http://oauth.net/2/
They use a special Javascript API that Facebook has created, which I believe runs on a protocol called OAUTH. The complete details can be found at the Facebook developer page:
https://developers.facebook.com/docs/facebook-login/login-flow-for-web/v2.3
Once a person is logged in, you can get their information like this:
FB.api('/me', function(data) {
console.log(JSON.stringify(data));
});
Then facebook sends back their information as a JSON object called data
I want users to my website to use Google Accounts to authenticate / sign in to my website. The primary use case being users will edit and generate content and we want to log ownership in a secure way. We are not interested in obtaining users Google data, we just want a means to authenticate users.
After googling, I came across some documentation, which seems to explain how to do this OpenID Connect (OAuth 2.0 for Login). But the documentation immediately says "Note: If you want to provide a “sign-in with Google” button for your website or app, we recommend using Google+ Sign-In, ...", which if you follow the link ultimately takes you to Google+ Sign-In.
What's the difference between these two pages of documentation? Why does the first tell you to go to the second while not saying the first is deprecated? Are both/either suitable for my use case? All it says is "we recommend" I want to know WHY, WHY do they recommend it?
UPDATE: I also found yet another link which seems to be documenting another approach https://developers.google.com/accounts/docs/OAuth2WebServer I think this is just for "Authorization" i.e. authorizing your app to make google api calls to get user data, so cannot be used for authenticating/sign-in.
BTW I'm building my website with a Scala Spray BE REST API & NG JS FE.
A comparison of the two is available here.
Google+ Sign-In with profile scope
Has Google client libraries for authenticating with OAuth 2.0, which includes support for Google+ and other Google services (like getting social information on a user). Also this can make implementing easier and requires less boiler plate code
Has the Google+ Sign-In button to simplify sign-in Has no pre-built widgets
Supports over-the-air Android installs
OAuth login is primarily just for authentication at a lower level, that is by making raw HTTP requests, no API.
OpenID Connect protocols (OAuth 2.0 login)
Google+ Sign-In supports OIDC interoperability if you configure with the openid scope and get the user profile using getOpenIdConnect.
OAuth 2.0 login supports OIDC directly. Use it for signing in users to apps that do not need social features and run on platforms not supported by Google+ Sign-In.
Which URL I should user for authentication user in the Twitter?
For example, in the Instagram token for user can be received when user click on the following link
https://api.instagram.com/oauth/authorize/?client_id=XXX&redirect_uri=XXX&response_type=XXX
After this its return token and I can work with user profile.
How to build such link for twitter?
Twitter API has several ways to authorize and it depends on what you want to do for determining which approach to take.
The OAuth2 approach that instagram takes is called application-only in Twitter API. The thing about application-only is that you can only use it on endpoints that aren't associated with a user. e.g. it's great for search, but doesn't work well for tweeting (which is something a user would do).
A couple other approaches are Single User Authorization, which is good if your app only needs one set of credentials. e.g. a server app. Another is Pin Authorization which is a work-around for devices that can't manage Web callbacks. These use OAuth 1.0A.
There are a few other OAuth options, but this was just to give you an idea about the available choices and the need to think about what you want to accomplish and match that with what the Twitter API offers. Here's the Twitter docs for more info:
Authentication and Authorization
Should I use oAuth, for example LinkedIn or Twitter, as my signin mechanism for my app? It seems that most apps just use oAuth to connect other services to it, but they make you set up your own user/password after you use oAuth (including StackOverflow), and I'm not really sure why this is. Would love some insight here. Thank you.
Why not use OpenId, to allow people to sign into your application, without having to type any specific login/password ?
Quoting the corresponding wikipedia entry :
OpenID is an open, decentralized
standard for authenticating users
which can be used for access control,
allowing users to log on to different
services with the same digital
identity where these services trust
the authentication body. OpenID
replaces the common log on process
that uses a login-name and a password,
...
BTW, that's exactly how one logs-in on stackoverflow ;-)
OAuth purpose is not authenticating your users with your site, is letting your users allow you (the oauth consumer) access to their protected resources in other sites (oauth providers) like LinkedIn, Twitter, Google APIs etc.
For authentication, you should use OpenId as others have pointed
Twitter provides a Sign in with Twitter flow that is OAuth but provides a faster redirect if it is an existing user of your service and they are already authenticated with Twitter.
http://apiwiki.twitter.com/Sign-in-with-Twitter
If you are building a Twitter centric application this makes a lot of since to use and you won't have to implement an entire alternate authentication method like OpenID.
Be careful if you let users authenticate with both Twitter and LinkedIn as users will inadvertently create two accounts and need them to be merged.
Facebook and Twitter both have the "Login with Facebook/Twitter" APIs to actually allow users to login without having to create an account for your website. Both of them will return you a valid session that may (or may not) expire. So you actually wouldn't have to ask users to decide on a username/password, as you can fetch both from the APIs (you can not get the users email address when using Twitter though)
So why add those functions to your website?
Users are in general more likely to hit the "Login with ..." button than going through the whole mail address authorization process and entering their name, etc...
Linkedin only has OAuth for usage to its API. It will also depend on what type of language you are writing your webapp in, they should have premade wrapper libraries you could tap on to.