I have the following client configured on the IdentityServer4 host side:
new Client
{
ClientId = "myClient",
....
RedirectUris = {"https://localhost:44001/home/claims",
"https://localhost:44001/"}
....
}
I am currently trying to get it to return in such a way that it works regardless of which controller in the client app it originates from (since redirectURI is configured at startup time on the client app & has to match the server's client config).
In the client app startup, the relevant code:
app.UseOpenIdConnectAuthentication(new OpenIdConnectAuthenticationOptions
{
...
ClientId = "myClient",
RedirectUri = "https://localhost:44001/",
...
}
When I set the redirectUri to the second option above, "https://localhost:44001" on the client startup, I get redirected to the client error controller with the following error:
"Sorry, there was an error : unauthorized_client Invalid
redirect_uri".
In addition, the server outputs the following error to console:
Exception thrown: 'System.FormatException' in
System.Private.CoreLib.dll
IdentityServer4.Validation.AuthorizeRequestValidator:Error: Invalid
redirect_uri: https://localhost:44001/ { "ClientId": "myClient",
... "AllowedRedirectUris": [
"https://localhost:44001/home/claims",
"https://localhost:44001/" ], "SubjectId": "anonymous", "RequestedScopes": "", "Raw": {
"client_id": "myClient",
"redirect_uri": "https://localhost:44001/",
"response_mode": "form_post",
"response_type": "code id_token",
... } }
It's almost like you cannot have multiple redirect URIs for a client, but that can't be right.
Related
I have an Identity Server 4 instance running at https://localhost:5443/ and a client React.js application running at http://localhost:3000/ and making a reference to the oidc-client library in order to establish the communication. I've been following more or less this article.
The way I've configured the client (in-memory) on the Identity Server is as follows:
new Client
{
ClientId = "react-js-implicit-flow",
ClientName = "Some App name",
ClientUri = "http://localhost:3000",
AllowedGrantTypes = GrantTypes.Implicit,
RequireClientSecret = false,
RedirectUris = { "http://localhost:3000/signin-oidc", },
PostLogoutRedirectUris = { "http://localhost:3000/signout-oidc" },
AllowedCorsOrigins = { "http://localhost:3000" },
AllowedScopes = new List<string>
{
IdentityServerConstants.StandardScopes.OpenId,
IdentityServerConstants.StandardScopes.Profile,
"weatherapi.read"
},
AllowAccessTokensViaBrowser = true
}
and the way it looks like on the Ract.js app is like this:
In general, everything goes well. I can login and logout from the Identity Server but the issue is that here:
I get no value (it is null) and this stops the Identity server from redirecting me back to the client application right after logout. If I hard code it (http://localhost:3000/signout-oidc) it works. But for some reason it is just not available.
During the logout this is what the Identity Server logs show:
So, no error, no nothing but I still can not navigate back to the client app after logout.
You do not provide an idTokenHint (id token) with your logout request like the following:
const mgr = new Oidc.UserManager(settings);
const signoutUrl = await mgr.createSignoutRequest({id_token_hint: user.id_token});
window.location.href = signOutUrl.url;
//or
await mgr.signoutRedirect({id_token_hint: user.id_token});
//or just
await mgr.signoutRedirect();
//it will try to attach id_token internally
Lack of the token is the reason for Identityserver to skip the post_logout_redirect_url parameter.
Identityserver has to validate the parameter against the client's configuration, but without the token it can't.
What solved the issue for (me thanks to answer by #d_f) was to change something on the client side and more specifically: src/services/userService/signoutRedirect.
I've finally been able to get an access token from IdentityServer, and use it to retrieve the UserInfo.
However it seems that the access token I'm getting from IdentityServer only contains the sub claim.
Here is an example token
eyJhbGciOiJSUzI1NiIsImtpZCI6IjVCOTBDN0JBNkExMjI2RjEyMEU0QzJGOEQzMjIwMzAxIiwidHlwIjoiYXQrand0In0.eyJuYmYiOjE2MzcwNTI5MDIsImV4cCI6MTYzNzEzOTMwMiwiaXNzIjoiaHR0cHM6Ly9sb2NhbGhvc3Q6NDQzNTkiLCJhdWQiOiJ3ZWF0aGVyZm9yZWNhc3RzIiwiY2xpZW50X2lkIjoiU3NvQXBwbGljYXRpb25DbGllbnQiLCJjZW50cmFsLXRoZWNsaWVudCI6IlRoZSBTU08gY2xpZW50Iiwic3ViIjoiYTUxYjBkZWMtODQyYS00ZWMyLTgwMGEtMzRmYWQyNTRjZTBlIiwiYXV0aF90aW1lIjoxNjM3MDUyMDcyLCJpZHAiOiJsb2NhbCIsImp0aSI6IkQ3Rjc2MzgwQzNERDkzMzVERDVFMTE1NjE4MDkzNEUwIiwic2lkIjoiOEY1OUZFMjRDNkY1NTM2ODhEQzVCMTM5QjNFQUU1MTMiLCJpYXQiOjE2MzcwNTI5MDIsInNjb3BlIjpbIm9wZW5pZCIsInByb2ZpbGUiLCJlbWFpbCIsIndlYXRoZXJmb3JlY2FzdHMucmVhZCIsIndlYXRoZXJmb3JlY2FzdHMud3JpdGUiXSwiYW1yIjpbInB3ZCJdfQ.MiDmgc7AzbVpogbp8ID3WvJ0eo4a30_taxR9EI9ylyJASSdOiNSsk-sGuW-YnJIzf668EQGkTym6FMIvOyTxem9DxxIs8nI_rboHLvuvj4e7CtJeELwbZyraZtAxjVjm9tn0BVRZxuskzb6XSq4xGrt2ag_E0Re5MeQOjtyL0EeMS5md5IEywfD7ThH7pIu8SofFvV5tAYbwO-OPd5YyqpPGKXslRtFlyc7lj9faQh-e2CRMql5rSwhJRqCiaIaLxvXk8ZwISfdhmuyzHA88xrzXkqTK_RElhq4PY_GqpRe64nMvIBrkSeoOGLzlQNE9wa58UypZFFV4l8Cpy3_P2Q
Here is the decoded token
I should be able to use this token to call the /connect/userinfo endpoint
And I can see this in the Output window:
IdentityServer4.Hosting.EndpointRouter: Debug: Request path /connect/userinfo matched to endpoint type Userinfo
IdentityServer4.Hosting.EndpointRouter: Debug: Endpoint enabled: Userinfo, successfully created handler: IdentityServer4.Endpoints.UserInfoEndpoint
IdentityServer4.Hosting.IdentityServerMiddleware: Information: Invoking IdentityServer endpoint: IdentityServer4.Endpoints.UserInfoEndpoint for /connect/userinfo
IdentityServer4.Endpoints.UserInfoEndpoint: Debug: Start userinfo request
IdentityServer4.Validation.BearerTokenUsageValidator: Debug: Bearer token found in header
IdentityServer4.Endpoints.UserInfoEndpoint: Trace: Calling into userinfo request validator: IdentityServer4.Validation.UserInfoRequestValidator
IdentityServer4.Validation.TokenValidator: Trace: Start access token validation
IdentityServer4.EntityFramework.Stores.ClientStore: Debug: SsoApplicationClient found in database: True
IdentityServer4.Stores.ValidatingClientStore: Trace: Calling into client configuration validator: IdentityServer4.Validation.DefaultClientConfigurationValidator
IdentityServer4.Stores.ValidatingClientStore: Debug: client configuration validation for client SsoApplicationClient succeeded.
IdentityServer4.EntityFramework.Stores.ClientStore: Debug: SsoApplicationClient found in database: True
IdentityServer4.Stores.ValidatingClientStore: Trace: Calling into client configuration validator: IdentityServer4.Validation.DefaultClientConfigurationValidator
IdentityServer4.Stores.ValidatingClientStore: Debug: client configuration validation for client SsoApplicationClient succeeded.
IdentityServer4.Validation.TokenValidator: Debug: Calling into custom token validator: IdentityServer4.Validation.DefaultCustomTokenValidator
IdentityServer4.Validation.TokenValidator: Debug: Token validation success
{
"ValidateLifetime": true,
"AccessTokenType": "Jwt",
"ExpectedScope": "openid",
"JwtId": "2FB8F8A941528DAF18D8C523BCC9A770",
"Claims": {
"nbf": 1637062004,
"exp": 1637148404,
"iss": "https://localhost:44359",
"aud": "weatherforecasts",
"client_id": "SsoApplicationClient",
"central-theclient": "The SSO client",
"sub": "959c9bfa-ed30-4638-9986-63cf1589eff8",
"auth_time": 1637060908,
"idp": "local",
"jti": "2FB8F8A941528DAF18D8C523BCC9A770",
"sid": "75C294FC15A544FE60E361B495EE5BCA",
"iat": 1637062004,
"scope": [
"openid",
"profile",
"email",
"weatherforecasts.read",
"weatherforecasts.write"
],
"amr": "pwd"
}
}
IdentityServer4.Endpoints.UserInfoEndpoint: Trace: Calling into userinfo response generator: IdentityServer4.ResponseHandling.UserInfoResponseGenerator
IdentityServer4.ResponseHandling.UserInfoResponseGenerator: Debug: Creating userinfo response
IdentityServer4.ResponseHandling.UserInfoResponseGenerator: Debug: Scopes in access token: openid profile email weatherforecasts.read weatherforecasts.write
IdentityServer4.EntityFramework.Stores.ResourceStore: Debug: Found openid, profile, email identity scopes in database
IdentityServer4.ResponseHandling.UserInfoResponseGenerator: Debug: Requested claim types:
IdentityServer4.ResponseHandling.UserInfoResponseGenerator: Information: Profile service returned the following claim types:
IdentityServer4.Endpoints.UserInfoEndpoint: Debug: End userinfo request
You can even see my custom dedicated client claims being appended during the token validation.
But yet only the sub claim is returned from the identityserver userinfo endpoint...
How can I fix this?
Edit
I added the ProfileService, and it's being called. But as Dejan already mentioned, RequestedClaimTypes is empty. However I updated the database by adding
[{"type":"email","identityResourceId":1003},{"type":"sub","identityResourceId":1003}]
records to the IdentityResourceClaim table. In the output window I can now see that the email and sub claims are requested:
IdentityServer4.Validation.TokenValidator: Debug: Token validation success
{
"ValidateLifetime": true,
"AccessTokenType": "Jwt",
"ExpectedScope": "openid",
"JwtId": "C37AF164BF3A7DE6A28FA7538683248F",
"Claims": {
"nbf": 1637069285,
"exp": 1637155685,
"iss": "https://localhost:44359",
"aud": "weatherforecasts",
"client_id": "SsoApplicationClient",
"central-theclient": "The SSO client",
"sub": "959c9bfa-ed30-4638-9986-63cf1589eff8",
"auth_time": 1637067659,
"idp": "local",
"email": "pieterjan#example.com",
"name": "Pieterjan",
"jti": "C37AF164BF3A7DE6A28FA7538683248F",
"sid": "BBFA9FD0A06824FA4E982DB1D3669A86",
"iat": 1637069285,
"scope": [
"openid",
"profile",
"email",
"weatherforecasts.read",
"weatherforecasts.write"
],
"amr": "pwd"
}
}
IdentityServer4.Endpoints.UserInfoEndpoint: Trace: Calling into userinfo response generator: IdentityServer4.ResponseHandling.UserInfoResponseGenerator
IdentityServer4.ResponseHandling.UserInfoResponseGenerator: Debug: Creating userinfo response
IdentityServer4.ResponseHandling.UserInfoResponseGenerator: Debug: Scopes in access token: openid profile email weatherforecasts.read weatherforecasts.write
IdentityServer4.EntityFramework.Stores.ResourceStore: Debug: Found openid, profile, email identity scopes in database
IdentityServer4.ResponseHandling.UserInfoResponseGenerator: Debug: Requested claim types: email sub
IdentityServer4.ResponseHandling.UserInfoResponseGenerator: Information: Profile service returned the following claim types: email name
IdentityServer4.Endpoints.UserInfoEndpoint: Debug: End userinfo request
IdentityServer4.Hosting.IdentityServerMiddleware: Trace: Invoking result: IdentityServer4.Endpoints.Results.UserInfoResult
The code finally enters the ExternalLoginCallback, but the await signInManager.GetExternalLoginInfoAsync() returns null now.
The response from https://localhost:44359/connect/userinfo is
{
"email": "pieterjan#example.com",
"name": "Pieterjan",
"sub": "959c9bfa-ed30-4638-9986-63cf1589eff8"
}
The userinfo endpoint calls GetProfileDataAsync from IdentityServer4.Services.IProfileService to obtain the requested claim values. So the simple solution would be to implement that service.
Assuming you have your user manager defined as IMyUserManager and that it has the methods referenced here (GetClaimsForUser and IsActive), the simplified implementation might look like this:
public class MyProfileService : IProfileService
{
private readonly IMyUserManager userManager;
public MyProfileService(IMyUserManager usermanager)
{
this.userManager = userManager;
}
public async Task GetProfileDataAsync(ProfileDataRequestContext context)
{
// context.RequestedClaimTypes will contain the claims you requested when invoking the token endpoint
var myClaims = await userManager.GetClaimsForUser(context.Subject, context.RequestedClaimTypes);
context.IssuedClaims = myClaims;
}
public async Task IsActiveAsync(IsActiveContext context)
{
context.IsActive = await userManager.IsActive(context.Subject);
}
}
You would then need to configure IdentityServer4 to use this implementation, by calling AddProfileService at startup like this:
services.AddIdentityServer()
// ...
.AddProfileService<MyProfileService>();
I should also add that, in order for your wanted claim to be present in context.RequestedClaimTypes, it needs to be associated with the scopes you directly request when making a call to token endpoint.
At startup, when configuring IdentityServer4, make sure the identity resources you supplied to your AddIdentityResources call contains the required claim.
I am trying to set up a web app and web API using Azure B2C as the auth mechanism, but apparently failing miserably. My web app and API are both registered in Azure, the return URIs set properly, a scope created for the API which is then granted to the app, an app client secret created, and I have tested this locally WITH IT WORKING, but now that I've published my API to my live Azure App Service, it goes wrong for some reason.
Locally, I have run my web API and web app separately, signed into the web app and then obtained an access token, called the API (running locally) and all works well. However, now the API is published and running live (i.e. https://api.myapp.net), I am running the web app locally, calling the live API and every single time I request an access token then send it to the API I get a 401 Unauthorized because apparently the signature is invalid. WHY?!?!?!?
Below are slightly redacted copies of my startup and app settings files. Note I also have Azure Front Door set up to redirect "login.myapp.net" to "myapp.b2clogin.com", this has been tested with both the user flows on the Azure dashboard and with my own app running locally and all is fine.
Here is my web app's Startup.cs file:
services.AddRazorPages();
services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
.AddMicrosoftIdentityWebApp(Configuration.GetSection(Constants.AzureAdB2C))
.EnableTokenAcquisitionToCallDownstreamApi(new string[] { "https://myapp.net/api/query" })
.AddInMemoryTokenCaches();
services
.AddControllersWithViews()
.AddMicrosoftIdentityUI();
services
.AddServerSideBlazor()
.AddMicrosoftIdentityConsentHandler();
services.AddAuthorization(authorizationOptions =>
{
authorizationOptions.AddPolicy(
App.Policies.CanManageUsers,
App.Policies.CanManageUsersPolicy());
});
services.Configure<OpenIdConnectOptions>(OpenIdConnectDefaults.AuthenticationScheme, options =>
{
options.ResponseType = "code";
options.SaveTokens = true;
}).AddInMemoryTokenCaches();
services.AddSingleton<IHttpContextAccessor, HttpContextAccessor>();
services.AddSingleton<AppData>();
services.AddScoped<IAuthTokensService, AuthTokensService>();
services.AddOptions();
My web app's appsettings.json file:
"AzureAdB2C": {
"Instance": "https://login.myapp.net",
"ClientId": "my-web-app-client-id",
"CallbackPath": "/signin-oidc",
"Domain": "my-b2c-tenant-id",
"SignedOutCallbackPath": "/signout/B2C_1_SignUpIn",
"SignUpSignInPolicyId": "B2C_1_SignUpIn",
"ResetPasswordPolicyId": "B2C_1_PasswordReset",
"EditProfilePolicyId": "B2C_1_ProfileEdit",
"ClientSecret": "my-client-secret"
},
"Logging": {
"LogLevel": {
"Default": "Information",
"Microsoft": "Warning",
"Microsoft.Hosting.Lifetime": "Information"
}
},
"AllowedHosts": "*"
Calling for an access token in my web app:
private readonly ITokenAcquisition _tokenAcquisition;
public AuthTokensService(ITokenAcquisition tokenAcquisition)
{
_tokenAcquisition = tokenAcquisition;
}
/// <inheritdoc />
public async Task<string> GetToken()
{
return await _tokenAcquisition.GetAccessTokenForUserAsync(new[] { "https://myapp.net/api/query" });
}
My web API's Startup.cs file:
if (Configuration.GetConnectionString("SQLConnection") == null)
{
throw new InvalidOperationException("ConfigureServices: Connection string 'SQLConnection' returned null.");
}
services.AddDbContext<MyAppDbContext>(
option => option.UseSqlServer(Configuration.GetConnectionString("SQLConnection")));
services.AddMicrosoftIdentityWebApiAuthentication(Configuration, Constants.AzureAdB2C);
services.AddControllers();
services.AddScoped<IMyRepository, MyRepository>();
And my web API's appsettings.json file:
"AzureAdB2C": {
"Instance": "https://login.myapp.net",
"ClientId": "my-web-api-client-id",
"Domain": "my-b2c-tenant-id",
"SignUpSignInPolicyId": "B2C_1_SignUpIn",
"SignedOutCallbackPath": "/signout/B2C_1_SignUpIn"
},
"ConnectionStrings": {
"SQLConnection": "Server=(localdb)\\mssqllocaldb;Database=MyAppDebug;Trusted_Connection=True;MultipleActiveResultSets=true"
},
"Logging": {
"LogLevel": {
"Default": "Debug",
"System": "Information",
"Microsoft": "Information"
}
}
Can anybody advise on why this is? The only sensible answer I've seen anywhere online is that Blazor uses a v1.0 endpoint to obtain public keys whereas v2.0 is required for the API (see here) and I can see this happening with my tokens, but when I followed the fix given on the Microsoft documentation, I then get an exception thrown on startup of my web app IDX20807: Unable to retrieve document from: 'System.String'.
I have cloned the repo from the redux-oidc-example and it works for the most part but after a few hours it gives the following error:
Action payload: ErrorResponse: login_required
at new e (oidc-client.min.js:1)
at t [as _processSigninParams] (oidc-client.min.js:1)
at t [as validateSigninResponse] (oidc-client.min.js:1)
at oidc-client.min.js:1
UserManager.js looks like this:
const userManagerConfig = {
client_id: 'js.dev',
client_secret: 'secret',
redirect_uri: `${window.location.protocol}//${window.location.hostname}${window.location.port ? `:${window.location.port}` : ''}/callback`,
response_type: 'id_token token',
scope: 'openid email profile role offline_access',
authority: 'http://localhost:8080',
silent_redirect_uri: `${window.location.protocol}//${window.location.hostname}${window.location.port ? `:${window.location.port}` : ''}/silent_renew.html`,
automaticSilentRenew: true,
filterProtocolClaims: true,
loadUserInfo: true
};
and my identity server config:
{
"Enabled": true,
"ClientId": "js.dev",
"ClientName": "Javascript Client",
"ClientSecrets": [ { "Value": "K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols=" } ],
"AllowedGrantTypes": [ "implicit", "authorization_code" ],
"AllowedScopes": [ "openid", "email", "profile", "role", "offline_access" ],
"AllowOfflineAccess": true,
"AllowAccessTokensViaBrowser":true,
"RedirectUris": [
"http://localhost:8081/callback",
"http://localhost:8081/silent_renew.html"
],
"PostLogoutRedirectUris": [
"http://localhost:8081"
],
"AccessTokenLifetime": 900,
"RequireConsent": false
}
I noticed that prior to error last valid response had one cookie response(idsrv.session) with empty value with the expiry date set to the previous year:
I believe this to be the root cause of the issue, I searched it on related Github repo and tried to add the Cookie.SameSite to none but it didn't help:
services.AddAuthentication()
.AddSaml(Configuration,externalProviders.UseSaml)
.AddCookie(options => {
options.SlidingExpiration = true;
options.ExpireTimeSpan = TimeSpan.FromDays(30);
options.Cookie.SameSite = SameSiteMode.None;
});
Any idea!
This is likely due to your IDP session expiring - if you call the authorize endpoint with prompt=none but it's unable to satisfy that request because no valid session exists (i.e. authentication cookie does not exist or has expired) then it will return error=login_required.
If this occurs then the correct course of action is to do an interactive (i.e. prompt=login) sign in request in the top level browser window.
After searching the Identity Server 4 repo, I made the following changes to my code:
services.AddIdentityServer(options=>
{
options.Authentication.CookieLifetime = TimeSpan.FromDays(30);
options.Authentication.CookieSlidingExpiration = true;
})
.AddProfileService<ProfileService>()
.AddSigningCertificate(Configuration)
.AddInMemoryClients(Configuration.GetSection("IdentityServer:Clients"))
.AddInMemoryIdentityResources(Resources.GetIdentityResources());
It started working afterward, but you would have to login again after you close the browser or reopen a new tab I guess it's because of the sessionStorage.
When the session expires the signin-callback is being called by STS having a query parameter called 'error' with the value 'login_required'.
In the signin-callback, before completing sign-in, you can check for this query parameter and if it's found you can sign-out also from your web client.
I had the same issue and tried the proposed above, but for me, it actually was SameSiteMode not set correctly on IdentityServer Cookies. It caused Callback error: ErrorResponse: login_required right after login and after N attempts user was logged out.
This helped me https://github.com/IdentityServer/IdentityServer4/blob/main/src/IdentityServer4/host/Extensions/SameSiteHandlingExtensions.cs
What they do is based on this article https://devblogs.microsoft.com/dotnet/upcoming-samesite-cookie-changes-in-asp-net-and-asp-net-core/
Hope this is useful.
Update.
I had another issue related to this when the user was logged out after re-opening a browser (especially on Android Chrome). login_required error was shown. I noticed that session cookie Expires/Max-Age was set to Session and not some future date. Probably because of that check session iframe (with src={identity server url}/connect/checksession) failed as Identity Server thought there was no session as cookie expired.
I tried setting cookie lifetime via options, but it didn't work as expected for some reason. Lifetime was always 14 days:
services.AddIdentityServer(options=>
options.Authentication.CookieLifetime = TimeSpan.FromDays(30);
options.Authentication.CookieSlidingExpiration = true;
})
Then I tried this and it worked for me:
services.ConfigureApplicationCookie(options => {
options.ExpireTimeSpan = sessionCookieLifetime;
options.SlidingExpiration = true;
})
My js report server with client ui applications was working with username filed by adding one claim e.g. Claim('username', 'user name value') in identityserver.
4 version 1.1. B ut recently client has upgraded the identityserver 4 version to 2.2.0 and netcoreapp2.1 .
Now the client ui applications get "Unauthorized" error. When I run the application locally I see one error in jsreport server console:
error: Authorization server has no "username" field in its response, token assumed as invalid.
I have tried to find solution in the sample:
https://github.com/bjrmatos/jsreport-with-authorization-server-sample but they have not upgraded the sample for latest .net core and identity server yet, I see the node js sample link "https://github.com/IdentityServer/IdentityServer4.Samples/tree/release/NodeJsApi" does not exists. so I am unable to solve the issue. Can anyone help me please on this?
Thanks in advance.
I have found solution to solve this error by adding a claim type with user name and declare that in api resource scope:
new ApiResource
{
Name="jsreportscope",
DisplayName = "JavaScript based reporting platform",
Scopes=
{
new Scope()
{
Name="jsreportscope",
UserClaims = new List<string>(){"username" }
}
},
UserClaims = new List<string>(){"username"},
ApiSecrets = { new Secret("yoursecret".Sha256()) },
}
But now it goes to the previous problem that I fixed by adding a claim type matching the value of username field value with identity server 1.1 version but now we have upgraded the identity server version to 2.1 and again getting the error. The it was able to authorize any user of identity server for report access. Here is the jsreport.config.js code I am using:
{
"store": { "provider": "fs" },
"httpPort": 5004,
"allowLocalFilesAccess": true,
"extensions": {
"authentication": {
"cookieSession": {
"secret": "<your strong secret>"
},
"admin": {
"username": "IdentityServer4User#domain.com",
"password": "Password"
},
"authorizationServer": {
"tokenValidation": {
"endpoint": "http://localhost:5000/connect/introspect",
"usernameField": "username",
"activeField": "active",
"scope": {
"valid": ["jsreportscope"]
},
"auth": {
"type": "basic",
"basic": {
"clientId": "jsreport",
"clientSecret": "yoursecret"
}
}
}
},
"enabled": true
},
"authorization": {
"enabled": true
},
"sample-template": {
"createSamples": true
}
}
}
But now I can login and access reports from report server if login by only the user IdentityServer4User#domain.com any other users is getting unauthorized error. In the report server console the error is shown like:
error: username "OtherIdentityServer4User#domain.com" returned from authorization server is not a jsreport user. I don not want to add all the identity server users to js report server.