As far as I understood, the SS session uses the cache to be persisted and by default uses the MemoryCacheClient; meanwhile the session will be also saved within the request items (I assume for performance reason).
All that makes perfectly sense, but I’d like to use the session approach and be capable to decide later if activate the cache or not: in other word for now I’ll be fine with the “per request - Items” storage only.
I assume I could set a session id different per each request so my need will be accomplished, but I don’t like to pollute the memory cache for nothing.
Is there any way to do not involve the cache at all? I mean… I could write a CacheClient that uses the request items storage, but I wonder if there’s any better way to do that.
The purpose of a “Session” is to hold information about a user across multiple requests, if it’s not going to be persisted anywhere it defeats the purpose in having one. i.e. Authentication can’t work unless it can access the Users authenticated session. Users wouldn’t be able to Authenticate first, then access authenticated Services. They’d need to authenticate with every request, which they can only do with Auth Providers that implement IAuthWithRequest.
The ICacheClient is what holds the Session, it uses MemoryCacheClient by default primarily because it doesn’t require any external dependencies, but you can switch to use any of the other Caching Providers instead.
There’s no way in not using an ICacheClient, the session needs to be stored somewhere in order for it to be accessed from subsequent requests. If you’re concerned about Cache size you can reduce the Session Expiry, but when the session is evicted from the cache, the user loses their session and it will force them to re-authenticate.
I understand and that makes perfect sense.
My scenario is to authenticate the user using an OAuth2 bearer provided within every request.
I’m considering to validate the token against STS not on each request, but every n seconds and store the validate/decrypted token within the session mainly to use the token data later in the service layer.
I’m still not sure if validate the token on each request or not and leverage on the session feature.
I’m also still in doubt if validate the token using a custom AuthProvider (that implements IAuthWithRequest) or using a Filter: in both case I’m considering to set a custom session id reflecting the value of the bearer token and fill the session after the STS validation.
My last idea is to use a custom AuthProvider to validate the token and store in session the user claim and later on using a dedicated Filter (relying on the session previously filled after the token validation) to check if the token satisfy the scopes required by the service operation.
What do you think? AuthProvider or Filter to validate the bearer token and fill the session?
Hard to say, if it can fit within a Custom AuthProvider that would be preferred, but if it’s not a natural fit (i.e. requires too much friction), then I’d avoid the AuthFeature/Sessions entirely and just validate using a custom Request Filter. You can store any info in IRequest.Items so it’s available throughout the Request pipeline.