Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I am doing Facebook integration to authenticate users and with my Ruby on Rails application. I've been going through tutorials available online and some SO posts.
I've come across some ways to do this, and most of them talk about what is explained in this post from last year. http://railscasts.com/episodes/360-facebook-authentication?view=asciicast
My questions are:
Can I do with just client side integration?
Why do I need server side integration?
What are the pros and cons of choosing one?
What are the benefits of doing both?
What is the best way to do Server side integration (which gem/gems)?
Can I do with just client side integration?
By Client side integration I'm assuming you are referencing simply using FB javascript widgets like the facebook like button (https://developers.facebook.com/docs/reference/plugins/like/). You can definitely do this, and it will not require your users to "authenticate" to your app at all (ie. go through the oAuth process of giving your app permission etc.) Instead, it will simply pop them to the facebook login page and post directly on their wall/like etc.
Why do I need server side integration?
As a continuation to the answer to the first question, sometimes you may want actually want the user to go through the oAuth process so that you can do other things server side. This may include (depending on what permissions you ask for) getting information like an email/picture, country/etc. of your user. Or perhaps it has to do with implementing a particular feature such as for example pulling friends of friends and seeing who is currently using your app.
What are the pros and cons of choosing one?
Both are acceptable ways of integration with FB, but using the JS widgets isn't really a login integration, its simply a redirection to FB for them to perform some action. If you really want to enable someone to "sign in with facebook" on your site, you will have to use server side integration (ie. oAuth)
This in turn means that after the oAuth process, you will have an "authentication" (ie. a token) that represents the user from FB tied to the actual "user" object in your server side database.
This is useful for many reasons, as outlined above. If you do not need to do complex things, but just want someone to be able to "Like" something, or "Share to wall" you may not need server side integration, but again as mentioned - if you do need "sign in with facebook" at all, it is definitely oAuth and will require the server side integration.
What are the benefits of doing both?
Lots to say here... but pretty much see above for answer, can go in to more detail if you have more specific questions.
What is the best way to do Server side integration (which gem/gems)?
It would depend upon which gem you are using for your authentication. Personally, I've had great success with the Devise Gem and its built in support for the Omniauth Gem. You can read more about that integration here: https://github.com/plataformatec/devise/wiki/OmniAuth:-Overview
The question is a bit vague. If what you mean by integration is authentication then the answer is the only difference is that the client side version needs javascript to work, whereas the server side version doesn't(and implementation is slightly different).
The best way, in my opinion, to do any kind of facebook work in Rails is the Koala gem(which uses Omniauth). It's really well documented and it makes navigating the terrible FB API almost bearable.
Again, if what you asked about is authentication then there is no difference. With Koala/Omniauth you can extract user info from the cookie produced with the JS SDK, just as well as you do by using the server-side redirect based login.
Related
I'm working on building a closed community forum for members of an existing site I also built. I'd like to allow members to sign in to the new forum using their existing accounts on the main application. The forum will be on a different domain from the main site.
This will be my first time using OAuth. Most information on the web about it seems to skew heavily toward allowing users to sign in with Twitter/Facebook/etc accounts, and there's very little information that seems pertinent to what I'm working on.
I'd like to create an OAuth provider in the original web app and a OAuth client in the new app I'm building. No other providers will be used, and no other client sites will be authenticating off this main site. Additionally, I need to avoid any sort of "authorize this web site" intermediary step for my users.
The main site is Rails 4 with Devise, and the new site is Rails 5. I'd like to stick with Devise on the new site as well, which I understand can function as an OAuth client. Doorkeeper seems like it could be overkill for my exceedingly simple needs, but most other information I've found is years out of date, so I don't want to invest time pursuing an implementation that won't work or is not the current best approach.
What is currently the best way to handle this kind of single-client, single-provider setup?
Let me make this clear from the beginning: I'm a complete noob regarding oauth2 and not a dev (just monkey interested in tech stuff) so the question might be silly. If so please don't hesitate to smash the monkey as he truly deserved it...
Since I wanted to get a better understanding of how oauth2 is working I wanted to setup slack within emacs. This is not my first project with oauth2. I managed to get offlineimap working with gmail using oauth2. However, google did one step automatically with which I'm struggeling right now for slack.
My question is all about the redirect url. Google did setup this for me pointing to my localhost. Now slack doesn't do the job for me and since my localhost isn't reachable form the outside (of my home network) I need to setup a way to securely get to my localhost.
How does google set this up?
I came across ngork which looks to me like a solution to my problem. Again, I've never heard / used it before. I think I would be able to get that stuff up and running but I would like to know:
Is this a safe and secure solution? To what should I pay attention?
"Is this a safe and secure solution?" is a very broad question and you can surely find a lot of discussion and opinions on this forum on how safe VPN tunnels for HTTP are in general and ngrok is in particular.
So the answer is: it depends on what your requirements are. Any other answer will be opinionated or will have to make assumptions about your requirements, which you have not specified.
Having said that:
If you want to use it for local development (incl. Oauth) ngrok
appears to be safe enough to be recommend by the Slack team for
local development (see tutorial).
If you want to use it for a production environment and/or in a
company network I would recommend to verify with the responsible IT
security officer before using it. However, it is a professional and
well-known product used by many companies, so you should have a fair
chance that it gets approved.
I have not used Google Oauth, but in my experience with other Oauth services its pretty standard that its calling you via a redirect URL.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 3 years ago.
Improve this question
So i'm creating an app that really only communicates with one other rails application besides for some remote touch screens. The app is only available to individuals who own one of these touch screens, and an admin. Therefore, I really don't see the point in being able to sign in with twitter, facebook, etc. However, I need SOME sort of http authentication using request/access tokens in order to 1. authenticate a user and 2. be able to derive what user is communicating with the server (and when). I've spent about a week (I'm a rails newb) researching Oauth, omniauth, etc, and I'm asking two things:
Because Im authenticating between my own two sets of apps, what gem would be best for my situation?
Where would I write the logic for request/access tokens?
I really can't find any good tutorials for this
If you don't need any kind of integration with existing identity providers, then Devise is all you need. It provides a simple way for you to manage user accounts, and users will login using their email addresses and passwords.
It gets trickier to authenticate against another app.
Method 1
If you don't need much communication between the two apps, you can have the user login to the main app, then generate a temporary token that the user can use in the secondary app. Finally, have the secondary app include this string in all communications with the main app. Real world examples include Pivotal Tracker, which gives users an API key that they can use in web hooks on GitHub.
Trivial Example
User goes to Main.com and logs in using email and password.
Main.com generates a temporary token for user.
User gives token to Sub.com.
Sub.com contacts Main.com using <user>:<token>#main.com/some/path?some=query
There are many security issues with this, but it's good enough for non-critical use cases. You might want to use SSL to protect the tokens.
Method 2
However, Method 1 is not very secure. A more robust and secure solution is to make the main app an OAuth provider, and then have the secondary app authenticate against the main app using OAuth. Here is a Railscast that explains how to do that with DoorKeeper. You can use OmniAuth in the secondary app.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
So I'm building an application in Rails 3 using Devise as my authentication mechanism. I have all my controllers and views working. Our web site is humming along. Now we'd like to export our routes to 3rd party developers. The problem is how.
Here's the list of things I think I need to figure out.
Third party authentication. I am trying to get it straight in my head what I need to do. We have an existing user base and tokens have been generated for all of them with the Devise authentication model. Now I need to provide some kind of security. My current line of thinking is to set up an OAuth Provider to manage private keys and then somehow set up our web app as one of the applications the 3rd party developer can gain access to. Is that the correct line of thinking or am I over-engineering it?
Generate public facing documentation for our REST endpoints. While the rake routes is nice for internal developers, I really think we need something more along the lines of swagger-ui. the problem is rails doesn't generate the appropriate json/xml calls for swagger-ui. Which as I understand it are required in a true REST service. Such as resource listing, and operations listing on a resource.
Thanks in advance for any direction you can give me in these arena's!
I'm biased about Swagger (I work on it at Wordnik) and will point out that we'll add ruby server support to automatically generate the description layer like we do with Scala.
I would definitely recommend OAuth if there is a security element for your users. That is, you want someone to be able to edit multiple users details via their service then used 3-legged OAuth (Provider, User, Client). Otherwise go for the 2-legged OAuth (Provider, Client.)
If you want to implement a 3-legged OAuth API then I wrote a tutorial which is available here. It uses Devise and Oauth2.
As for the documentation, I would go as far as to write custom documentation instead of relying on tools. Twitter have a very well documented API, I use that as a basis for the RESTful APIs I write.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How to logout from Relying Party?
Why DotnetOpenID have not implemented the logout from Openid Provider ?
There current version is DotNetOpenId-2.5.5.9153 and DotNetOpenAuth-3.1.0.9122
Are they planning to implement logout in next version ?
I'd say this is more or less a duplicate of your other question. I've posted an answer there. In short, DotNetOpenId doesn't implement single-sign out because the OpenID spec doesn't explain how it would be done. No OpenID library offers single-sign out because it doesn't exist.
For instance, a user probably wants to sign out of the RP, the OP, and all the other RPs that were signed into during his session when he steps away from the computer. But exactly how to interact with so many web sites at once from a single user gesture just hasn't been fully figured out yet.