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?
Related
So I have been looking into OAuth lately, I want to authorize another of my domain which has separate database using OAuth. Upon searching I found auth0.com. Which sounded similar to Oauth and I created a sample implementation, it offers support for custom databases also. We have users stored in external api running on .net core, and I learnt that auth0.com is not free after trial expiration. So my efforts kindof got wasted. Now I am looking for authorization method that works for both domains.
Now my question is, does it even make sense to use Oauth for this task? Since I won't be giving it to third party and it's matter of two databases. How should i approach this and what are opensource Oauth services that allow custom database.
Cause i'm new to the whole angular (specific angular2) thing i wonder about something.
I want to build an "api" backend with rails 5 as they released the api mode and my frontend with angular2. Because i'm used to rails i wanted to implement a devise user authentication and because i'm new to angular2 i searched for a way to authenticate the user against my rails/devise backend.
But all i find are tutorials about angular2 and auth0, which i never heared before.
So my question is, is it "normal" to user angular2 with auth0 authentication?
And when i use auth0 my user data are not in my database right? So how do i create relationships with my rails models?
Would be great if someone can explain that to me or link me some article if they exists.
Auth0 is one of the many choices available to you. If you'd like to use Auth0 but store credentials in your own database, there is a tutorial for setting that up with Auth0.
So it can be normal to use Auth0, and you can also have your user data available in your own database-- do keep in mind you'll need to secure user credentials thoroughly when storing them yourself though!
I've also faced the same problem and considered Devise (going so far as setting up a Rails+Devise landing page that redirected users to the Angular app after successful login). After much pain I have come to the same recommendation as Kassandra, that using JWT authentication is the way to go.
However, if you plan to use Auth0 note that after 7000 users have signed up you will need to upgrade. This may not be a problem for you but since I plan to deploy something substantial it's a decision I had to think about.
I am reading the Service Oriented Design with Ruby book by Paul Dix and many posts here but am left with many questions surrounding authenticating users and the application.
I want to have api.site.com as a RESTful Rails app serving up JSON. Secure.site.com will be a web app (maybe Rails or maybe PHP) that will consume the service. Also a mobile app such as iPad will also consume it.
So is the first step to build in a level of auth so that only my web app and mobile app can consume the service? Then once the calling app has been authenticated, both these apps will have users who want to CRUD their data so then authenticate them as well?
I've read about Http basic, digest, tokens, oauth and many plugins but am having a difficult time narrowing down the most flexible and reusable way. For now this is simply learning so I would like to stay away from plugins so I can learn the code better.
Can my web app use normal sessions like I'm familiar with and then the mobile use their equivalent to sessions. At that point I still have no authenticated the calling app though. Http basic seemed like I could use it from both, but I didn't see a way for my web app to use a normal login form and logging out seemed like an issue.
I would suggest two solutions for you.
Use a Gem like devise for login system and inherit the devise registration and sessions controller to make it respond to JSON requests.
Create your own simple authentication and use respond to HTML and respond to JSON for separating web and mobile login
Iam not totally sure whether a mobile device maintains a session (please look around) but u can always use a token authentication system if it doesnt.
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.
I'm building some applications using rails.
All apps using restful auth plugin for User base and declarative authorization plugin for authorization rules.
But I need to merge all site's User accounts to one User base for providing login for all sites.
I.e like 37signals working on. Here is their work ;
http://37signals.com/accounts
How can I archieve this, any suggestions are welcome.
Thanks
A.Karr
From studying how 37signals was doing stuff - I think they're using RubyCAS http://github.com/gunark/rubycas-server
It's perfect for single sign-on, single sign-off and other related stuff - when you have multiple independent applications. Also, because CAS is a generic protocol, it exists for non-ruby/rails applications too. SO you can integrate legacy systems or client applications in Java etc.
I started building a set of how-tos on the subject here:
http://rubyglasses.blogspot.com/2009/12/rails-single-sign-on-with-rubycas.html
Have you thought about using open id?
If all your apps run on the same domain you shouldn't have any problems accessing the authentication cookie in all the apps, but you'll need to store the authentication state somewhere where all the applications can access it.