C
C#12mo ago
TYoemtais.z

API does not store keys from IdentityServer to validate tokens

I have two machines, one identity server and second REST API A user through the API logs in, goes post to IS, in response IS returns JWT The user authenticates himself to the API with each data request. And everything was working fine, but today I noticed that there is an unusually high load on my IS It turns out that every time the user queries the API for data, the API sends a request to IS. But the API should itself check if the token is correct. API is on .NET 6 and LicenseServer is on .NET Core 2.1 API sends out as many as two requests to IS for each user request: 1. GET /.well-known/openid-configuration/jwks HTTP/1.1 IS response -> HTTP: HTTP/1.1 200 OK 2. POST /connect/token HTTP/1.1 IS response -> HTTP/1.1 400 Bad Request And this is happening after the user has already successfully logged in. IS setup: new Client { ClientId = "native_clien AllowedGrantTypes = new[] {"password", "client_credentials", "external" }, AccessTokenType = AccessTokenType.Jwt, AccessTokenLifetime = 600, //86400, IdentityTokenLifetime = 600, //86400, UpdateAccessTokenClaimsOnRefresh = true, AbsoluteRefreshTokenLifetime = 2592000, AllowOfflineAccess = true, RefreshTokenExpiration = TokenExpiration.Absolute, RefreshTokenUsage = TokenUsage.OneTimeOnly, AlwaysSendClientClaims = true, Enabled = true, RequireClientSecret = true, ClientSecrets = new List<Secret>{ new Secret(configuration.GetConnectionString("NativeClientApiKey").Sha256()), }, AllowedScopes = new List<string>{ "api_default", "offline_access", } }, API setup: services.AddAuthentication(o => { o.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme; o.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme; }) .AddJwtBearer(o => { o.Authority = configuration.GetSection("IsHost").Value; o.RequireHttpsMetadata = true; o.Audience = "api_default"; }); I've get 2x more load to IS than to API, when there should be a few dozen requests per day, not tens of thousands
2 Replies
aquaritek
aquaritek12mo ago
This is actually the correct behavior of an OAuth/Oidc environment. Identity Server acts as the broker in all requests and is the only source of truth for Authentication & Authorization. When a user signs in they are given an opaque token (Jwt in this case) that references within itself a set of resources they can communicate with such as your API service. This token also includes access to the operation session for that token (user) on the issuing server in this case Identity Server. When you make a request to the API service the API must validate that token against your Identity Server instance to see if the token is valid to perform said action. The reason for this is because the IS instance is the only source of truth. Your API instance remains dumb essentially - as well as any other services you may create. They're job is to always validate against the source of truth before moving forward.
TYoemtais.z
TYoemtais.zOP12mo ago
Thank you for your reply. But the keys on my IS do not change, it is closed to the outside world so I would like to use the offline_access capabilities. Since in my case the API can validate the token by itself having the obtained keys from the IS why should it do it for every request?

Did you find this page helpful?