Does OneLogin send plain text or hashed password to the client server?
Is there an option to opt out from synching the password?
OneLogin will only send over the User's password if you configure the SCIM connector to do that.
As part of setting up your SCIM application connection in OneLogin, you define the payload you want to send over as well as the user attributes that get mapped to the various values in the payload.
While user password is one of the values that's available to sent over, there's absolutely no requirement to send it.
In fact, most applications that support SCIM use SAML for user authentication, so there's no need for passwords.
Related
I'm looking for a way to share SSO user table and secret key with other applications using Node.js API.
Current implementation: I have a central server which is used for Authentication. Authorization happens at the application level. A user signs up using my SSO server. The user information is stored in MySQL DB. when user logs in SSO will generate a JWT token, sends it to the client (stores it in a cookie). Then the client, for each request, will send the token instead of username and password.
I will have a product display page which will list all the applications.
Each of these applications has their own DB/file system to store user information. I thought about two ways to share the user information and secret key with each of these applications.
Design 1:
You copy the value of the JWT from a cookie, decode it in your application and then try to insert user information into the respective database/file
This operation happens in the product display page of SSO when a user clicks on a particular application
Every application won’t have user information stored unless the user clicks on App in the SSO product display page.
Design-2: Applies for both user management and a key share
We explicitly configure all the application servers in SSO
We provide an API to send the user data to the application
How do I efficiently manage to add, delete, update user information across multiple applications and share the secret key among all the apps? How should I approach it?
I have a chrome extension which allows users to exclusively login with google and no other provider.
In my (node + couchdb) backend I need to construct a user account from the auth Response provided by google's oauth2 api. I was thinking about using a hash of the id_token as a password after verifying the token using the tokeninfo api
I realize that the id_token changes from time to time. In that case I was hoping to update the user's password automatically.
Here is the flow I had in mind:
1) User signs in on the front-end and gets an id_token from google
2) Id token is sent to the server and verified using the tokeninfo api
3) If verified, a user account is created with a password being the hash of the id_token.
Do you see any security holes with this flow? If so, what are the alternatives?
It is probably annoying to change user passwords all the time, and this ties your authentication too much to google. What if you want to implement password logins in the future, etc.
I would recommend to use something like proxy authentication instead.
http://docs.couchdb.org/en/latest/api/server/authn.html#api-auth-proxy
make sure to set
[couch_httpd_auth]
proxy_use_secret = true
in the config.
On a side note: if you sync the couchdb password with external secrets like in the question, you should sign the password with a hashed secret that you control completely.
The nodemailer module (allows to send emails in a node.js app) supports XOAUTH2 authentication against Gmail accounts. Why would one want to use this for general purpose email notifications as opposed to just specifying the user: and pass: parameters in auth? I understand that the password is then stored in plain text, but it's never propagated anywhere. Also, the XOAUTH2 method seems to require a clientSecret: parameter, which should also probably not be made public. So what are the advantages here?
Similar question: how can I include authentication information in the app without pushing it into the remote repo? Is there a way to just ignore those lines with Git?
Using XOAUTH is useful when you want to send e-mails on behalf of your users (eg. as if the sender would be the user, not your application) - instead of asking their passwords, you can ask them to authorize your application through the OAuth mechanism. The resulting client secrets are known only to you, valid only for accessing the e-mail of the user, nothing more and the user can revoke these client tokens any time they wish.
If you do not want to send mail on behalf your users but with your own credentials, then there is no point of using XOAUTH.
I am trying to determine the best way to enforce password expiration rules in my solution.
The server-side exposes a REST API for operations with a custom active Security Token Service (of sorts). Client applications pass user credentials to a REST endpoint where the user is authenticated on the server. The response includes a custom security token representing the user which is then passed to other API methods so the call can be authorized. The server is stateless and does not maintain any reference to the identity or claims information (i.e. session-less).
We have password expiration rules that are enforced by the server. So, when authenticating a user, it is possible that their password has expired. I need to communicate this to the client so they can do whatever is needed to have the user change their password. (There is another REST endpoint for changing the password on the server.)
Questions
It seems to me that authenticating a user with an expired password should fail. However, I need to know the identity of the user changing the password when making the second API call, so should I go ahead and return a token even when the password has expired?
How should I inform the client that a password change is required? I thought about including this as a claim in the token, but that would require me to reissue a new token after the password has been changed or modify the original token which isn't allowed. My other thought was a custom HTTP Status Code that I would correspond to meaning Password Change Required.
The answer to this question probably depends on the previous two, but I don't want to authorize a user that has an expired password if the token is passed to any other APIs (besides changing the password). What's the best way to handle this?
So, what I ended up doing (certainly not the be-all-end-all solution) is having my Authenticate endpoint return an AuthenticationResultCode enumerated value in the response in lieu of a simple pass/fail boolean. Possible values for the enumeration include:
ValidCredentials - the user was authenticated and the AuthenticationToken is included in the response.
InvalidCredentials - the user was not authenticated
CredentialsExpired - the user was authenticated but their password has expired. I have yet to determine if the AuthToken will be included with this result.
NoCredentials - no credentials were provided to the request
Now the client has more information about the result than a pass/fail value (which I really never checked anyway) and I can take the appropriate action in response such as automatically displaying the ChangePasswordDialog when CredentialsExpired is received.
Like I said, still working out whether or not I should still send the token when the credentials are expired because I don't want to be able to authorize a user if their credentials are expired but they've already been authenticated once and I don't think it makes sense to re-authenticate after changing the password (after all, I have to be authenticated so I can change the password in the first place). Maybe just a simple IsLocked or IsExpired property on the client will suffice...
I'm working on a web application which involves connecting to Gmail on behalf of a user to check for new messages. Is there a way to securely store the user's credentials so that they can still be recovered for the login, or is there some way to obtain a token for Gmail to use in connections?
EDIT: The application is meant to be used mostly with mobile users, so they won't be logging into the site frequently. Thus, storing information in a cookie isn't viable.
If you logged into GMail's web interface it gives you a token in the form of a cookie. If yYou could use that token and the web interface then you could access their email without storing their credentials. Of course that isn't IMAP access, and it expires (as a good token should).
Alternatively you could encrypt their credentials with a value you store as a cookie on their computer. Then when they access your site you can check their mail without ever storing the encrypted credentials with the key to decrypt it.
Neither is an ideal solution, but hopefully they get you moving in the right direction.