Search code examples
jwtopenid-connectopenid

OpenID Connect JWT token verification and usage strategy for backend api - jwks or session?

I'm little confused about backend api authorization flow with OIDC.

I have react SPA app with rest backend api.

I want to allow app clients register their own OIDC providers for login/registration purpose.

What is the strategy to use for OpenID Connect JWT token verification and usage?

Currently I do this:

  1. Client adds provider specifying clientId, clientSecret, issuer.
  2. On backend side I fetch provider metadata using OIDC Discovery.
  3. After client hits login button using provider with auth code flow we end up at backend callback handler where I exchange code for:
  {
      access_token: 'str',
      id_token: 'str.str.str',
      scope: 'openid profile email',
      expires_at: 1628797367,
      token_type: 'Bearer'
  }

Now is a question, what to do next? What token to send to app for api request usage and how to verify it on each request?

I can send id_token to app and then on each api request use loaded from provider JWKS to verify id_token.

Or I can just authorize/register user based on id_token and create my own JWT token that will be sended to app for api requests usage.

Used packages: hapi, node-openid-client

Solution

  • So the id_token is there to provide information about the authenticated user. The access token is the one you want to use to access user's resources.

    You can verify and decode the id_token on the backend and use it to register a new user in your system, and create a session for them - or just create the session if it is an already registered user.

    The question is - what backend resources is your SPA calling. If these are APIs in control of the OIDC Provider, then you just need to add their access token to the request and it will be validated. I assume, though, that these are your APIs. Then you have two options:

    1. If you received an access token from the OP you can still use it to access your APIs, if the OP exposes an introspection endpoint. Every time you get a request from your SPA you would have to call the OP to check whether the token is valid and possibly get data associated with that token - like issuer, subject, audience, etc. You can use these claims to perform authorization decisions - whether to allow access for that request or not.

    2. Once you complete the authorization code flow with the OP you can issue your own access token based on the information you got from the OP. You can then easily verify that token on every request. In this scenario you have more control over what ends up in that token - for example you can introduce roles for users, etc.

    If you only access your own APIs and as you already have a backend for performing OIDC flows, I would recommend keeping the response from OP in the backend and issue a plain old session to the SPA. Your APIs can validate the session by calling your authorization backend. This way you have no tokens lying around in the SPA.