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.
Related
I am trying to understand in what scenarios I should be using oauth. From reading the spec, I understand that you are essentially delegating identification to a 3rd party.
So if we take the example stackoverflow's login page you get
Oauth2 is being used for google and facebook, how do I determine what stackoverflow is using (when entering username and password directly)? Would that also be oauth 2? If it is using oauth, how would I go about understanding which flow they use?
Your question is a little unclear but what I think you're asking is if SO or some other site uses oAuth for all their authentication schemes. They could. If they using oAuth with user password authentication when you authenticate, the response you get back should have an Authorization Token and a Refresh Token in it that you would then use to authenticate on each successive request. Hope this helps. oAuth isn't a technology it's a protocol on how to do authentication in a better way.
See what is the request URL when you click to log in with gmail...
https://accounts.google.com/ServiceLogin?passive=1209600&continue=https://accounts.google.com/o/oauth2/auth?client_id%3D717762328687-p17pldm5fteklla3nplbss3ai9slta0a.apps.googleusercontent.com%26scope%3Dprofile%2Bemail%26redirect_uri%3Dhttps://stackauth.com/auth/oauth2/google%26state%3D%257B%2522sid%2522:1,%2522st%2522:%2522e35d652c26ae7fad9b61f6176cc93f2eb9bbb240c32231bc95f8270176d7a5d5%2522,%2522ses%2522:%252291fdf487240d4fa38576f780ad448f55%2522%257D%26response_type%3Dcode%26from_login%3D1%26as%3D-8520e47ae71bbb4&oauth=1&sarp=1&scc=1#identifier
Does that auth2 means oauth 2 ? I think so
UPD: As I understand OAuth mechanism is supported by 3-rd part. SO could use their own oauth for direct enter, or standard auttentication. It is up to SO.
To keep it short and easy:
If you want to add authentication to your application and you want to leave some security heavilifting to big companies like Facebook, Google and Stackoverflow it is generally a good idea if you do not know precisely how to handle such a delicate task and/or you are not using a specific Auth tool / framework.
On the other hand, from the user perspective, the application will be far more user friendly (just one click authorization instead of a painful registration).
If you want a much more detailed technical explanation I suggest you to read this other Stackoverflow post:
OAuth 2.0: Benefits and use cases — why?
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.
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.
I'm designing a new web application. Some quick points on it:
ASP.NET MVC Web Application
SQL Server 2008
Entity Framework ORM
3 User Roles: Anonymous, Registered, Administrators.
Anonymous users can view stuff, Registered Users can post stuff, Admins can do anything
Heavy social integration with Facebook, Twitter and the like.
I plan to use OpenId for authentication (DotNetOpenAuth)
So, pretty simple right? (famous last words)
Now my question is:
Should i provide OpenId as the only means of authentication, or should i
also give the user the option to log
in using my own authentication system?
So this is basically a "User Experience" question. Take the example of StackOverflow - you MUST signup with OpenId. It seemed fine to me, but what about the general public? Can i be happy with the fact that a user of my site must have an OpenId account? (or signup for one before using my site)
Is giving the user two options to login bad UX?
I realize this is a partially subjective question, but im just looking for advice on which road to take, some case studies would be helpful.
Thanks.
Any good answer to a subjective question begins with it depends. :-)
I think if your prospective user base is already fairly social-network engaged (as it sounds by your description), it will probably be just fine to have authentication handled by OpenId providers. The important part is providing an easy-to-use login process, and make it obvious that various providers are available for authentication (Yahoo, Google, etc.).
If your prospective user base is going to consist of new or inexperienced Internet users, even a simple OpenId implementation may be too confusing.
I, for one, find it annoying to have to create yet another account every time a visit a new website, and I suspect that more and more users are feeling the same way.
There's a decent set of responses to a similar question at https://ux.stackexchange.com/questions/78
The thing is that only OpenID won't cut it in you case mainly because of Facebook and Twitter who aren't OpenID providers. Both use OAuth 2 for authetication. Wikipedia says this about it:
OAuth (Open Authorization) is an open standard for authorization. It allows users to share their private resources (e.g. photos, videos, contact lists) stored on one site with another site without having to hand out their credentials, typically username and password.
and this:
OAuth is a service that is complementary to, but distinct from, OpenID.
The DotNetOpenAuth also supports OAuth and the latest CTP release implements the OAuth 2 draft 10. Mind you that the OAuth 2 specification is still being developed and is expected to be finalized by the end of 2010. OAuth 2 also isn't backward compatible with OAuth 1.