How can private data be protected by OAuth2 authentication?

Question

I am setting up a site to use the Google OAuth2 interface for user authentication. The website will store personal data associated with each user that I plan to encrypt.

If I applied my own authentication method for the website, I could easily get the key for the user credentials (including the user password), which would protect the data for each user. But with OAuth2, I believe that I can get an access token by granting this permission to the user for a certain period of time - the problem is that the value of the access token will change over time.

Is there a way that OAuth2 can provide me with an immutable user-specific secret that I can use to get a secure key? Or is there some other way to create a secure persistent secret using OAuth2?

--- Edit ---

In response to questions and comments, here are a few considerations:

• All user information should always be protected with strong encryption and user authentication - the reason we read so many news articles about website and database hackers is because the developers say "do we really need to provide this," and then answer "No - because no one but us can access the database, security is tight, etc." Hacker downloads database and script. Credit cards, email addresses, phone numbers, passwords, you name it, and then you are at risk.
• There are only two real secrets: one is the password stored by someone's manager, the other is a strong random value that only an authorized user can access (for example, a physical token). If you believe that a secure key can be obtained from only one email address or that the secret should be stored in a database, you really do not understand security.

I assume that I was trying to find out if the OAuth provider could provide the OAuth client with an immutable value that is securely associated with the user and the client - this will be a key that can only be unlocked by the OAuth provider using a combination of user privacy (their authentication password) and client secret (used in the OAuth protocol). The client can then use this value to provide a reasonable level of security for user data.

Of course, this implementation is not ideal due to abuse, but implemented correctly can provide a reasonable way to protect data, while at the same time using good OAuth schema practices.

Answer 1

The point of the marker is that you can use the token to get information about the user from Google. During initial authentication, you tell the user and Google that you want to access certain user information:

https://developers.google.com/+/api/oauth

Assuming the user allows you to access your information, such as an email address, you can get your email address from Google. Once you have an email address, you can create a secret key for your user, save it in your user table and use to encrypt your data. Then, when they log in again, you can find their email address and find their key.

Is there a need for classified information about immutable information? Or is it just a key to identify the user?

If the information you store is truly confidential, and you want to do it so that you cannot access your user data, all you have to do is save an encrypted frame for your users. Once the user has uploaded their data, they can use their key to decrypt the client side of the data.

Answer 2

My first question: Why do you want to get encryption keys from some tokens?

Tokens and encryption keys can remain independent and can be associated with a user identified by a unique identifier. User authentication can be done in any way that you need, either using credentials, or using authentication with an open identifier, or something else. But, once the user is authenticated, your decryption APIs can retrieve the decryption key associated with the authenticated user and perform any decryption.

This way, you can potentially allow users to associate multiple open accounts with the same user as what Stackoverflow does. I can link my yahoo, facebook and google accounts with my Stackoverflow user and can log in with any of these providers. I can disable these accounts at any time. But this does not affect my profile and Stackoverflow data.

Thus, it is not recommended to derive your keys from something that is not constant and continues to change. Instead, keep them separate.

Answer 3

You need a permanent secure (random) key for each user, which you can get from the authentication service, which gives the OAuth2 endpoint (in this case, Google).

The OAuth2 protocol itself does not provide this value. The authentication server uses generated values ​​that are not constant. But OAuth2 does not prohibit giving this value from the resource server (along with the user ID, email, etc.). Thus, basically OAuth2 allows you to protect the data the way you want, but the Google that you are currently using does not give this kind of constant random value.

Also note that this will not work if you allow the user to link multiple accounts, such as Google and Facebook, as they will give different random keys.

If you get sensitive information from your credentials, it also means that a user account will be reset to reset the password.

In addition, if you encrypt data such as emails in this way, it becomes impossible to decrypt them without the current user. Therefore, sending out e-mail becomes almost impossible. You also cannot query data in SQL.

I could only suggest some countermeasures:

• Do not store sensitive data at all or store hashed data. Passwords must be hashed, not encrypted. Do not store CC numbers, keep tokens that represent them.
• Use encryption with a key stored in another data source. This adds at least some protection - an attacker should get not only a copy of the database, but also an encryption key.
• When data is encrypted, storing it in the database is no longer required. You can store encrypted data in files or another source, where it is safer than in the database (there is no risk of SQL injections, etc.).

Answer 4

I have the same problem. So far, I can’t find a safe way.

Basically, we need an arbitrarily created secret for each site, provided only with an implicit stream, which can be used to obtain credentials for accessing systems and decrypting data.

Since I want to protect the data from myself, I could write to the client to salt / hash the secret in two ways, one way to get the data, and the other to decrypt it.

Alas, this is not so.

I could get credentials from things in the main oAuth area and this will protect the data from me, but it will open up great opportunities for cross-site vulnerabilities, and in addition, personal identification information makes a bad secret.

The best I got was to use the implicit oAuth2 stream to get the user's email address, randomly generate the client’s secret part and force the user to send a secret via email (as a recovery key), and then store the secret in localStorage. Salt / Hash of the secret variable + oauth to obtain the client part of the credentials (so that the user should be logged in), necessary for access, encryption and decryption of the data.

If a user ever cleans up his local storage, he needs to follow the link in the recovery email, which puts the secret in localStorage.

This puts the vulnerability back to the client, but is resistant to public machines (you had to know who was last registered and get access to the localStorage token), allows for recovery and weakly requires the user to log in. Still vulnerable to plugin attacks and physical access + knowing the user.

Update . I decided to use some oAuth extensions (hello.js, folder APIs) to store keys in the user account as files. It requires some permissions and some APIs to implement, but seems viable.