Hi.
We recently switched from SHA512 salt based password to Argon in one of our projects.
All our users would have to reset their password, which is fine.
We have a backend admin app (AA) and a consumer facing app (CA). Both use the same DB and user table in their security provider setup.
In one of our use cases, the admin user while logged into AA needs to log into the CA to view their user-dashboard. For this, we created a token based system where on click of a button in AA, user would be logged in CA.
The URL where we pass the token is a server connect route, like https://ca-domain.com/auto-login/:token
Based on this token, we would get the hashed password from DB via query.
Sending the DB password value in security login step, user is logged in.
But with Argon, now the security provider hashes this DB passed value again before checking against the DB value - which obviously does not match.
I understand that extracting original plain text password, or attempting to un-hash the argon string would be stupid. So what is the best way to approach this?
The security provider cannot be changed since the same provider is used elsewhere in the CA dashboard SAs which needs to work with its own login flow.
In a gist, we need to do security login without asking the user for the password on our CA.
I think you would have to separate things out a little
When a CA user is logging in, you could use a password verify step to check the argon password they supplied and then conditionally, if successful, retrieve a UUID/hash from the DB for that user which you could then use in the Security Provider step
When an AA user uses the auto login, you would check they have permission to do so using the token and then retrieve the same UUID/hash to log them in.
Argon encrypts the user password in the DB but the login is done with SHA512 or similar
Yeah - it could be trick to use Security Restrict. As far as I can tell, SR uses a cookie based on an encryption of the Session ID and username/password to âloginâ for each API call where it is required. Hence you would still need to login with a username/password initially
@sid I have implemented OKTA login in my company app. My login workflow in bullet points:
Setup âLoginâ action which authorise user in Keycloak
In return your authentication service will return your all Scopes that youâre requested like openid email profile groups
Then you can authenticate your users in your Wappler system with Security Login step by using for example user email as login and unique user authenticator in Keycloakas password
You can build your logic based on user groups return from your Keycloak
Thanks for the detailed steps @Notum. I have implemented Outseta authentication in past using a similar method, where the password is Outsetaâs unique user id. This was based on JWT and not OAuth.
Now that I think of it, its similar to the concept that Ben has suggested.
I re-evaluated the SSO option, and it does not fit the requirements of this app.
I have tweaked Wapplerâs core file to conditionally allow direct text comparison when doing auto-login, for now.
I would incline towards using another field if I would change the logic in future - which could be modified to support SSO & SR as well.