I'm working on a small Rails application in which I'd like users to be able to prove that accounts they have at other sites, Live Journal, Stack Overflow, Reddit, etc. are in fact theirs.
Can anyone provide any guidance on how best to accomplish something like this?
I've outlined some potential options for account verification.
Ask users to basically pass their log in credentials to the application via SSL and allow it to verify that it can log in. Then, of course, log out and delete any user session data/credentials. Problems:
People are not going to psyched about the idea of exposing their credentials to a third party system.
Handing off log in information may well be against many
website's ToS agreements.
The idea makes me queasy.
Provide the user with a hash and ask them to insert it into some field of the their public profile. Putting "aTWIUqHRgxEpSVaQzCYc" in the location field of my Stack Overflow account for example and then having the application verify the hash via either API or screen scrape depending on the website.Problems:
This is tedious to do for more than one or two websites.
Some sites don't have any sort fields with user supplied information. Reddit for example.
Again, provide the user with a hash but ask them to send that hash via the website's message system to a specified user account. A server process would routinely check that account's inbox and then link the hash with the account. This seems like the easiest solution.
3B. Have the user friend the specified account when applicable.
I've not yet done enough due diligence investigating what options OAuth or OpenId might provide to speak intelligently about them.
I realize the headache of having to verify accounts this way is going to cause a barrier to entry. Not only that but failing to have a single consistent method for doing it.
I would go with OAuth / OpenID, there is a gem called omniauth and it supports a wide variety of external providers. Ryan Bates has made 3 railscasts about omniauth so you could start there! It's really easy to get it up and running. If you follow the railscasts by Ryan Bates you can allow your users to use more than 1 provider (e.g twitter, openid and facebook).
Related
I work for a company where we give customer (hundreds/thousands of users) access to 2 sites. One owned by a 3rd party SaaS and one owned by us.
Customers spend alot of time registering for both sites and we also spend alot of time removing accounts when customers no longer need access.
I would like users to register for Site A. After successful authentication; a user can click on a link within the site to access Site B but without the user entering credentials.
I want Site A identity to be used to access site B and its resources. I do not need site B resources to be presented on Site A site, but simply allow users to access site B if already authenticated to site A.
Users may have different roles on site B.
What is my best option? Oauth2 sounds like a good option. But will it satisfy my requirement above?
Who will manage the authorisation server? I presume Site B?
Thank you.
Two main options:
OLD TECH WITH COOKIES
Perhaps the cheapest option is to use hosting domains and have 2 apps like this:
mail.google.com
drive.google.com
Use a cookie issued to the parent domain, google.com
Cookie identifies user, to provide a user id
Rights are looked up in each app from the user id
OAUTH2 AND OPENID CONNECT
This is the option for modern apps and they are usually used together, due to being web, mobile and API friendly.
It is a big job though, including user migration, and usually involves giving users a new password. So it needs to be something your company are prepared to invest in.
The Authorization Server (AS) becomes a shared central resource and it is common to use a Cloud Provider to ensure high availability.
RELATED RESOURCES OF MINE
Initial Code Sample with Cloud AS
User Migration Blog Post
More specifically, I mean being able to provide an OAuth2 service.
I've seen multiple websites used "Sign in with Twitter" "Sign in with Google" etc.. on their websites. I'm wondering if there's a certain process you need to go through in order to allow other websites to use your websites to authenticate.
Let's say I've got a website called "SomeRandomSite", and people can sign up/sign into this site as they normally would, but then if you go to some other website you'd see a "Sign in using SomeRandomSite".
When looking into it, I came across this article here:
http://scottksmith.com/blog/2014/07/02/beer-locker-building-a-restful-api-with-node-oauth2-server/
I have yet to finish reading all of it, but so far it seems like it's only allowing your application to incorporate other OAuth services such as Google, rather than building your own.
I hope I explained this well enough haha.
Implement OpenID Connect if you want to make your server behave as an Identity Provider (IdP). You can find a list of implementations of OpenID Connect in "Libraries, Products and Tools" page.
It basically means you want to act as an IdentityProvider, take a look at ThinkTecture.
https://identityserver.github.io/Documentation/
It's cetainly possible, but an Identity provider is usually a well known(trusted) party, between the IdentityProvider and the target site the user want's to log into there should be a trusted relationship, in other words the target site should register with you the IdentityProvider
Getting started example
https://identityserver.github.io/Documentation/docsv2/overview/simplestOAuth.html
My understanding of OpenID is that it provides a way to have one site contain all your identity & peripheral info, but to let other OpenID-compliant (and user-trusted) sites re-use that info for identifying and authenticating the user. Essentially it minimizes the number of logins credentials (usernames & passwords) a user has for the internet.
My understanding of OpenSSO is that it allows you to sign-in to one site and automatically log-in to all other sites that the first site trusts. Essentially it minimizes the number of times a user has to log in to these different sites.
My understanding of OAuth is that it allows users to grant 3rd party sites certain access to their information located at one particular site. Essentially, like OpenSSO, it minimizes the number of times a user has to log in to these different sites. The different with OpenSSO is that OpenSSO logs the user into all the participating sites at once (with full privileges turned on), whereas OAuth grants finer-grained access to these participating sites.
So, first off, if anything I have said is incorrect, please begin by correcting me!
Assuming I am more or less correct, then I have the following questions/need clarification on the following items:
When would I choose OpenSSO over OAuth - just when I want to restrict access that the other participating sites have when a user logs in to one of them?
Are their different security risks for each of these technologies that I will have to consider and integrate into my app - or are they considered secure in and of themselves (basically can I rest assured that if my app uses them that my app is not open to any new attacks)?
Since these technologies are so closely related its hard for me to see the whole "forest through the trees" here - thanks in advance!
Not really the right comparison to be making. OpenID & OAuth are protocols, OpenSSO (now OpenAM) is an implementation of those and other protocols (SAML, OAuth, etc)
Generally speaking, the protocols for OpenID and OAuth are similar even though they originated with different use cases in mind. Today there is a lot of convergence around OAuth 2.0 for both federation (authentication) and authorization cases. The next generation of OpenID called OpenID Connect is built on top of OAuth 2.0 and precursors to this are already in place at Google, Facebook, Twitter, etc...
As for security, there are always some risks, particularly with implementation errors. Pick a good implementation and read the specs so you understand what the risks and countermeasures are.
OpenSSO is for you to log into one site and be logged into multiple sites.
OAuth lets one site extract your data from a second site (pull your tweets or facebook statuses) without the first site having to know how to log into the second site.
I'm building a standalone couchdb application. These are called couchapps. The idea is that the database itself is served on port 80 and returns HTML and works as the actual website. This is a very powerful idea and I'm entirely amazed by this new concept of having your code live inside your database.
But I'm having some issues with user registration. The one built into couchdb allows for cookies to be set and makes it really easy to plug it into your website. But there's several quite important things missing that my app requires in order to say that it has a "proper" user registration system.
There's no signup verification. No email is sent, no captcha is displayed. This means that anyone could spam your _users database and create as many new users as they please.
If a user forgets their password there's no facility to help them recover it.
Any idea how I could overcome these issues without doing any hardcore Erlang development at a lower level (not an Erlang guy)? It would also be great if anybody knew if I could be using OAuth to authenticate against Twitter or GitHub accounts and have that integrate seemlessly with how couchdb data is handled (inside validate_doc_update functions).
Thank you
While the built in user database can work, I would not recommend it for the workflow you describe. Here are some other options:
Browser ID
I would really recommend using BrowserID. IrisCouch has provided a plugin to couchdb here:
https://github.com/iriscouch/browserid_couchdb
This will take care of the normal registration workflow.
If you want to take it a step further and have your users "Fairly Anonymous", you can follow the example of this couchapp called "Mingle"
https://github.com/thedod/Mingle
Twitter Integration
Max Ogden's "DataCouch" project has a log in via twitter, although it is using some Node external processors to make it work. See here:
https://github.com/maxogden/datacouch/blob/master/processors/auth/twitterauth.js
Facebook integration
https://github.com/ocastalabs/CouchDB-Facebook-Authentication
OpenID
https://github.com/mcaprari/couchdb-openid
I dont think you can use the oauth purely with Couch, as this post suggests:
http://bennolan.com/2011/01/11/couchdb-oath.html
so the closest you will get there is following what Datacouch has done.
Hope these suggestions help.
I am trying to develop a very basic console application that will retrieve a user's homepage (twitter updates from people followed by the user) and save it (json). I've read a lot on the internet, but still am unsure of whether i need to 'register' such an application, and if yes, how could I possibly do it for a console app.
I'd like to get a step-by-step rundown on how I should proceed with the development. Its just a tad complex for a noob like me in this field. I'm aware that off-the-shelf libraries for doing this job are aplenty, but I lack a general understanding of how I should approach this.
Much appreciated,
Abhi
The answer really depends on a few things.
If your application is not going to try to access information about protected users (users can opt to be protected so their information and tweets are kept private) your application will not need to be authorized by any user and will not need to be registered or deal with OAuth. Without using OAuth, you will be limited to making 150 requests per hour, per IP address.
If your application needs to make more than 150 requests an hour, or needs to access protected user information, then you will need to register your application and make requests on behalf of a user. This user could be your twitter account. This will give you up to 300 requests per hour per authorized user.
I can't give you much detail as to how to best write a console application with TweetSharp., but I am familiar with Twitterizer (I wrote it).