hajola / nextjs-firebase-authentication

⚠️ DEPRECATED! Example Next.js Firebase authentication application using iron session
28 stars 3 forks source link

No firebase admin? #1

Open heauton opened 4 years ago

heauton commented 4 years ago

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?

tettoffensive commented 4 years ago

@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.

jensmeindertsma commented 4 years ago

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 commented 4 years ago

@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?

tettoffensive commented 4 years ago

@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.

jensmeindertsma commented 4 years ago

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.

tettoffensive commented 4 years ago

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

tettoffensive commented 4 years ago

@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.