So I have looked at the following client library, implementing the OpenID Connect spec:
https://github.com/IdentityModel/oidc-client-js
It works as expected, and I can now allow users to login with Google, great.
This library specifically assumes a 'pure' web client application, i.e. an app that has 'no backend' from where it renders.
Now my webapp (like many others) wants to connect to the backend REST api resources that I own (or proxy).
It makes no sense to add additional authentication (after all the user is now logged in with Google, why would (s)he want to log in again).
So to recap, basically what happens is that the user wants to authenticate with Google in the client (because there is no need for me to force the user to make yet another login account specifically for my own platform), then the user wants to access my self-managed REST endpoints.
My question is: what common approach exists to allow my own server REST endpoints to allow the oidc granted access token?
I have made the following considerations:
1. Make a call at the server on every request (for example using passport.js) to verify the access token at the server side.
This almost certainly looks like an overkill, but it is the simplest implementation and keeps my server stateless, which is what you want from a REST api.
Philosophically it doesn't make sense to have your own backend be responsible for the authentication, since that would invalidate the entire use of delegating user authentication to the oidc protocol.
Although this seems like the way it could / should be done (IMO), nobody actually recommends this approach. Why is that?
2. Generate your own jwt at a /register and/or /login endpoint after the client has obtained an access token from the oidc provider, and implement your own auth flow for your personal resources.
I personally despise this approach, because you're basically duplicating authentication, system for refreshing tokens etc... which oidc already delivers and what you want is merely authorization for your resources based on the access token that you already have.
You would end up with a complex system that tries to match oidc and your own account system, which I find terrible (correct me if I'm wrong).
3. Store access tokens in server-side sessions / database to avoid having to repeat calls to the oidc provider at the server-side on every request.
This system seems broken overall. First you're going back to server-side sessions, which is what you don't want. I expect people to refer to this as a 'trade-off', but it totally invalidates the 'stateless approach' and I could just go back to server authentication (which I assume is the point not to).
Not only would you store access tokens on the server (should you really want / need to do that?(?)), you also need an entire flow again in back and forth communication between server and client because stored access tokens will expire, the client needs to refresh / re-initialize the flow, go back etc. None of this makes a lot of sense to me.
After long research online, there doesn't seem to be an established recommendation for this common scenario (probably the most common today) which sort of baffles me.
Is there a common approach that you can recommend and that tackles before-mentioned issues, and explain the 'why' in terms that are non-dubious, non-circumventing the actual question and just clear? Is there a clear argument on why number 1 is not a valid option?
I really don't understand why I'm spending so much time on this simple / common scenario but like to move forward from here instead of running circles.
