Using firebase-admin in action scripts

Help
,
1

In my SSO SAML flow I am trying to use firebase-admin to check if a user exists in Firebase before allowing post login to proceed

The issue is that it requires a file containing google_application_credentials. I am not sure how to use a file in action scripts, if it is even possible?

doc for firebase-admin setup: अपने सर्वर में Firebase व्यवस्थापक SDK जोड़ें  |  Firebase Admin SDK

3

Hi @auth0rocks,

You cannot add a file to the Actions workflow, but you can take the contents of the file and add it to the Action’s secret store.

It looks like the Firebase Admin SDK accepts a credential object in the initializeApp() options. Is there some way to pass this the credentials directly, instead of passing an env variable from a file?

What does the JSON file look like? (don’t share any sensitive values)

4

Thanks so much for helping!

Here is the structure of the json from google credentials. We would somehow have to run that script and get the credentials object out of it and paste it in secrets… not sure if that works but we can try…

{
  "type": "service_account",
  "project_id": "***",
  "private_key_id": "***",
  "private_key": "***",
  "client_email": "***",
  "client_id": "***",
  "auth_uri": "***",
  "token_uri": "***",
  "auth_provider_x509_cert_url": "***",
  "client_x509_cert_url": "***",
  "universe_domain": "***"
}
5

Even this though is still concerning to us based on a chat with our security team
Doing the pre-generation object above is still just saving the same file in a different form in the actions.secrets. It can be json.parsed to get the creds for use with firebase-admin

Also even if use this we run into this

Each secret key may have a maximum length of 128 characters, and each secret value may have a maximum length of 2048 characters.

Finally, we would like to avoid having to use the google service account approach altogether outside of our systems if possible

It looks like I have to find an alternative here such as our backend doing this lookup with google account instead of doing it in Auth0

Do you have any precedents or solutions you know of your clients have used in this situation? I have a working alternative solution with our backend doing this lookup, but that requires more work and happens for every request during jwt inspection and we maybe need to have FE do update_user_metadata to save the additional user id we need in the sso record, and we cannot leverage actions to the fullest :).

1 Like
6

Hm, I don’t have any other solutions for you at this time. I think handling it in your backend is probably the best approach.

7

np thank you!

I am now trying to see how our backend can update app_metadata in auth0. Any tips on this?

I think what I need to do is:

  • use the auth0 java sdk in my spring app to post a app_metadata update to the current user record
  • in auth0, create an api with permissions sufficient to do this. Instead of using management api directly, for security reasons

but I am not 100% if I got this right…

1 Like
8

Yes, that’s correct.

Yes, you will need an API to proxy the request if you are using a client side app, and you can set up your API as a machine to machine application to use against the management API, give it the limited scopes necessary for security.

9

Thanks for all your help!

So yeah the solutoin we are going with is using our bakend to post the app+metadata back to auth0 using the api associated with the usermgmt app. So we won’t need to solve for using firebase-admin in the post login script

Thanks for your help!

1 Like
10

Thanks for the update!

1 Like
11

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.