I'm starting a new project that depends on social networking platforms very deeply, so I have decided to avoid the normal registration-login mechanism and allow the users to create accounts by using Oauth or similar methods provided by services like Facebook and Twitter. I'm clear on how to implement them but I'm not clear on how my database and the front-end should be.
I'm looking for a theoretical solution because I might use this mechanism in multiple projects using different technologies.
Related
I'm building a web application in Golang, and at the moment I'm struggling with the authentication/authorization mechanisms.
I want to deploy this app to different platforms (browsers, androids, etc). To achieve this I chosed to use oauth 2.0, namely this lib: https://github.com/golang/oauth2 .
The problem I'm facing is how to achieve this with my own database and users. The lib has a jwt package (https://github.com/golang/oauth2/tree/master/jwt) and also has a package clientcredentials (https://github.com/golang/oauth2/blob/master/clientcredentials/clientcredentials.go) that can be used for 2-legged Oauth 2.0, but I have no idea how to achieve this, and can't find any example showing it. Which package should I use? The token should be set when user sends a POST with its credentials at http://example.domain/login.
Can someone provide me some hints / show me a simple example?
Have you explored solutions such as ory/hydra, which will handle everything OAuth2/OpenID related and let you handle user authentication?
Implementing your own OAuth2 provider is dangerous territory. It only takes one misread RFC and BOOM! Security vulnerability. It's typically better to entrust that responsibility to established security experts or lasting projects as opposed to home-grown remedies.
Of course, this isn't to say that everybody needs to jump onto the hype train and use this cool new software. In fact, I would urge the opposite: if you are a competent security analyst and feel comfortable writing an OAuth2/OpenID Connect implementation, go right ahead! But us normal people who don't want our hair to gray before we are thirty will use existing technologies to our advantage.
We have a web platform with 5 sites. Authentication is implemented with login/password only. My management told me that we need to add social login with Google and Facebook and for it I should look to Auth0 solution.
I checked it, it's look quite interesting but could somebody give me the real benefits of it's integration to our system what is quite difficult today? Price for 10 000 active users is 1440$ per month and I'm asking myself if it is really so difficult to implement social login?
In past, I created myself a simple prototype that logins with Google, it did not take a lot of time.
I suppose that everything is not so simple, so what am I missing and why do we have to buy this solution instead creating something simple ourselves?
I stumbled upon this question when I was researching about using Auth0.
I came to these conclusions, but your mileage may vary.
Here are some of the pros of using Auth0:
Almost any webapp you use is going to implement authentication. This is table stakes and there are lot of cookiecutter solutions for various frameworks, but can be hard to get it right and secured. One less thing to maintain and worry about when you are building your product. Their starter free plan is sufficient for most startups' needs.
Auth0 has got SDKs in various languages and a ton of documentation. Its easy to integrate it with your application.
It provides compliance with various standards(Ex: HIPAA), if that's a key requirement for your product.
Auth0 is not without its disadvantages. Remember that you are offloading your entire user data to a 3rd party app in exchange for flexibility. They do offer a way to migrate this data back to your app in case you need it, thus avoiding any vendor lockin.
We're working with Cumulocity and we'd like to offer services to our customers that are not currently possible to implement with Cumulocity. As an example, we'd like to be able to retrieve a list of devices located within x kilometers of a given point.
Currently there are two limitations that prevent us from doing so:
the impossibility of extending the Cumulocity API with custom route/parameters
the impossibility of implementing custom functions for specific API GET calls
I can think of a workaround to achieve this, like a POST request of an event that would be processed by an Esper rule, generating another event/measurement that could then be accessed by a GET. But I think we can agree this is not a suitable mechanism.
Please not that the use case I described above is just an example. Our needs don't limit to this and we need a standardized way to expand our services without requirering updates on Cumulocity side.
There are two topics here, I believe:
Geo-querying: Some geographical querying and aggregation use cases can be handled through CEL. A general geo-querying API is on the Cumulocity roadmap. Note: This use case is not only related to extending the API, as such queries go right down into the database.
Extending the API: That is actually possible. Cumulocity has a microservices API in which you can expose other APIs under the URL /services/.... This is, for example, how connectivity platforms are interfaced. The API is not on the web site because it's not GA yet, but you can certainly discuss it with your Cumulocity contact or open a ticket. This btw includes also adding permissions for the new microservices, so that you can do proper A&A.
As the title suggests, I am not sure how an Authentication Server works. I have implemented authentication on multiple websites but it hasn't ever sat on a separate server. So, how would this architecture work? Is there material online that can explain this (I couldn't find any)? Advantages/ Disadvantages of this approach when compared to an implementing authentication on the same machine.
Having different authentication systems per application would land the user to create multiple profile which could be cumbersome for the user. Also architecturally you are creating tight coupling between application and authentication.
You should consider & design authentication as a simple Service/API call, this would help you in removing the coupling, achieving re-usability and maintainability. Following are few benefits of Authentication as a service or separate system:
Isolating Authentication system would create a path for implementing Single Sign On feature.
Implement changes and testing would be easier.
You can have the road-map to apply standardization in elegant manner.
In future your authentication can also handle authorization responsibilities.
When you change your Authentication system to a new IDAM solution, the impact on the business applications is reduced or eliminated.
You can find lot of Identity Access Management Solutions in the market which are pretty much industry standard. I would recommend you to research on SSO & IDAM products, which should give you comprehensive idea about the above mentioned points.
I have a web app implemented in Ruby on Rails 4, need an Android native app for it, I am really new to mobile development.
I am a bit confused as to what the mobile-web architecture should look like in this case. I've done some research online, there seems to be a few ways of doing this, but I still have some questions that I haven't been able to find answers for. Thanks in advance for all pointers.
1) do I really need a separate API for the mobile app? what are the issues in using my Rails app's existing controllers with respond_to format.json?
2) I've seen some online examples that suggest using an separate API namespace in the Rails app to serve mobile requests, e.g class Api::ApiController < ActionController::Base for the new controller, then add namespace :api do in routes.rb. With this approach, doesn't it imply that I'll need to duplicate quite a bit of my controller functionality in this new namespace just for mobile?
3) Regarding authentication, many examples suggest using token authentication, is the built-in Rails sessions management framework not good enough for mobile apps? or is it because session cookies work completely differently in a mobile app?
Appreciate your time.
It is not necessary, but it is, like you said, considered a best practice.
1+2) Having same controllers with respond_to/respond_with logic is a nice idea at first sight. But, from my experience, I can say, there always comes a day where API code start to differ with HTML client code. The mobile client might have a different UI and it is just natural that it will expect to consume your data another way as your web client does. The web client is specialized to one use case where an API should be more generic allowing multiple consuming ways.
The second issue that will arise is the fact that you cannot rely on your mobile users to always have the latest app version where with a webapp you can. So for the HTML app you can easily introduce non-compatible changes because you are delivering a proper client right within where for the mobile API breaking the API is at least concerning. Perhaps, you will want to maintain a backwards compatibility which will make your all purpose controllers ugly as hell. And without a proper api/v1 namespace you even can't have two different API versions at the same time.
You can avoid duplication of your logic by keeping your controllers very skinny and move the logic out into models (Service Objects are models too, not only Active Records).
3) Your mobile HTTP lib will to a high probability have a proper automatic cookie management. Having token based authentication is just again a best practice. If it is just a token vs session_id within cookie, there will be not much win. I can only think that it will be automatically secure against CSRF attack and you can disable this protection entirely for the API because your website users won't be allowed to consume the API, just by logging in to the site (an additional benefit perhaps). With session based authentication you will have to generate a CSRF token on first API request and set it within X-CSRF-Token cookie.
The big advantage of token based authentication is that it is extendable to more security, like introducing expire tokens, HMAC tokens etc, whereby session authentication is not.
See Using Sessions vs Tokens for API authentication
I would also encourage you to look at json:api. It comes from the creators of ember.js, who have thought about minifying decisions to take, when building APIs. Another interesting thing is an active_model_serializers gem. An intro to it is given within Rails: The Next Five Years by Yehuda Katz