So on my website I have a signup/signin page. I'm looking at implementing social signup/signin buttons.
I'm planning on saving the social user data in their own table and then use that data to make a user on my website (in my sites user table).
The problem/question is, how should I handle the password?
They need to confirm their password whenever they change sensitive information. ie. username,email,password. Which is not possible if they don't have one set.
Of course I have a "forgot password" button, but surely there's a better way.
The general rule of password handling is to never send password in plain-text over the net.
For the social signups/signin the password handling is taken care of by the provider. The API they provide will usually give you an unique id or something that you can use for verification in your data-table.
Be aware that some of the social authentication APIs strongly recommend not to send user-ids over the net, but rather let your back-end do the user-id look-up with an access token.
Try to search for "[social media] oauth" that will help you on your way
Related
I'm trying to create an App which has a log in page where user should be authenticated using azure AD. Basically the App has a log in form where user puts his id and password from ad and django should check with ad and allow him in or not. Later on ofc would like to add permission depending on AD group.
So far I searched a lot on the internet and found nothing. Could you guys help with some example or link to documentation what I could use.
First of all, I'd like to suggest that you don't do that.
What you are asking for is ROPC flow: https://joonasw.net/view/ropc-grant-flow-in-azure-ad.
Usage of this flow is not recommended unless this is for migrating a legacy application (which is the original purpose of ROPC).
It also won't work if the user has MFA, an expired password etc.
There is usually no reason why you'd want to handle user passwords when using a federated identity provider.
In Amazon Cognito's User Guide, in the page “Configuring User Pool Attributes”, there is this paragraph (with added emphasis):
“If your application does not require a username, you do not need to ask users to provide one. Your app can create a unique username for users in the background. This is useful if, for example, you want users to register and sign in with an email address and password.”
I want to do precisely what the paragraph says: while users sign up, create in the background a custom user ID for them myself, because I need these IDs to follow a specific semantic format, that embeds tenant context into the IDs (something like “T01234#U01234567“, meaning “user U01234567 inside of tenant T01234”).
The users won't know of their custom ID, they will feel as they've signed up (and later signed in) with their emails (or through 3rd parties like Facebook and Google, if possible in this set up). But in the background I will create these custom IDs and store them in their username attribute in the User Pool.
The reason I want to store these iDs specifically in the username attribute is because it is un-mutable and unique, but most important because I will need to query Cognito's APIs (ListUsers, AdminListGroupsForUser, etc.) using these custom IDs as filter, to give my customers some user management capabilities. The username attribute is the parameter for these APIs. Therefore, I cannot use User Pool custom attributes here, since they are not accepted as parameters of these APIs.
The reason I post this Question is because, while the documentation recommends this as a possible setting, there is no specific information on how to set the user pools and sign up flow to support this specific use case.
What is the general settings layout of this? To start with, in the option “How do you want your end users to sign-up and sign-in?”, what do I have to put there in the scenario I described? If anyone can give any additional pertinent information, it would be very helpful, as the documentation feels somewhat opaque.
Thank you very much for those who've read this.
You probably will need to deal this in your frontend.
When your user start the sign-up process, you will need to generate the username based on your requirements and send the request to Cognito User Pool using that generated username + e-mail.
For Cognito User Pools this will be transparent because in the request it will receive the username, the password and the user e-mail. Off course you will need to allow login with e-mail and password.
If you don't want to do this in the frontend you can create a backend with public access that accepts a unauthenticated requests and performs this task directly in Cognito User Pool.
I am building a basic social media web application and I would like my only login point to be via facebook login. After doing a fare amount of research, I have seen multiple third party authorization frameworks that plug in with facebook, but I was wondering if there were any opinions on what the best foot forward would be.
Additionally, how would I go about still being able to use sessions/cookies within Django if I use fb login?
All answers are appreciated!
You can use SocialAuth (https://github.com/python-social-auth/social-app-django), this app allows you to let users log in via many common SocialMedia-accounts, e.g. facebook. Upon login, the app will create a user in your database, which you can then use as if the user logged in with a local account. Therefore, the session will still be handled by django, fb only sends you some information about the user (e.g. first- and lastname, email, etc. [configurable in your settings.py])
According to the Cypress best practices, I should avoid using my login UI before each test. I'm struggling to do this using Oracle APEX because it appears the login process requires a lot more than just username and password.
I have used chrome's tamper data tool and Jmeter to inspect the mechanics of the Oracle APEX login process and, essentially, the login process has 2 steps:
(1) the login page redirects to a login page with a valid session id in the URL, seeded with dozens of time-sensitive unique ids.
(2) Upon submitting your username and password, a POST request is made to /ords/wwv_flow.accept with the username, the password and several other time-sensitive unique identifiers.
It appears that APEX requires something similar to following for a successful login:
p_json : {"salt":"108222855956905007172773085768141257328","pageItems":{"itemsToSubmit":[{"n":"P101_USERNAME","v":"jsmith"},{"n":"P101_PASSWORD","v":"Password123"}],"protected":"unDCYO1qmj_OAwtyYNo_yA","rowVersion":""}},
p_flow_id : 4000250,
p_flow_step_id: 101,
p_instance: 6589106753596,
p_page_submission_id: 108222855…,
p_request : LOGIN,
p_reload_on_submit : A
All of these variables (besides the username and password) are available in the login page but to get them I'd have to visit the login UI, which is what I'm trying to avoid. Am I thinking about this the wrong way?
I believe this is the wrong approach. As for Unit testing you have to accept some degree of variability in terms of production vs. pre-production.
Saying the above I think you need to consider some more "normal" approach such as:
Change passwords in Pre-Prod.
Alternate Authentication Scheme.
Alternate Build Option(s) based on your needs.
I am not sure about these best practices you mention, but the session information you might pass along you testing must be created by APEX engine on the server-side.
There is no such way to bypass the login by just passing some parameters to the server other than a proper credentials information. What you can do, however, is implementing a custom authentication schema in APEX that would authenticate (and would create your session) by using some token or some other custom way, for i.e., checking the browser agent, IP address, environment, I don't know.
This custom authentication schema isn't related to unit-testing though.
I'm writing a Facebook canvas webapp that performs a login (using urllib) to a third party website and performs actions on behalf of the user. This means I have 2 accounts; the account the user has with my webapp (via facebook) and the account the app uses to perform a login on their behalf (with user/password details provided by the user).
I obviously don't want plaintext passwords in the DB. But I also don't want the user to have to enter their password every time they perform an action. I want them to enter the password once when they sign up, and I want to encrypt the passwords, but what do I encrypt against?
Any key on the server would be available to anyone who had gained access (i.e. useless), so I was thinking of encrypting it against a value available via the Facebook API.
When the user logs in (and gives the app their access token), the app can request the value via the API and encrypt/decrypt their 3rd party password with this. Anyone with access to the server wouldn't be able to make this request without the user being logged in to the app. (This still means someone snooping on the server could get logged-in users 3rd party password, but anyone who got one-off access to the DB couldn't see passwords.) Is this wishful thinking?
You might as well encrypt it using a key on the server. If anyone gains access to your server they will have everything they need to retrieve the key even if you're getting it from Facebook.
I think the best you can do is to store the key in a location that isn't available to your webserver, but that is available to your script. At least make sure you don't store the key in the database.
Whatever you do beyond that would just be security through obscurity. The key here is to keep your server secure so that no one gains access to it.
I guess you could store the logins ONLY on the client, in some sort of local storage and do all the actions related to the third party, from the client in JS.
This of course would need some change in the architecture of your app if you tought to do all this from your server, but that would possible for sure, you can event make client JS send data to your server after it worked so you can log data from the interactions with the 3rd party.
Furthermore it has the advantage of distributing the load on the clients
I know you didn't tag the question with javascript and you seem to want a server pure solution, but It seems the best solution to me. the user keeps its data ..
Security through obscurity might be your best bet. Perhaps implement an algorithm to generate the key using something standard (like the current datetime). You can store the date in your db, and use that to generate the key using your own algorithm.