Re: [Firebase] Alternate RS256 client cert url's

[Jacob Wenger]

Hey Andrew,

Thanks for the feature request! Let me clarify some of the points you made and then respond to your feature request.

The JSON file resulting from service account creation contains a "client_x509_cert_url" property with a competing URL value to that predefined within "CLIENT_CERT_URL"

I know this is kind of confusing, but you are actually conflating two different token types: custom tokens and ID tokens. The createCustomToken() method creates a Firebase custom token, which is signed by your service account's private key. These custom tokens are passed to end-user client devices to sign in via signInWithCustomToken(). You are correct that in order to verify the custom token, you would use the URL specified by "client_x509_cert_url" in your service account JSON key file.

However, the verifyIdToken() does not verify these custom tokens, so the two URLs you mention are not conflicting. Instead, that method verifies ID tokens, which are used to authenticate directly to services like the Realtime Database and Storage. These are signed by Firebase private keys which you never see, as opposed to being signed by your service account's private key. The URL of the corresponding public keys happens to be https://www.googleapis.com/robot/v1/metadata/x509/secur...@system.gserviceaccount.com, which is what we hardcode into CLIENT_CERT_URL. This could change in the future, but it's relatively safe for us to hardcode this into our library.

While one can accomplish RS256 validation against alternate URL's using a third-party token library, it may be helpful to support this feature within the SDK.

I don't fully disagree, but this library is specifically meant to integrate with the Firebase Authentication service and is not meant to be a generic JWT generator / verifier. If and when Firebase Authentication recognizes JWTs signed by something other than the Firebase private keys (see next section, below), we will update this method accordingly.

Alternatively, it may be helpful to clarify within the documentation that delegated custom tokens (I'm using Auth0 for example) require the user to verify with a third party library. 

Auth0 does have an integration with the Firebase 3.x.x SDKs, but that integration requires a service account and still signs the tokens with your service account's private key at the end of the day. The tokens they sign are not signed with any Auth0 private keys. In the future, we may add support for third parties like Auth0 to sign tokens which we can recognize that wouldn't require you to share a service account's private key with Auth0. After all, our JWTs now implement and follow the OpenID Connect spec for benefits like this. However, this feature is not currently supported and probably won't be for a while. It is definitely on our long-term roadmap though. So, we recognize this feature request and plan to support it at some point in the future.

Okay, I think I wrote enough on this subject for a single response. Hopefully that gives you some more insight into the process and clears up any misconceptions. Let me know if you've still got questions!

Cheers,

Jacob

On Fri, Jul 15, 2016 at 3:17 AM, Andrew Johnson <set...@gmail.com> wrote:

Feature Request - Update FirebaseTokenGenerator.prototype.verifyIdToken with an optional "options" argument allowing one to specify an alternate client certificate url when using algorithm "RS256" (should be all non-legacy tokens).

Within node SDK v3, firebase.auth().verifyIdToken(idToken) relies on a hard-coded value for the google cert:

var CLIENT_CERT_URL = 'https://www.googleapis.com/robot/v1/metadata/x509/secur...@system.gserviceaccount.com';

Firebase can issue custom tokens from a service account, defined within a google project.  The JSON file resulting from service account creation contains a "client_x509_cert_url" property with a competing URL value to that predefined within "CLIENT_CERT_URL".  While one can accomplish RS256 validation against alternate URL's using a third-party token library, it may be helpful to support this feature within the SDK.  Alternatively, it may be helpful to clarify within the documentation that delegated custom tokens (I'm using Auth0 for example) require the user to verify with a third party library.  I think Firebase does a great job covering the fields here but your kid may NOT always be defined within the list of certs found at the hard-coded URL.

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/02371af6-586c-4b79-90ef-1dd2da76da7a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.