Ambassador setup

[travisghansen]

Ambassador setup

[mr-smithers-excellent]

Great news - I will have a chance to test this out this week. Will update this feed accordingly when ready.

[travisghansen]

Thanks for the diagram and info! Happy to see what can be done to facilitate the workflow.

I'm pretty detailed oriented so stick with for a few questions :) especially not being familiar with firebase:

• Are the users/user agents here typically system-to-system or are these end-users navigating to a service?
• Does firebase act as an oauth provider and/or openid connect?
• Does firebase really need to validate the token (ie: stateful session type stuff) or are simple assertion on the token data/claims sufficient?
• Are these typically single-page-apps?
• Does firebase have an endpoint for submitting the token for validation? Can you send me a link to the documentation if so to review?

I'm sure I'll have follow-ups based on the answers but that should be enough to get me started..

[mr-smithers-excellent]

Thanks for the quick reply. Happy to dig deep into the details with you. Let me preface this by saying, this auth flow is not yet in production and flexible if something simply doesn't make sense. Here's the answers to your questions:

• Are these typically single-page-apps?
  Yes, this particular flow is used for a public-facing React SPA. In particular, this flow would be used when a user wants to access their "My Account" page and requests are made to backend /user protected endpoints.

• Are the users/user agents here typically system-to-system or are these end-users navigating to a service?
  I think the above answer might explain this, but let me know if not. Essentially, this is a SPA talking to our RESTful backend with some protected endpoints.

• Does firebase act as an oauth provider and/or openid connect?
  According to their documentation, "[Firebase] leverages industry standards like OAuth 2.0 and OpenID Connect, so it can be easily integrated with your custom backend." We are using their JavaScript library on the front-end, giving users the ability to log in with Facebook, Google or Email/Password. Each method has its own Firebase auth provider that returns an idToken on successful authentication."

• Does firebase really need to validate the token (ie: stateful session type stuff) or are simple assertion on the token data/claims sufficient?
  Short answer - I'm not sure. Given the rest of the details I've provided, I would be happy to take your expertise here. The backend service needs to ultimately retrieve user account details from Firebase at some point in this flow. Right now, that's happening after the token validation. If helpful, I can do a diagram for the current process - let me know.

• Does firebase have an endpoint for submitting the token for validation? Can you send me a link to the documentation if so to review?
  Currently we are verifying tokens in individual microservices using the Firebase Admin SDK. Specifically, we are using the verifyIdToken method. A similar endpoint exists in the Firebase REST API, which would return a 400 status with an error if invalid and a 200 status with account info if valid.

[travisghansen]

OK, perfect thanks for the responses:

• So you manage in the interface your own login sequence direct in your app and then make the appropriate ajax requests or whatever to firebase to retrieve the token(s)?
• They never land on a firebase URL and get redirected correct?
• For the verifyIdToken method are you using the method signature with the boolean second parameter?
• Are you taking care of refreshing the token(s) as appropriate direct to firebase?

[mr-smithers-excellent]

• So you manage in the interface your own login sequence direct in your app and then make the appropriate ajax requests or whatever to firebase to retrieve the token(s)?
  The Firebase JS library handles all this for us. Here's an example for a Google login. Essentially, it will pop up the Google login form and returns the result (see step 5 in example).

• They never land on a firebase URL and get redirected correct?
  If they choose Google or Facebook, they would get the respective login form as a popup. An excellent example of a site using this would be: https://app.termly.io/user/login

• For the verifyIdToken method are you using the method signature with the boolean second parameter?
  Yes - this ensures the token was not revoked.

• Are you taking care of refreshing the token(s) as appropriate direct to firebase?
  Yes, although again the Firebase JS library handles this for us. The getIdToken method will automatically refresh, as necessary.

[travisghansen]

OK, getting close here:

• You presumably cannot or do not want to validate the token at the service layer?
• Do you intend on forwarding the X-Auth-Token down to the service(s) for some other reason? Or you want them completely out of the picture by using eas?
• Is the X-Auth-Token the idToken or is it an accessToken? Do you intend to send an accessToken down to service(s)?

[mr-smithers-excellent]

• You presumably cannot or do not want to validate the token at the service layer?
  We can, but would prefer to offload this functionality to the edge so it can be done in one place vs. at each individual service.

• Do you intend on forwarding the X-Auth-Token down to the service(s) for some other reason? Or you want them completely out of the picture by using eas?
  I think we still need the token, as it contains the user_id we'll need to look up user information in the database. On the server-side, I'm intending on using the Spring PreAuthenticatedAuthenticationProvider, which expects a token, but also expects it to be preauthorized. I'm unclear on what should ideally happen after eas authenticates the token. Should it pass it to the service as is? Any idea on the best practice here would be helpful.

• Is the X-Auth-Token the idToken or is it an accessToken? Do you intend to send an accessToken down to service(s)?
  The X-Auth-Token is the idToken that returns from Firebase after a successful login. It has basic user information embedded in the JWT. See below for an example of a decoded idToken. The way Firebase works, I don't believe I need an accessToken.

{
  "iss": "https://securetoken.google.com/firebase-project-name",
  "aud": "firebase-project-name",
  "auth_time": 1559756352,
  "user_id": "somelonguserid",
  "sub": "somesubhere",
  "iat": 1559756352,
  "exp": 1559759952,
  "email": "[email protected]",
  "email_verified": true,
  "firebase": {
    "identities": {
      "email": [
        "[email protected]"
      ]
    },
    "sign_in_provider": "password"
  }
}

[travisghansen]

Very good. Reviewing the docs appears to show that verifying the idToken via the REST api is not possible so I'll need to either look at what the SDKs are doing, or pull in the node sdk and make a specific plugin for firebase (which I'm completely open to). If you see something otherwise let me know, otherwise I'll start digging.

The existing jwt plugin handles everything the sdk does except the whole stateful revoking situation at the provider.

No best practice on what to do with the token after authentication. The reverse proxy will likely pass it down by default. We do have code that allows you to set/add headers during the auth process...for example pull the email claim out of the token and set it as X-Userinfo-Email or whatever. May or may not be helpful for your services.

[travisghansen]

So I read through the code and the revoked logic is pretty simple. It checks if the auth_time of the idToken is before (failure scenario) the validSince property of the user. It is possible to get the userinfo using: https://firebase.google.com/docs/reference/rest/auth#section-get-account-info

I'm inclined to just pull in the code, however, a benefit of doing it 'manually' would be to allow deeper custom assertions based on the userinfo above and beyond the revocation logic (for example emailVerified must be true, that kind of thing). The assertion engine is pretty strong and this seems like a prime use-case to put it to work.

Thoughts?

[mr-smithers-excellent]

When you say "pull in the code", do you mean using the Firebase NodeJS SDK in eas? And when you say "doing it manually", do you mean applying the same logic but in your JWT plugin? Just want to make sure I'm following.

[travisghansen]

Yeah sorry that wasn't very clear. Either way it will be a new plugin, the question is whether to use the nodejs sdk or just use standard jwt validation along with some custom http requests/etc with custom validation logic (infrastructure is already available for that).

Either way it's a simple integration and could be knocked out with very little code.

I'm leaning toward the custom route at this point simply because it seems more straight forward and will be far more powerful in the long haul.

[mr-smithers-excellent]

That sounds good to me. Seems logical to tackle this in a more generic fashion if it can be leveraged beyond Firebase. Let me know if there's anything we can do to help you.

[travisghansen]

Well, the plugin will be specific to firebase which is fine, just will be more powerful to use the raw data rather than the sdk and will facilitate more common configuration options that are in the others.

I'm currently knocking out some header work and then looking at server-side config_tokens, after that I'll get an API key for firebase and add this to the 0.2.0 release.

[travisghansen]

OK, so I finished up my other items and then spent an hour and knocked this out. I'll be committing shortly and getting it merged into master. It can optionally check revoked status, and any other arbitrary datapoints in the id_token and userinfo datasets (for example I tested to only allow a specific localId, but you could go bonkers with it).

I'll keep you posted about merge status and then once it's merged help you step through setup/configuration.

[travisghansen]

I just landed all my work including firebase_jwt auth plugin. Comment here when you're ready to give it a whirl and I can help you get going..

[travisghansen]

Still want help with this?