I am using the OIDC protocol in order to perform authentication.

The flow that i'm using is the authorization code flow.

When a user authenticates through the Authorization Server, my client application backend receives an id_token containing information about the user.

At this point, i consider him as authenticated since i can verify the claims inside the id_token and validate the signature.

I would like to keep my own cookie based session and ignore the id_token after i'm done with authentication, of course i would extract some of the claims from the token but i don't want to use any refresh token. In fact i would like to have my own session expiration time.

I don't care if the user claims change on the Resource Server side while my application session is still active and based on old claims.

Is it secure enough ? Should i only rely on id_token and refresh it after it expires ?

CodePudding user response：

Is it secure enough ?

It depends on what you want to be protected from. Are you using PKCE with authorization_code?

Should i only rely on id_token and refresh it after it expires ?

I would suggest you throw away the ID Token and call explicitly with the Access Token the user_info endpoint to retrieve User claims so that you don't have to handle in your Client the crypto material required to verify the ID Token "authenticity". Even if you can download the public key from the jwks_uri, there is only one way to ensure that the token is legit, it is to request the one who forged it. Cryptographic verification of the ID Token to gain trust on it is acceptable when you are in a trusted zone only.

In order to harden things, check if your Authorization Server supports more modern client authentication (client_secret_jwt, private_key_jwt). So that your client authentication doesn't transmit the client secret in clear text but create an ephemeral JWT and sign it with HMAC(ClientSecret) for client_secret_jwt or a concrete private key for private_key_jwt)

Reference(s)

CodePudding user response：

PRE-OAUTH WEB SOLUTIONS

That's kind of correct and how SAML solutions used to work, 10 or so years ago. Apps received a SAML assertion in their back end, verified it, then considered their app authenticated.

The back end then issued application level cookies to the browser, with their preferred session time. The ID token is similar to a SAML assertion, and tells the how, when and who of authentication.

APIs AND MOBILE APPS

Then mobile apps came along, which do not use cookies. And companies started building APIs that could serve both web and mobile apps. Both web and mobile apps would send an access token to APIs. The APIs should follow API security best practices, which involves validating a JWT access token on every request.

OAuth also gives APIs design patterns for backend authorization, notably scopes and claims. If you have a standalone web app these may not be especially important, but these authorization patterns are worth being aware of, especially as the backend grows.

WEB APPLICATION COOKIE LAYER

For browser based apps it is still recommended to have an application cookie layer, since keeping tokens out of the browser is a current best practice. This can be combined with an API gateway that translates HTTP-only cookies to JWT access tokens, then forwards the JWT to APIs. Read more about this in this Token Handler article.

SUMMARY

If you have a standalone web app with a web backend, then using just ID tokens and application cookies can be sufficient. If you are also developing APIs you will need access tokens and refresh tokens as well.