Auth Emulator and createSessionCookie /validDuration should be string

[royletron]

[REQUIRED] Environment info

firebase-tools:8.14.1

Platform:macOS

[REQUIRED] Test case

const expiresIn = 60 * 60 * 24 * 5 * 1000;
const idToken = '<TOKEN FOUND USING auth().currentUser.getIdToken() ON CLIENT>'
await auth().createSessionCookie(idToken, {
  expiresIn
});

[REQUIRED] Steps to reproduce

This is using firebase-admin on an express backed server, with a front end using firebase and firebase/auth. These are all connected to the firebase emulator running both firestore and the new auth. You'll need to get an ID token for a user (not sure if it has to be valid or not), and then pass this to the createSessionCookie example above. It should fail with the error Invalid JSON payload received. /validDuration should be string. This doesn't happen if I connect to a live Firebase project, only when using the emulator.

[REQUIRED] Expected behavior

That we receive a cookie that we can send back to the client.

[REQUIRED] Actual behavior

{ Error: An internal error has occurred. Raw server response: "{"error":{"code":400,"message":"Invalid JSON payload received. /validDuration should be string","errors":[{"message":"Invalid JSON payload received. /validDuration should be string","reason":"invalid","domain":"global"}],"status":"INVALID_ARGUMENT"}}"
     at FirebaseAuthError.FirebaseError [as constructor] (/Users/redacted-project-path/node_modules/firebase-admin/lib/utils/error.js:43:28)
     at FirebaseAuthError.PrefixedFirebaseError [as constructor] (/Users/redacted-project-path/node_modules/firebase-admin/lib/utils/error.js:89:28)
     at new FirebaseAuthError (/Users/redacted-project-path/node_modules/firebase-admin/lib/utils/error.js:148:16)
     at Function.FirebaseAuthError.fromServerError (/Users/redacted-project-path/node_modules/firebase-admin/lib/utils/error.js:187:16)
     at /Users/redacted-project-path/node_modules/firebase-admin/lib/auth/auth-api-request.js:1510:49
     at process._tickCallback (internal/process/next_tick.js:68:7)
   errorInfo:
    { code: 'auth/internal-error',
      message:
       'An internal error has occurred. Raw server response: "{"error":{"code":400,"message":"Invalid JSON payload received. /validDuration should be string","errors":[{"message":"Invalid JSON payload received. /validDuration should be string","reason":"invalid","domain":"global"}],"status":"INVALID_ARGUMENT"}}"' },
   codePrefix: 'auth' }

[samtstern]

@royletron where is your express server running? Right now the Admin SDK only accepts emulated ID Tokens when running inside of the Cloud Functions emulator. This is a decision we made for security reasons, although we are open to reconsidering this based on developer feedback.

[royletron]

@samtstern express is just running locally not inside the functions emulator. In prod we run a server on CloudRun so this is more related to our use case

[samtstern]

@royletron ok thanks for clarifying. Right now there's not much you can do about this ... we'd like to expand the situations where we can support verifying emulated tokens but we're still debating the right way to do that.

[samtstern]

@royletron this feature request is being tracked over here: #2764

I'm going to close this one so we can focus the discussion in one thread.

[andymatuschak]

@samtstern I think this is a real issue, actually! I'm encountering it even though I'm executing createSessionCookie inside the function emulator. So I dug in, and I believe the validation schema is wrong. The auth emulator validation schema specifies validationDuration as a string, but firebase-admin-node constructs it as a number.

I note that the OpenAPI schema for createSessionCookie specifies the parameter as "string (int64 format)". If that means it's meant to be a string-encoded int64, then this is really a firebase-admin-node bug, although clearly the production auth server is accepting numbers for this parameter.

[samtstern]

@andymatuschak thanks for digging into that! Filed: firebase/firebase-admin-node#1084

[yuchenshi]

As of Firebase CLI v9.3.0, creating session cookie is now supported and we've also added coercion from number to string similar to production behavior (hat tip to @andymatuschak). Note that you need Node.js Admin SDK v9.5.0 to verify these cookies properly.