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.
Related
I need to create a very basic log in system to allow access to an admin portal.
I'll need to hold email, password and a field to identify access level (admin, read-only or edit).
Users will be created by an admin, where they will get sent an email with a generated password. There will be no user registration page.
Asp.net core Identity would handle all this...but my question is it overkill for a small application?
That is really a matter of opinion. I don't mind overkilling small tasks, as I learn a lot in the process. If it's a system between a small group, you could just implement a reset-button for you, that resets whoever you want, and generates a new random password. I have done that in the past.
Also .Net Core Identity handles a lot of the boilerplate code, so it's not that difficult to implement. There are a lot of great guides out there.
...but my question is it overkill for a small application?
Depends on your definition of an overkill.
It will allow you to setup working identity system in a few clicks, so from that point of view, having to code all that stuff from scratch would be an overkill.
On the other hand, the generated tables have a few excess (for your use case) columns that might seem like an overkill. There is also support for functionality like 2FA, which you may not need.
Bottom line: by choosing to use the identity system, you save time and gain some extraneous functionality.
I have been using .net for a very long time, and for a long time implemented custom user management (overriding built in providers, and customising to my own database structures etc) This is required if implementing over legacy system but for new development and security, it worth using off-the-shelf authorization/authentication systems whether it's built in or supported by .Net or using 3rd party services.
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.
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.
This question is an open question since it's not bound to a programming language:
Is it a bad idea to provide users an auto-login feature? Why?
I've been reading a couple of papers arguing that auto-login feature on web development leads to many user having trouble with "hijacked" accounts. However, I would like to read a real answer/comment from someone with experience on this matter.
Well, I think it totally depends on the audience which is consuming the services you are providing.
If you are in an intranet environment, then it is a good idea to enable auto login features. Provides more luxury to the users. But still you must check in the background the application access level for each particular user.
In an internet environment you have much less control - more likely to say no control - of who is going to use the application. Therefore there you should have an authentication mechanism in place and do not provide any auto-login features except through cookies.
HTH