user9795472
user9795472

Reputation:

Architecting and thinking about Authentication

I am architecting a new Angular SPA, and I am confused as to what action my back end plays in this given that FireBase already authenticated my user on the front end, and what that action is supposed to do to instantiate some form of a user session?

Here is where my thinking breaks down:

  1. login button pressed
  2. send username and password to Firebase
  3. Firebase sends reply back with a token string back to my front end
  4. POST this string to my own back end
  5. (why am i verifying this token here?) but i verify this token with Firebase-admin npm package
  6. encrypt 'something'
  7. send 'something' back to the front end so user is authenticated in LocalStorage

When thinking of authentication, my process breaks down around this point. My boss says that the back end should always be stateless, so...

What do I encrypt back to the client after step 5, and are there any additional things I am missing?

///////////////////////////
///////////////////////////
///////////////////////////

edit for posterity:

The confusion for me lied in mixing levels of abstraction, specifically abstracting the idea of creating a session away from simply one login page. I got the most benefit when I began to think of sessions as something that isn't managed by one component but rather a process that wraps the state of the user interacting with multiple components.

Upvotes: 1

Views: 40

Answers (1)

Doug Stevenson
Doug Stevenson

Reputation: 317798

Firebase Authentication automatically manages an ID token internally. If you want the user to invoke some backend API, but only if they're allowed, what you're supposed to do is get that token from the client SDK, send it to the backend with the request, and the backend uses the Firebase Admin SDK to verify that token on each call.

That linked documentation has code samples to illustrate in more detail how it works for different client and server platforms.

Upvotes: 2

Related Questions