Is it best practice to use sessions?

[DarkLite1]

Library

• @azure/msal-browser@2.1.0

Description

I've asked the same question on StackOverflow without any response so I'll try it here again.

I'm very new to web development but I've manged to set up a client and server app. The front-end uses msal.js to authenticate the user to Azure AD and the backend receives the access_token and verifies if the token is valid with passport-azure-ad. This is the token flow:

So far all is working fine except that I'm wondering how it would work on heavy load. In the Microsoft example they set the session to false.

// API endpoint
app.get("/hello",
    passport.authenticate('oauth-bearer', {session: false}),

This probably makes passport verify each and every call. Might this be an issue when invoked many times? We use passport as middlewware for graphql queries, nutations, resolvers, ...

  app.use(passport.initialize())
  passport.use(bearerStrategy)

  app.use(
    passport.authenticate('oauth-bearer', { session: false }),
    (req, _res, next) => {
      console.log('User info: ', req.user)
      console.log('Validated claims: ', req.authInfo)
      next()
    }
  )

This is a bit unclear from the docs of the bearerStrategy for our v2 endpoint. If this becomes an issue it might be needed to create a graphql login and logout resolver that is only called when a user logs in and set up a session on the backend.

Thank you for helping to clear up my confusion.

[derisen]

@DarkLite1 as far as I know, the best practice for RESTful APIs is to be stateless i.e. each request should contain all the information that the API needs to decide whether and how to respond. As such, sessions are not recommended for REST APIs, in particular with respect to scalability (e.g. your API should be able to handle requests from any client type, some of which might not be able to establish a session). Of course, this might be in conflict with your performance needs. In that case, perhaps you should reconsider your app topology -a web application, instead of SPA + web API, might be the better approach for you.

[DarkLite1]

Thank you for the clarification @derisen . For me personally it would be a lot easier to not be using sessions, setting up cookies, maintaining the session store, ... . But, when using a session on the backend and having a login graphql mutation called by the client only once, than Azure AD will also be called only once to verify the token and from that point on a session would be started to avoid calling Azure AD multiple times to verify the token.

Verifying the token with passport.authenticate() and session: false for every call is fine by me. I'm just wondering at which point Azure AD will say "Hey man, you're sending us too many verification requests, we're baling out!".

Could you elaborate a bit on this? How will Azure handle so many requests?

[derisen]

Oh I understand your concern, but I wouldn't worry about it: Azure AD handles around a few billion requests everyday! Now how it deals with such scales is beyond me of course, but I would recommend checking out this blog post.

[DarkLite1]

Awesome! Going for a stateless API simplifies the design a lot! Thank you very much for the information. Closing this one.