I'm building a web application using CakePHP (which I'm new to). The app is going to require some sort of login where I'm going to use Facebook Connect. I've got a table for storing names, emails etc (for newsletter purposes etc) but not any password.
My question is: do/should I use CakePHP Auth combined with the Facebook Connect plugin (http://www.webtechnick.com/blogs/view/229/CakePHP_Facebook_Plugin_Auth_Facebook_and_more) or should I just use the plugin without any CakePHP auth? What makes the most sense?
I don't think there is a straight answer to this, but I guess it depends on your users. Some people still feel uneasy logging in with their facebook accounts, worrying about what you will do with their valuable facebook data. If you're not worried about that, just use facebook connect, if you are, use both native and facebook connect.
If you choose to use both, you can generate a random password for the facebook connected accounts, which they will never use, since the login with facebook.
Hope this helps.
Related
I have a public-facing application that uses ASP.NET Core Identity to store first-party logins, and no intention of using third-party IdPs like Facebook or Google. I want to build the front-end in React, and the application comprises an API fronting a couple of back-end services to which I'll need to forward JWTs for authorisation.
The plan so far is to use Identity Server 4 as the IdP for the project, backing it into the ASP.NET Core Identity data stores.
Current guidance is to use Authorization Code Flow with PKCE, which would require redirection to the IdP, two sets of styling etc.
In this scenario, where there is no possibility of a third-party IdP, is Resource Owner Password Grant still highly discouraged? On the face of it, it gives a neater experience:
User populates React-based login page
XHR POST to IdP with credentials (modulo an MFA challenge)
IdP returns an access token, React app subsequently uses that for future requests to the API
What issues will I introduce by pursuing the ROPC grant in this specific situation, vs accepting the need and duplication involved in a redirect-based flow to the IdP?
AMOUNT OF WORK
This is one of the big issues. As well as a login screen you'll have to make sure other areas such as Forget Password also work. If you build a second app you'll need to make it work there also.
EXTENSIBILITY
This article summarises problem areas. One of these is no scope to ever extend login solutions.
SECURITY
Token refresh does not (usually) work with ROPG, which leads to long lived access tokens and other complexity. Also, with OAuth it is recommended that the app never sees credentials.
From a security viewpoint it looks more modern to redirect the user - all the big providers do it - eg Google, Microsoft.
BRIDGING SOLUTION
As you say, if the password is private to your app it may not be the worst thing in the world. Capturing a user's Google password in your app would be a bad thing though.
ROPG has its uses but does not have much of a future - it is deprecated in OAuth 2.1 and providers will be getting rid of it. So I would also recommend what LalitaCode suggests ..
You can create a React based Identity Server login page for Authorization Code flow with PKCE instead of using MVC UI if you want. It is just extra work and complicated. I would recommend you just style the Identity Server MVC UI to look exactly like your frontend SPA. This is the simplest way and the path I took when I did a project with Identity Server(with Angular as front end).
I have a WordPress Website that currently uses its own authentication.
I am building a new web app on React which would be on its sub-domain.
I will be using AWS Cognito for authentication.
Now I want to enable a single sign-on between the Wordpress site and the React App via Cognito.
i.e user logs in to the Wordpress site and when he navigates to the react app, he does not have to login again.
Please suggest how to achieve this.
I am going through the exact same process right now. It's not simple, but from what I gather it is doable. There are some things you must reconcile first:
You will need to set up a cognito user pool to house all of your user configurations going forward. You should set it up with the attributes and roles you currently use in WP, and to allow SSO.
Your existing WP users will need to be imported into the Cognito User Pool. You will not be able to import their passwords unfortunately, so you will need to notify them to reset the passwords (I suggest sending them to the cognito hosted login page if you want to use a federated login with social providers such as facebook, google, apple, etc. - LinkedIn is a bit of a pain as it uses Auth0 but still doable).
For the login integration, you will need to choose whether to use AWS AMPLIFY or just the JavaScript SDK. Several coders tried to convince me to use Amplify, but I felt the sdk was much cleaner. Especially for the Node.js as there arfe several packages you can use as well as the amazon docs ... https://docs.aws.amazon.com/sdk-for-javascript/v2/developer-guide/setting-credentials-node.html
For the Wordpress, this is a bit more tedious. There is, AFAICT, one plugin made by miniOrange that allows you to directly integrate an app pool, but the free functionality is limited, the docs are outdated and obscure, and I generally don't have a good feeling about their longevity. Nonetheless, I am using it for now.
Now for the fun part. Unifying the login between sites requires the use of Cognito's JWT tokens (JSON web tokens) to pass between sites. There are a number of docs that AWS offers, but none were clear to me, so I have resolved to hire someone to set these up. Here is a primer on that: https://itnext.io/aws-cognito-example-using-react-ui-and-node-js-rest-apis-part-3-jwt-secured-rest-apis-e56d336ce306
I know this is not a complete answer, but hopefully it saves you some time.
I am building an AngularJS application with a Laravel API. I am looking for authentication for a couple of days, but I am stuck.
I found OAuth 2.0 as a kind of default authentication, also used by Facebook and Twitter and so more. A lot of tutorials I found are about using OAuth 2.0 with Facebook and Twitter or Google. But, I do not want to authenticatie a user with Facebook, but I want to build my own authentication, using the user credentials in my own database. So I guess, I need my own OAuth provider.
The authentication has to be very secure and easy to connect for other companies, who want to use our data (it is a web application for primary schools).
I believe there are a lot of answers possible on this question. But, I also believe a lot of people have the same question ;)
Who can explain me how to use OAuth 2.0 or a similar authentication method?
You are right - if you want to implement OAuth 2.0 you need to be your own provider (or authorization server). Being your own provider also means you can actually skip some parts of the process (e.g. the screen with a confirmation if the user really wants to grant this application the right to that etc...)
If you decide to go with OAuth 2.0, there's a widely used package called oauth2-server-laravel that helps with the whole process.
However you could also develop you're own token-based authentication system. Actually the basics are pretty simple:
Login
Verify credentials
Generate token
Store token in database
And then on request you check if the token is in the database (and hasn't expired yet)
Dead simple right? Well.. as you may already know, that's too easy to be true.
Especially where security is of high importance, You have to consider every case and you should really know what you're doing. That's why I recommend you use the OAuth standard. Yes, it may be a bit of an overkill but I believe it's worth it.
Hope I could help :)
Currently have an client application running on GAE that supports OpenId login to access resources on a server application (also on GAE) through OAuth. All is fine.
But, it requires that the user have an account with Google, Yahoo, or other OpenId provider. While that seems fine for personal users, how do I handle the corporate case where users want to use myname#mycompany.com as their login?
Do I build my own OpenId provider, host it, and store those names/passwords in a database?
Is there existing OpenId source that I can use, but give it my own names/passwords?
Do I skip OpenId entirely and somehow get my own custom db lookup to integrate with GAE authentication?
Something complete different?
My work is in Java, so Java solutions are preferred. And since this is more for prototyping than for production use, easier solutions are preferred :).
After doing some additional research it seems that if I want to stick with my current use of Restlet's GAEAuthenticator then I will have to rely on OpenId. There appears to be ways to rewrite the entire authentication so that it works both with Google/OpenId and a custom database (not what I want to try), and there appear to be commercial products (SadaSystems) that seem to also do it.
For now, my workaround is to ask people who want to use their own email address in our system to sign up with MyOpenId and add that email address as their persona.
Is there a way to use Google accounts to authenticate my own personal website? I understand Google provides an API for authentication but it requires redirection. Is there anyway to have a customized login process without being redirected to Google?
By the way I'm a total noob when it comes to user authentication. I did try to find a preexisting thread but was unable to find one.
For exactly the reason given by Kris, Google (along with similar OAuth providers) doesn't allow you to authenticate users directly.
It's a security measure to protect both themselves and their users from the Web equivalent of ATM card skimmers.
I have a usability answer rather than a technical one.
I am unsure if this is doable but, even if it is doable, I would highly suggest NOT doing it. Think of it this way: you want a user to use their Google account to login to your website. If you were that user, would you feel more comfortable entering your login information on a Google website or someone else's website that has nothing to do with Google?