3
For most purposes that is secure enough minus the logging.
Your server must have the plain text password at one point, whether it's signing up or logging in. In this case, the user is passing their password to the API through an HTTPS POST request, the server is verifying the password against a hashed and salted password with many salt rounds using bcrypt ...
2
This is expected and nothing strange. While you handle sign up and log in requests, your server will need to have the password in plain text so that it can be hashed. That's how most sites using passwords work. What is important is that they are never stored (in database, logs, anywhere) in plain text. If you keep using bcrypt and don't actually log the ...
2
This question is your friend:
CSRF protection with custom headers (and without validating token)
In essence, if you opt to make your X-CSRFToken header something simple like 1, you are falling back simply on the presence of your custom header for CSRF protection. If you have a fixed CSRF token for all users, then an attacker will easily be able to figure ...
1
It depends which generation of IDaaS you are referring to but in general Active Directory (and other IAM solutions) tend to have better support for on-prem authentication protocols than IDaaS, which is a cloud bridge, does.
I find your question intriguing because I have never tried to compare them previously (they are after all apples and oranges).
I have ...
1
The easiest and only way you can do SSO without any redirect at all is if all of your applications run on subdomains (a.site.com, b.site.com). Subdomains can share domain level cookies, so that your application will receive the login cookie right from the first request.
If you want your applications to be on multiple unrelated primary domains (a.com, b.com)...
Only top voted, non community-wiki answers of a minimum length are eligible
