As the title says. This is the condition I have.
I wanted to make approval token before a user can do certain things. Here's my situation :
I have a web application made with Laravel 5.1
All user are already authenticated before they can use the web app
Before the user do any large transaction, the User needs approval from supervisor and in some case the director (software side). This is a preventive measure against fraud and employee stealing money.
Now I've been looking at a few solution but all that I've found are to further authenticate user when they login. I'm not sure I can modify it to do what I want.
Here are some of the solution I've been reading :
google 2fa
authy
This is the workflow I imagine to fulfill my need :
The user opens the web application and authenticate using their credential
The user navigate to a certain page and do a large transaction.
Before they press the "submit" button, the supervisor or the director must enter some kind of token (One Time Password perhaps) before the submit buttons activate.
On the server side, the application process all the inputs and authenticate the token (one time password), if the token (one time password) checks out, everything runs.
Can anyone gives me suggestion about the workflow? and Is there any solution to fulfill the needs?
I'm open to any suggestion.
Thank you very much.
*disclaimer : Sorry if the grammar is wrong or somethings are confusing, english is my 3rd language.
Related
I am developing an ASP.NET Core web application with user management functionalities. My question is about the email address changing algorithm. Almost every web app I saw before have the following flow:
User authorized
User requested an email address change
User received a message on the new mailbox with the confirmation link
User clicks the link and the email address updates
But I think, this algorithm might be a bit insecure and that is what I want to discuss here.
How about this flow:
User authorized
User requested an email address change
User received a message on the old mailbox with the confirmation link
User received a message on the new mailbox with the second confirmation link
User clicks the link and the email address updates
With this additional step in the middle of the algorithm, things may be much better from the security perspective, but would it be too complex or not? How do you think what algorithm I should implement? And what would you prefer if you will be in my shoes?
The second options might sound great, and it's not too much headache to implement too. But I'll stick with the first approach due to some reason:
Common work flow pattern.
As the backend side can be wrote by many language, by various developers, so common pattern would make things more standard when we need some kind of migration, and even maintaining by new developer. If the project doesn't require ultra-secure authentication flow, the simplicity of first approach was enough.
From user convinient pespertive
Let's just imagine when changing an email address, what case the user likely want to change email address ? I was register my facebook account long ago using yahoo mail, that's no-longer active, and i need to switch to a gmail one. What's the point of sending the email back to the old one ? Cumbersome... and i can do nothing in this case except get some help from the staff.
I totally aggree with the second approach on security angle. But that's not suitable for most of the case, only implement if the project have some requirement. And even in that case, I suggest don't even do that too, build some thing like sub-admin account role and grant permission to someone have responsible. Like Google enterprise email organize some account called admin if anything wrong happen to user account. As long as it has this kind of security level requirement, it's not gonna serve massively user.
The intension of all the flow
The User got authorized first, right, that's mean we Identified what the user are, and what she capable to do. Imagine when we hide a hotel room then request to change to another due to some reason. What's the point of proving that's I booked my own room, since we all know that's the fact ? Kinda weird... right ?
To conclusion, I think we shouldn't mess with something that's become common pattern that widely acknowledged, except we have some special requirements and the project have something uniquely to satisfy, and we consider ourself, as developer that's reasonable.
The main problem with this approach is: what happens if the user no longer has access to their original email account? Perhaps it was a work/school/uni account that they no longer have, or perhaps they've just forgotten their password or otherwise lost access to it.
With your second approach, they are not going to be able to update to the new account, because they'll never receive the first confirmation link.
How about the following approach instead:
User requests an email change.
Require the user to re-authenticate with their current password (just like when they change their password).
Send a confirmation link to their new email.
Send a notification to their old email, with the details of the change, and instructions of what to do if they didn't initiate the change.
User clicks the link to update or contacts your support to say their account has been compromised.
This way you still provide them with an alert that someone is trying to change their email (and potentially a means to stop it), but a user who has lost access to their old account will still be able to update their email.
I have a bot command that needs users to sign in first in order to get the answer. For example, if user types in list my saved movies, the bot will send a sign in card with a sign in button. After the user signs in, the bot should give user the answer for the original command, but currently I don't know how yet. Do you have any idea how can I achieve this?
The Bot Framework includes the ability to save different kinds of state, most particularly "user" state, which is tied to the user themself, and conversation state which is tied to just a particular conversation. One of these, in particular conversation state, could be useful - you could save the command into conversation state, do the signin, and then check from there what command triggered the signin and therefore what to do next. I haven't done a lot of work with signin, but I think that should work. More info on this is available at save user and conversation data.
Just to confirm, I see you've tagged the question with MSTeams, so I assume the command you're offering the user requires access to, say, the Microsoft Graph or similar? I'm asking because you don't necessarily need to authenticate the user per se, if they're just accessing data in your own database, as an example - they're authenticated via the Teams client already - you'd want signin, I guess, in order to get a token so that you can call something else on behalf of the user (e.g. OneDrive)?
Hope that helps
In the documents of Google One-Tap sign in, it says:
Returning users are signed in automatically, even when they switch devices or platforms, or after their session expires.
Question 1:
But it doesn't say anywhere how it does this? Is the user refresh token saved in the browser's cache? How can it then auto log in a user cross devices?
Question 2: The reason I ask is because I have a setup where I initialize the Google API client for JavaScript ("GAPI"). The GAPI library also automatically logs in a user whenever the client is "initialised" through gapi.client.init().
Now the problem is that after I have added the Google One-Tap code (Or should I say "YOLO code"? : ) my user gets logged in through One-Tap and also through GAPI. I can prevent this by not initializing the GAPI client, but I don't think that's wise, because I thought this whole library is built to manage my refresh tokens etc. Is my understanding correct that One-Tap does exactly the same and in case I only want to Authenticate users I do not need the GAPI client anymore?
Really, which library does a better job at managing my refresh tokens? And how do they differ? I'm clueless...
The way I implemented my login is the following:
Try to login in the user first using gapi.auth2. Maybe the user was previously signed into the site.
If can't login user automatically, then use googleyolo to try to find existing user accounts.
If no existing accounts, then present a signin button for user to signin.
I can give you some code snippet if you need.
To answer your questions.
#1, the credential is stored within the browser/device. If the user has never signed into google in a device, then yolo won't be able to sign in the user.
#2. googleyolo will also login the user, the difference is that it will give the account selector even if there's only one user to select (it will automatically login the user if there's only one). gapi simply sign in the user without showing anything.
I made a members-only site that uses Google oauth2 to authorise users. The site is built with the Laravel framework and Artdarek's oath library.
When the authorization callback comes from Google, I lookup the user record in the DB by email and proceed to the protected page if the record exists, otherwise to a register page.
The problem is some of our members use two Google accounts. One user registered via his primary account (e.ge. a#gmail.com). The next day he returned and mistakenly tried to login with b#gmail.com. Naturally the system showed him the registration page. From that time on each time he visits the site the authentication mechanism sees him using his second (unwanted) set of credentials.
To resolve this one case I instructed him to logout of all accounts (on both sides), clear cookies and start from scratch but this is not a practical solution for all users. In same cases even this measure does not seem to correct the problem.
How can I solve this case? What is the right way to request oauth authentication and get them back from the right account? Can I force Google to ask the user with which account to proceed?
Google will automatically ask the user which account they want on an oauth request if they enable the account chooser.
I have logged into my Google Apps and my Google account, so for me on an oauth request, I get the following prompt:
In order to do the same for your user, they have to click "Stay signed in", but of course this is not advisable for public computers.
Beyond the above, I'm afraid not much can be done. - if they logged in with a#gmail.com at that time, these are the credentials you will receive.
They way I solve this problem is to have a field where the customer can add additional emails, and select one that is primary. I will then inspect against these emails when a request comes in to avoid duplicate user accounts.
A session token is given to the user when he starts running a facebook application, as long as this token is not stolen, other people cannot impersonate him. To increase security, a new token is also generated again when it has expired or has been cleared.
So what is the problem here? Why do people want infinite session token in facebook?
How is it useful to both developers and end-users of facebook applications?
It's now called "offline_access". You're right in that most applications don't need this permission; however, occasionally an app may want to do some processing on behalf of the user while the user isn't present. For example, there are some blogging apps like posterous.com that allow you to email your blog posts - and they may want to publish without asking each time. For those, it's appropriate to ask for the extended perm.
Here's more information about how to request the permission:
https://developers.facebook.com/docs/guides/policy/examples_and_explanations/Extended_Permissions/
Why do people want infinite session
token in facebook?
So that when they exit their browser and restart it, they don't have to type in the username and password again. The authentication is still there so they can just simply start facebooking.