Let's say there's a website A where I have permission to manage accounts and credentials in order to give access to other users, and i want to limit users to 2 different devices at maximum(one mobile, one laptop/desktop); but I don't own A so I can't modify or even view the source code.
I was wondering if it was possible to create a website B where I store server-side the credentials of website A, and give users credentials of website B instead, verify the restrictions there, and redirect them to A already logged in.
Related
The following scenario:
I have a website X with which users can interact
Once a user grants me the necessary permissions, I need to automatically send requests (in the name of the user) to another, unrelated website Y. The user needs to be logged in on that website.
Is there any way I can automatically control the requests that the user sends to site Y? I don't want to have access to his account password, but I need to be able to make requests with his account.
Any way I can achieve this in a trustless way?
This is the my web-app "User Settings" page.
I have simplified it to a minimum to better highlight the problem.
To authenticate users I use Auth0, I wanted to use the sub claim user_id to identify the users inside my MySQL database for update and retrieve user's info. Unfortunately the user_id is different for each provider, for example, if the same user with the same e-mail logs-in via Auth0 he gets a user_id if he does it via google he gets another one.
I thought about using email to link logged user to his info.
The problem is in my API. Before the change it was "localhost: 8080 / api / users /: id"
each time it created a new id and in any case it was impossible to recover the data of the single user. Now that I have replaced "id" with "email" my API has also changed in "localhost: 8080 / api / users /: johnsmith#xxx.com".
Before:
After:
In a few words, the request url on the client side has also changed.
I would like to make sure that the GET and PUT requests are made based on the e-mail of the logged user without going to modify the whole back-end.
Sounds like something is wrong with how you authenticate users. If you have multiple ways to authenticate a user, those methods need to be in a one to many relation with the user. For example each user has a list of auth-methods, and whenever an authentication is made you check your table of authentication methods and find the one user it maps to.
Im not sure if you are doing this yourself or if the framework you are using is handling that, but it sounds like you need to change the model to allow many Auth methods for a single account.
Also you could use email, but that is also an "old" way of uniquely identifying users almost every single person has multiple active email accounts nowadays, so you should also have a one-to-many relation for users to emails. What if the user has different email accounts for their Facebook and Google accounts?
See account linking here: https://auth0.com/docs/users/user-account-linking
It is dangerous to trust that the external providers are truthful about what email belongs to who. What if I open a new account using someone else's email on one of the providers? Then I can log into that users account in your application, which is a pretty big security risk.
On our intranet, I want to provide a website that certain employees can access. The work they do on the site will be recorded and tagged with their user-name for identification if the need should arise. Of course users have already logged in to their workstation and they have supplied credentials to our Active Directory.
Rather than maintain an additional set of user logins and passwords for the website, and forcing users to enter this second set of credentials, I am wondering if they can just be silently authenticated when they pull up the site? Somehow the webpage would have to find out their Active Directory user name as known on their workstation. (I see no reason it would need their password.) And then, for their work, the website can store their actions tagged with their user name.
So: I'd log in to my workstation as "Mark" in domain "ONU-AD". I'd pull up the webpage "resolveticket.php". That page would not challenge me for credentials, but it can access my username and store that with my various actions.
NOTE: I have seen some questions and answers here that were more specific. But my initial question is general: is there a piece of tech that can help with this? What is it? (for example, should I try to do this with Java?) Many similar questions are about ways to get this information in a server-side script. But I am simply wanting the webpage sitting on the client computer to be able to get the user name and perhaps place it in an input (type="hidden") on a web form.
Our web app. sends reports out to users which contain links that point to various items within our web app. (specific records). Users ordinarily have to login to our system to access it, so I am wondering what the best methods are of allowing one of these links to direct the user to the area of the system, without them having to repeatedly login.
When you create a link, you can note which user this link is for. When user clicks on the link, fetch information for the user. Guid in your url would guarantee that no other person can guess path for that users data. This will not technically authenticate a user. But will allow them to see data you need.
First of all it's bad idea to distribute user credentials even to a known email address.
You can generate a unique key for each customer and insert it in query string of included URL in the email. once user clicks on the sent URL, system discovers which user is dealing with and authenticates user. After successful authentication process it really makes sense if you disable the sent unique key.
There is website A, with its pool of users. There is a separate website B, which sells digital goods.
I want to allow users of website A to make a purchase from website B, without registering or visiting B.
Given that site A has an agreement with site B to pay the bill on a monthly basis, how can you authorize purchases without opening a vulnerability for malicious attackers?
The first solution which come to my mind, storing a master password to authorize single user purchase, is a security nightmare, but I can't thing anything better. Any ideas?
You can use SAML (http://en.wikipedia.org/wiki/SAML) for this purpose.
Site A will have username/password and other information to authenticate end users. After authentication, site A can send users to site B and site B will call a service exposed by site A to confirm that user is indeed sent from site A.
E.g.
user 'abc' logins on site A
user clicks on something (on site A) to buy something from site B
Site A generates some random and unique token for this action.
User is sent to Site B (usually by POST on a form that points to site B). One of the form fields would be this token
Site B calls some service on Site A to validate the token and to retrieve username for which token was generated. Service might return other things like purchase limit for this transaction.
It is VERY important that the whole communication happens over SSL. This will help mitigating Man-in-the-middle attacks.