Wednesday, July 7, 2021

Why 2LO auth services are not given client libraries?

 Google GCP service library for e.g. 

This library is currently aimed primarily at server applications that need to make calls to GCP services. (In this scenario, the "server application" is the "client" of the "GCP servers".)

Our currently-recommended way is to have your own server (e.g. on App Engine) that makes the calls to GCP, and your own Android app makes calls to your server. The reason is that google-cloud-java only has support for 2LO auth (service-account-based), not 3LO auth (user-account-based). If you make calls from your android app with 2LO auth, it's theoretically possible for someone to steal your service credentials from your app and use them in their own app. This isn't a problem with 3LO, though. With your App Engine app, you can use 3LO auth.

Now what is the difference between firebase in this case?

Firebase storage can be used with Google Cloud Storage as it stores the files there, but it uses Firebase specific security rules to protect the content. Essentially the Firebase project is granted access to GCS and when a client makes a request, they enforce the security rules you have given.

Using a 2LO auth bypasses the Firebase security rules and accesses the files directly and should not be used in an app as the used credentials can be stolen easily from the deployment.

The 3LO auth that Firebase uses (which is actually the same as Googles under the hood.) is used to add the "current user" info to the request, which is then validated against the Storage rules you give. See here: https://firebase.google.com/docs/storage/security/

So you really should be using the Firebase Android library to access the files, or if not using Firebase, you essentially need to create your own per-user-acl system if I understand correctly.

Note that I'm not in any way affiliated with Google nor Firebase, so if anyone can validate my assumptions correct I would be gratefull.

references:

https://github.com/googleapis/google-cloud-java/issues/1696#issuecomment-284464059

No comments:

Post a Comment