Authentication with website, mobile app, and webservice - web-services

I am creating a service that will include a website, a mobile app, and a web service.
Both the website and mobile app will talk to the web service to interact with the database and any other backend items.
I would like users to be able to log in with other services (such as google, facebook, twitter, etc.)
I have two questions in implementing this:
1.) Should I use OpenID or OAuth? I'm not sure which is better for the situation. I have no need to actually access features from a users account, I just want them to be able to log in with accounts they already have,
2.) Where should I implement the authentication? Do I have to implement it both on the website and on the mobile app, or could I have both talk to the web service and do the authentication there?
Thanks

If you are just doing authentication and not syncing any account details, I think OpenID is the way to go. From a security standpoint, I would say to implement your authentication on the website and on the app and not in the webservice. You want to handle credentials the least amount possible and especially avoid sending the credentials via webservice if not using SSL.

Related

When you use DRF(Server API) + React(public Web Client), how do you implement for OAuth2 social login?

I am developing Django(Server) with React(Web Client).
And I want to use facebook social login.
I knew that client is public client, server is confidential. So I want to use authentication code grant way for authenticating user.
So I find out the way but there is no way to implement that. All the python oauth2 library limplements is just for django server side rendering.(Django Server + Web client).
So I confused about I am wrong or just the others just did not make the grant way.
When you use DRF(Server API) + React(public Web Client),
how do you implement for OAuth2 social login?
I wonder that. please give me some advise to me.
Thanks.
Let's start from basics, people usually split frontend and backend to improve the production speed as frontend and backend can be developed by two separate teams. But in order for the frontend and backend to work together, there needs to be a connection interface, an API.
React is a frontend that runs in the browser, so in order to talk to the server, it uses a REST protocol.
As the backend in this scenario is Django we use DRF as React uses REST API. DRF provides easy flexible pre-built packages to carry out this communication job between server and client.
Now the authenticator for web login you choose to be Facebook hence you will get the identity token from facebook, which will correspond to the rows in the Django User table which will give you access to the user's data in Django.
You don't need to do everything at once, you need to first implement the Facebook social auth and after test(test using postman app) only think about connecting React
A good place to start is this DRF documentation, look into Social OAuth2
https://www.django-rest-framework.org/api-guide/authentication/#django-oauth-toolkit

User authentication in java web services

Im developing a java web application which is deployed on a glassfish server. The web services are used to connect to user databases. Each user has a database. My question is, is there a way to keep track of the user? For example in servlets we use sessions in order to store some user specific data. Is there something similar to it in web services? It seems impractical to have to authenticate the username and password each time the user sends a request to a web service. Thanks.
Web services may also use sessions, however there are good reasons to keep them stateless:
it might be that the clients do not support sessions (cookies), e.g. if your clients are not browser based;
stateless services are easier to scale.
You do not have to use username+password for authentication. You may use JWT (or other kind of access tokens) to protect them.
Auth0 has got nice article on this topic:
https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/

SSO solutions for Django

I have several Django websites and I want to create a centralized auth provider. The auth provider site would contain the user accounts and be the only repository for user details and passwords. Users would log into the auth provider site and when they visit each satellite website for the first time, an account is created on that site. Subsequent visits to the satellite site would result in them being sent to the auth provider site to login first. On returning they are automatically logged in to the satellite site. My only difficulty is that the auth provider site would be on the internet and the satellite sites are in DMZs on private networks with access to the internet. So the satellite sites cannot establish any outgoing connections to the auth provider.
I still need the ability to log into the satellite sites using the locally configured admin user.
I looked at OAuth2 but I don't think that fits my needs. I'm currently reading about OpenID but I noticed a comment that the satellite server contacts the OpenID server, which cannot happen in my configuration. When I say OpenID I mean that I would have to run my own server as I need 100% control over the users. Are there any other solutions I've not mentioned yet that meet my requirements?
Thanks
What you're looking for is essentially SAML.
Unfortunately, I'm not aware of any good off-the-shelf open source solutions for this.
If you're looking for a service solution, the company I work at (Stormpath) provides a library that does this. It's free to use. https://github.com/stormpath/stormpath-django

OpenID Connect for service-oriented architecture web portal

I'm building a website using service-oriented architecture (SOA) principles. When users visit the site in their browsers, the interface they see will be composed of resources delivered by several different services on the backend.
My question is how to use OpenID Connect (OIC) to implement SSO so that users log on through the site once and their browsers can automatically retrieve all the protected resources that are necessary.
The main conceptual difficulty I'm having is that everything written for implementing OpenID Connect seems to be oriented toward people creating monolithic third-party clients that authenticate with Google, Yahoo, etc. In my case, however, the client is my web portal and the resource providers are my backend services. Certain OIC concepts don't make sense to me in this context: for instance, the auth grant. Are users supposed to authorize the web portal to access their information the first time that they log on? That would be pretty absurd.
Or Is OIC the wrong tool for what I'm trying to do?

Google Cross Domain Authentication

I have various sites (on their own domain) with their own authentication systems. What I'm trying to do is combine all the authentication into Google's authentication so the users will only have to log in with their Google credentials. What I'm thinking of is that they would log in with their Google credentials and be redirected to a dashboard which has image links to the other sites. The user should be able to go to any of the sites and be automatically logged in since they were already authenticated. I saw that there's an authentication for Google Apps but is this the same thing for my websites?
What I'm not sure about is how does this happen cross domain? How do the other domains know that the user is already authenticated?
Also, if the user logs out, they should not be able to access any of the sites anymore.
Anyone have any experience implementing something like this? Any resources are much appreciated. I will be implementing this in Coldfusion so Coldfusion resources are a bonus.
Your talking about using Google to login/signup i.e. Using OAuth 2.0.
You will need to register each of your app domains with Google. The user will need to confirm each application to allow access (in your case for signup/login).
Resource on Google Login with ColdFusion by Raymond Camden
The point is you need to establish a certain protocol to build a trust.
Other options are:
Google oauth javascript cross domain