Question about security and using Parse as a REST API

[JoeyBodnar]

hello, I am wanting to use Parse solely as a REST API, so if needed it will be less cumbersome to switch out my networking code interface. I also want to use Sign In with Apple as my primary method of authentication.

when testing signing up/logging in, I noticed that when I retrieve the current user (using the session token), it sends back the authData field, which contains the JWT and user’s apples user identity.

Is this a security risk? As far as I understand, these are essentially the user’s username/password, as with this information, you can login as a user and create a session. And if it were being sent across the network just once (for example, we cannot get around the fact that username/password login requires us to send the password across the network), I think it would be ok. But getting/refreshing the current user can be done often throughout the lifecycle of an application, which seems like we would be increasing the amount that this sensitive information is sent across the network.

I am not a backend developer so maybe I am misunderstanding about how these things work behind the scene. Is this a security risk? or is there a way we can omit the authData field when retrieving the current user?

thanks

[dblythy]

It’s a good question, is there really a purpose for the authData field to ever be returned to the client? cc. @davimacedo @Manuel @cbaker6

[Manuel]

The communication between the client and the server therefore should be usually encrypted. For example, the session token is sensitive information that is sent to the server with every request to authenticate the client request and is basically a secret key that allows anyone to act on behalf of a user.

[JoeyBodnar]

hmm yes, I considered that was similar to the session token, but session tokens here are analogous to bearer tokens in a traditional Rest api setup, which can easily be revoked/invalidated when needed. But the authData info cannot revoked–if someone gets that info, they can permanently act as that user. But yes, the client/server communication should be encrypted to in theory protect against this.

maybe for now, the best solution for me would be to make my get current user api calls a cloudCode function, and then inside that function, strip out authData before sending it back to the client?

[Moumouls]

Hi @JoeyBodnar here a related discussion about security of the authData field.

Remove sensitive data from authData

After I save my user using a third party authentication, some sensitive data keeps saved in the user’s authData field, like the external auth token and id of the user. For security reasons, like to prevent exposing this info in a case where the DB leaks, I wanted to remove the authData value: Parse.Cloud.afterSave(Parse.User, async request => { // This prevents an infinite loop from cleaning authdata from the user. if (!request.object.get("authData")) return; // Remove session sensitive …

Once this PR will be merged: feat: new auth adapter and webauthn by Moumouls · Pull Request #7079 · parse-community/parse-server · GitHub

It will be easier to control authData saved and return to the client.

@JoeyBodnar

maybe for now, the best solution for me would be to make my get current user api calls a cloudCode function, and then inside that function, strip out authData before sending it back to the client?

Using cloud function to achieve this will work.

On another side JWT of Apple/Google/Facebook are short lived (something like 15min). Also, even with the Cloud function you will send the JWT through the network. This network need to encrypted (thanks to SSL/TLS).

From my point of view you should stick to the classic Rest login endpoint, actually the security benefits of using a cloud function will be not significant.

In another side i’ll recommend you to ensure that the User session token is saved in safe place. In case of a webapp for example, it’s a bad practice to save the session token into the localstorage/sessionstorage. Here some ressources about cookies dedicated to sensitive data: Session Management - OWASP Cheat Sheet Series

[JoeyBodnar]

@Moumouls has there been any update to being able to control what data is saved into the authData field? as I checked, the PR you mentioned above was closed and not merged.

[Moumouls]

Hi @JoeyBodnar it’s now possible.

See the new Auth Adapter spec ( validateLogin, validateSetup, validateUpate) and the ParseAuthResponse type definition here

parse-community/parse-server/blob/alpha/src/Adapters/Auth/AuthAdapter.js#L55