Auto-Login When Using Argon

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.

Would this be a case where you need a centralized auth server for both AA and CA?

Not sure if a auth server would also help me log in automatically in CA, when logged in in AA. Would it?

I think you’ll need SSO. Could possibly use Auth0 or keycloak.


https://www.keycloak.org/

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

1 Like

We recently self-hosted keycloak for our internal use. Its so complicated! So many options to configure. :sweat_smile:

I am not sure to what extent Wappler’s security restrict would play-well with external SSO. I remember some post about Auth0 in community.

Do you have any personal experience with Auth0/KeyCloack and Wappler security provider that you can share?

That sounds like a good approach. One caveat I see is to run an extra DB query on every login.

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

True. But it is only on login rather than on each API call so could definitely be worse

@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

These two topics helped me to get the initial knowledge: Using OAuth2 Connector with Facebook and Using OAuth2 Connector with Google

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.