JWT Token vs Session Token for React Native And react Js - reactjs

Question

We are in the process of building customer app for an organisation , with technical stack
react js for portal and react-native for the mobile.
During the review, it was suggested to go for session id based user session instead of JWT Token based.
We also want to use OIDC FLow for Authentication and OAUTH2.0 for Authorization of API's
As there are suggestion for both JWT and Session ID which each of them has their own pros and cons.
Security team is insisting on the Session ID's with reasons below
JWT is Bulky , not revokable
JWTs are dangerous JWT vsSession
What should be our choice for security architecture
Do we need still Session Id to track
The Token used for the OIDC cannot be sent to UI,as it has privacy and security information
should we have to go for JWE?
Can we have hash of the token or correlation id corresponding to the OIDC TOkens and lookup on each call from client to backend , so that browser or client app need not know OIDC TOkens?
Do we really need bespoke auth service, Can API Gw itself along with any OIDC will be enough to implement end2end security without any need for writing spring base or any Authentication service
[![FLow][4]][4]

Answer 1

CONFIDENTIALITY
You can satisfy these concerns in a standard way via a couple of techniques, though they require a more complex flow:
Use opaque tokens that are not readable by internet clients and do not reveal any sensitive information - see The Phantom Token Pattern for how this works.
In the browser use only secure cookies (SameSite=strict, HTTP Only, AES256 encrypted), which can contain opaque tokens. See the Token Handler Pattern where there is a React SPA you can run and a Node token handler API you can plug in.
Generally these internet credentials behave like session IDs, which are also opaque, but you are using standard OAuth and your APIs still end up authorizing via digitally verifiable JWT access tokens.
TOKEN HANDLER PATTERN
For SPAs the idea is to enable a setup like this, where you plug in (and perhaps adapt) open source token handler components, rather than needing to develop them yourself. This pattern should work with any Authorization Server:
Key benefits are as follows - see these Curity resources for further details:
SPA uses only the strongest SameSite=strict cookies, with no tokens in the browser
SPA can be deployed to many global locations via a Content Delivery Network
By default, cookies are only used on Ajax requests to APIs, which gives the SPA best control over usability aspects
API FLOWS
When calling APIs the flows then work like this, and typically involve a reverse proxy placed in front of APIs, so that API code remains simple:
Web clients send a secure cookie, and a cookie decryption gets the opaque token. A second plugin then gets a JWT from the opaque token and forwards it to APIs.
Mobile clients send an opaque token to the same API paths, in which case the cookie decryption plugin does nothing. The second plugin then gets a JWT from the opaque token and forwards it to APIs.
Note that the client can still receive an expires_in field if it wants to perform optimizations to check the lifetime of access tokens, but I have always advised against this, and to instead just handle 401s reliably in clients, like this:
private async fetch(method: string, path: string): Promise<any> {
try {
// Try the API call
return await this.fetchImpl(method, path);
} catch (e) {
if (!this.isApi401Error(e)) {
throw ErrorHandler.handleFetchError(e);
}
await this.oauthClient.refresh();
try {
// Retry the API call
return await this.fetchImpl(method, path);
} catch (e) {
throw ErrorHandler.handleFetchError(e);
}
}
}