nextjs-firebase-authentication icon indicating copy to clipboard operation
nextjs-firebase-authentication copied to clipboard

No firebase admin?

Open heauton opened this issue 5 years ago • 7 comments
trafficstars

Thanks for putting up this example. While examining, I noticed it's not using firebase-admin, as opposed to other example. May I ask the reasoning behind this?

heauton avatar May 22 '20 09:05 heauton

@calspre I think you actually do need to use firebase-admin. Because in order to make authenticated requests to firestore for example, you need to verifyIdToken due to the nature of the serverless environment.

tettoffensive avatar Jun 02 '20 04:06 tettoffensive

I'm working on an example with TypeScript and firebase-admin. I still need to figure out what verifyIdToken has to do with this. @tettoffensive could you give me a basic rundown?

Also, is there a reason using the client firebase library in API routes would be considered a bad practice?

jensmeindertsma avatar Jun 12 '20 08:06 jensmeindertsma

@tettoffensive I believe verifyIdToken is actually not necessary because req.session is encrypted with a password that is secret. So no-one with bad intentions can send a request to the API and get data back by supplying random ID's, it works by getting the ID from the session that only exists when a user is signed into the application. I thus believe it is not needed. Can you confirm this?

jensmeindertsma avatar Jun 17 '20 13:06 jensmeindertsma

@jensmeindertsma the only thing is that the token occasionally expires (1 hr or so). The client can get the new token and then update the session with that new token. So if you’re not verifying it you could have an expired token.

One thing I have to fix in my app is if it’s in the background for a bit and the token expires then it takes a second for firebase’s token refresh handler to fire. So calls made before that are unauthed.

tettoffensive avatar Jun 17 '20 14:06 tettoffensive

I think that we don't need a token at all! The server can fetch data with the uid that can be stored in the session. This session is decrypted using a secret password. A session encrypted with this password only exists on the request when the client behind the request has signed in using our API ( this sets the session ). Thus we can be sure that our user is authenticated when there is a decryptable session on the request. Am I right? I'm working on a complete example that will be done in a couple of days. I'll ask some people to check the security of it.

jensmeindertsma avatar Jun 17 '20 14:06 jensmeindertsma

You may be right. Though I’m no security expert.

tettoffensive avatar Jun 17 '20 15:06 tettoffensive

@jensmeindertsma another thing to keep in mind, if you're not using verifyToken and you want to have user roles via custom claims like:

// Verify the ID token first.
admin.auth().verifyIdToken(idToken).then((claims) => {
  if (claims.admin === true) {
    // Allow access to requested admin resource.
  }
});

But perhaps there's a way around this.

tettoffensive avatar Jun 17 '20 19:06 tettoffensive