duendesoftware / identityserver Goto Github PK

check if artwork repo has something appropriate...

e.g. to call HttpContext.GetIdentityServerIssuerUri

IdentityServer/IdentityServer4#3943

• enabling data protection

As I’m already using EF, I’ve decide to go down that route for the keystore, but I’m getting dependency injection issues.

Our implementation is pretty complex (we extend your EF interfaces and DbContexts with our own in order to add additional functionality), the error I am seeing is lots of the following (for various ServiceTypes and ImplementationTypes, but always while attempting to activate Duende.IdentityServer.EntityFramework.Stores.SigningKeyStore

Error while validating the service descriptor ' ServiceType: Microsoft.AspNetCore.Authentication.IAuthenticationService Lifetime: Transient ImplementationType: Duende.IdentityServer.Hosting.IdentityServerAuthenticationService ': Unable to resolve service for type 'Duende.IdentityServer.EntityFramework.DbContexts.PersistedGrantDbContext' while attempting to activate 'Duende.IdentityServer.EntityFramework.Stores.SigningKeyStore'.

I believe that the issue is due to the fact that the constructor for the SigningKeyStore is expecting a concrete type of PersistedGrantDbContext, rather than the Interface type IPersistedGrantDbContext in https://github.com/DuendeSoftware/IdentityServer/blob/main/src/EntityFramework.Storage/Stores/SigningKeyStore.cs lines 29 and 42

I may be completely wrong here, but this is the most obvious thing I can see that would break it in a scenario where you aren’t simply using the ‘out of the box’ dbContexts

• support license key validation
• must support flags for license features (e.g. number of clients/issuers, key management)
• consider how that affects our options (e.g. we enable key mgmt by default, but license does not allow)

Which version of Duende IdentityServer are you using?

5.0.3

Which version of .NET are you using?

.NET 5

Describe the bug

I'm playing around with trying to figure out how to best augment the default DbContexts to add custom functionality. Was planning on having a migrations specific DbContext that encapsulates the default DbContext configurations and adds new entities for our needs in a third DbContext. I don't know if we will go this route but I did uncover a variation in table naming for the "Keys" table. Since its name is not explicitly configured like all the other entities, our migration context ends up naming it "Key" vs. "Keys" unless I include an explicit DbSet named "Keys" in the migration DbContext.

See: Line #175 in ModelBuilderExtensions.cs

To Reproduce

public sealed class MigrationsDataContext : DbContext {

        public MigrationsDataContext(DbContextOptions<MigrationsDataContext> options, ConfigurationStoreOptions configurationStoreOptions, OperationalStoreOptions operationalStoreOptions)
            : base(options) {
            this.ConfigurationStoreOptions = configurationStoreOptions ?? throw new ArgumentNullException(nameof(configurationStoreOptions));
            this.OperationalStoreOptions = operationalStoreOptions ?? throw new ArgumentNullException(nameof(operationalStoreOptions));
        }

        private ConfigurationStoreOptions ConfigurationStoreOptions { get; }

        private OperationalStoreOptions OperationalStoreOptions { get; }

        protected override void OnModelCreating(ModelBuilder modelBuilder) {
            modelBuilder.ConfigureClientContext(this.ConfigurationStoreOptions);
            modelBuilder.ConfigureResourcesContext(this.ConfigurationStoreOptions);
            modelBuilder.ConfigurePersistedGrantContext(this.OperationalStoreOptions);

            base.OnModelCreating(modelBuilder);
        }
    }

Expected behavior

I expect the migration to generate a table named "Keys" instead "Key".

Log output/exception with stacktrace

Unhandled exception: Invalid object name 'Keys'.
Microsoft.Data.SqlClient.SqlException (0x80131904): Invalid object name 'Keys'.
at Microsoft.Data.SqlClient.SqlCommand.<>c.b__169_0(Task1 result) at System.Threading.Tasks.ContinuationResultTaskFromResultTask2.InnerInvoke()
at System.Threading.Tasks.Task.<>c.<.cctor>b__277_0(Object obj)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location ---
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread)
--- End of stack trace from previous location ---
at Microsoft.EntityFrameworkCore.Storage.RelationalCommand.ExecuteReaderAsync(RelationalCommandParameterObject parameterObject, CancellationToken cancellationToken)
at Microsoft.EntityFrameworkCore.Storage.RelationalCommand.ExecuteReaderAsync(RelationalCommandParameterObject parameterObject, CancellationToken cancellationToken)
at Microsoft.EntityFrameworkCore.Query.Internal.SingleQueryingEnumerable1.AsyncEnumerator.InitializeReaderAsync(DbContext _, Boolean result, CancellationToken cancellationToken) at Microsoft.EntityFrameworkCore.SqlServer.Storage.Internal.SqlServerExecutionStrategy.ExecuteAsync[TState,TResult](TState state, Func4 operation, Func4 verifySucceeded, CancellationToken cancellationToken) at Microsoft.EntityFrameworkCore.Query.Internal.SingleQueryingEnumerable1.AsyncEnumerator.MoveNextAsync()
at Microsoft.EntityFrameworkCore.EntityFrameworkQueryableExtensions.ToListAsync[TSource](IQueryable1 source, CancellationToken cancellationToken) at Microsoft.EntityFrameworkCore.EntityFrameworkQueryableExtensions.ToListAsync[TSource](IQueryable1 source, CancellationToken cancellationToken)
at Microsoft.EntityFrameworkCore.EntityFrameworkQueryableExtensions.ToArrayAsync[TSource](IQueryable`1 source, CancellationToken cancellationToken)
at Duende.IdentityServer.EntityFramework.Stores.SigningKeyStore.LoadKeysAsync() in //src/EntityFramework.Storage/Stores/SigningKeyStore.cs:line 54
at Duende.IdentityServer.Services.KeyManagement.KeyManager.GetKeysFromStoreAsync(Boolean cache) in //src/IdentityServer/Services/Default/KeyManagement/KeyManager.cs:line 422
at Duende.IdentityServer.Services.KeyManagement.KeyManager.GetAllKeysInternalAsync() in //src/IdentityServer/Services/Default/KeyManagement/KeyManager.cs:line 106
at Duende.IdentityServer.Services.KeyManagement.KeyManager.GetAllKeysAsync() in //src/IdentityServer/Services/Default/KeyManagement/KeyManager.cs:line 93
at Duende.IdentityServer.Services.KeyManagement.AutomaticKeyManagerKeyStore.GetValidationKeysAsync() in //src/IdentityServer/Services/Default/KeyManagement/AutomaticKeyManagerKeyStore.cs:line 105
at Duende.IdentityServer.Services.DefaultKeyMaterialService.GetValidationKeysAsync() in //src/IdentityServer/Services/Default/DefaultKeyMaterialService.cs:line 106
at Duende.IdentityServer.ResponseHandling.DiscoveryResponseGenerator.CreateDiscoveryDocumentAsync(String baseUrl, String issuerUri) in //src/IdentityServer/ResponseHandling/Default/DiscoveryResponseGenerator.cs:line 105
at Duende.IdentityServer.Endpoints.DiscoveryEndpoint.ProcessAsync(HttpContext context) in //src/IdentityServer/Endpoints/DiscoveryEndpoint.cs:line 61
at Duende.IdentityServer.Hosting.IdentityServerMiddleware.Invoke(HttpContext context, IEndpointRouter router, IUserSession session, IEventService events, IIssuerNameService issuerNameService, IBackChannelLogoutService backChannelLogoutService) in /_/src/IdentityServer/Hosting/IdentityServerMiddleware.cs:line 84

Additional context

I realize that this is probably not the best way to proceed but it did uncover an inconsistency in the DbContext configuration as it relates to the "Keys" table.

• add edition to summary
• always emit parsed License (even if invalid)
• key mgmt license error: give info on disabling

Which exact version are you using?
5.0.0-preview.2.13

Describe the bug
I am using IDS4 as an OAuth2 token service where I am doing exchanges of external id_tokens (google) for access_tokens, etc.
No id_tokens being produced by IDS4.

I am doing devicecode update where my id_token is from google.

I make a ClaimsPrincipal our of that id_token and it doesn't contain JwtClaimTypes.AuthenticationTime or JwtClaimTypes.IdentityProvider.

deviceAuth.Subject = googlePrincipal;
await _deviceFlowStore.UpdateByUserCodeAsync(data.UserCode, deviceAuth);

Later in the flow a call is made to the token endpoint with the grant_type:urn:ietf:params:oauth:grant-type:device_code.
Which eventually hits the GetStandardSubjectClaims method, which throws because there is no JwtClaimTypes.AuthenticationTime.

protected virtual IEnumerable<Claim> GetStandardSubjectClaims(ClaimsPrincipal subject)
{
    var claims = new List<Claim>
    {
        new Claim(JwtClaimTypes.Subject, subject.GetSubjectId()),
        new Claim(JwtClaimTypes.AuthenticationTime, subject.GetAuthenticationTimeEpoch().ToString(), ClaimValueTypes.Integer64),
        new Claim(JwtClaimTypes.IdentityProvider, subject.GetIdentityProvider())
    };

    claims.AddRange(subject.GetAuthenticationMethods());

    return claims;
}

I can create a ClaimsPincipal with it in there by copying it from google's id_token iat, however before doing that I need to know if this is a defect on google's side by not having it or IDS4 assuming that its there because of how IDS4 creates id_tokens.

Is this on me to make sure those 2 claims are in there or something IDS4 accounts for NOT being in there?

System.InvalidOperationException: auth_time is missing.
   at Duende.IdentityServer.Extensions.PrincipalExtensions.GetAuthenticationTimeEpoch(IIdentity identity) in C:\work\github\DuendeSoftware-FluffyBunny\TokenServices\src\Duende\Main\IdentityServer\Extensions\PrincipalExtensions.cs:line 52
   at Duende.IdentityServer.Extensions.PrincipalExtensions.GetAuthenticationTimeEpoch(IPrincipal principal) in C:\work\github\DuendeSoftware-FluffyBunny\TokenServices\src\Duende\Main\IdentityServer\Extensions\PrincipalExtensions.cs:line 38
   at Duende.IdentityServer.Services.DefaultClaimsService.GetStandardSubjectClaims(ClaimsPrincipal subject) in C:\work\github\DuendeSoftware-FluffyBunny\TokenServices\src\Duende\Main\IdentityServer\Services\Default\DefaultClaimsService.cs:line 226
   at Duende.IdentityServer.Services.DefaultClaimsService.GetAccessTokenClaimsAsync(ClaimsPrincipal subject, ResourceValidationResult resourceResult, ValidatedRequest request) in C:\work\github\DuendeSoftware-FluffyBunny\TokenServices\src\Duende\Main\IdentityServer\Services\Default\DefaultClaimsService.cs:line 165
   at FluffyBunny4.Services.MyDefaultClaimsService.GetAccessTokenClaimsAsync(ClaimsPrincipal subject, ResourceValidationResult resourceResult, ValidatedRequest request) in C:\work\github\DuendeSoftware-FluffyBunny\TokenServices\src\Apps\FluffyBunny4\Services\Default\MyDefaultClaimsService.cs:line 42
   at Duende.IdentityServer.Services.DefaultTokenService.CreateAccessTokenAsync(TokenCreationRequest request) in C:\work\github\DuendeSoftware-FluffyBunny\TokenServices\src\Duende\Main\IdentityServer\Services\Default\DefaultTokenService.cs:line 187
   at FluffyBunny4.Stores.MyTokenResponseGenerator.CreateAccessTokenAsync(ValidatedTokenRequest request) in C:\work\github\DuendeSoftware-FluffyBunny\TokenServices\src\Apps\FluffyBunny4\Stores\MyTokenResponseGenerator.cs:line 115
   at Duende.IdentityServer.ResponseHandling.TokenResponseGenerator.ProcessDeviceCodeRequestAsync(TokenRequestValidationResult request) in C:\work\github\DuendeSoftware-FluffyBunny\TokenServices\src\Duende\Main\IdentityServer\ResponseHandling\Default\TokenResponseGenerator.cs:line 261
   at Duende.IdentityServer.ResponseHandling.TokenResponseGenerator.ProcessAsync(TokenRequestValidationResult request) in C:\work\github\DuendeSoftware-FluffyBunny\TokenServices\src\Duende\Main\IdentityServer\ResponseHandling\Default\TokenResponseGenerator.cs:line 99
   at Duende.IdentityServer.Endpoints.TokenEndpoint.ProcessTokenRequestAsync(HttpContext context) in C:\work\github\DuendeSoftware-FluffyBunny\TokenServices\src\Duende\Main\IdentityServer\Endpoints\TokenEndpoint.cs:line 98
   at Duende.IdentityServer.Endpoints.TokenEndpoint.ProcessAsync(HttpContext context) in C:\work\github\DuendeSoftware-FluffyBunny\TokenServices\src\Duende\Main\IdentityServer\Endpoints\TokenEndpoint.cs:line 70
   at Duende.IdentityServer.Hosting.IdentityServerMiddleware.Invoke(HttpContext context, IEndpointRouter router, IUserSession session, IEventService events, IBackChannelLogoutService backChannelLogoutService) in C:\work\github\DuendeSoftware-FluffyBunny\TokenServices\src\Duende\Main\IdentityServer\Hosting\IdentityServerMiddleware.cs:line 74
   at Duende.IdentityServer.Hosting.IdentityServerMiddleware.Invoke(HttpContext context, IEndpointRouter router, IUserSession session, IEventService events, IBackChannelLogoutService backChannelLogoutService) in C:\work\github\DuendeSoftware-FluffyBunny\TokenServices\src\Duende\Main\IdentityServer\Hosting\IdentityServerMiddleware.cs:line 89
   at Duende.IdentityServer.Hosting.MutualTlsEndpointMiddleware.Invoke(HttpContext context, IAuthenticationSchemeProvider schemes) in C:\work\github\DuendeSoftware-FluffyBunny\TokenServices\src\Duende\Main\IdentityServer\Hosting\MutualTlsEndpointMiddleware.cs:line 94
   at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
   at Duende.IdentityServer.Hosting.BaseUrlMiddleware.Invoke(HttpContext context) in C:\work\github\DuendeSoftware-FluffyBunny\TokenServices\src\Duende\Main\IdentityServer\Hosting\BaseUrlMiddleware.cs:line 31
   at FluffyBunny4.Middleware.TenantMiddleware.Invoke(HttpContext context, IScopedTenantRequestContext scopedTenantRequestContext, ITenantStore tenantStore) in C:\work\github\DuendeSoftware-FluffyBunny\TokenServices\src\Apps\FluffyBunny4\Middleware\TenantMiddleware.cs:line 71
   at Swashbuckle.AspNetCore.SwaggerUI.SwaggerUIMiddleware.Invoke(HttpContext httpContext)
   at Swashbuckle.AspNetCore.Swagger.SwaggerMiddleware.Invoke(HttpContext httpContext, ISwaggerProvider swaggerProvider)
   at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)

IdentityServer/IdentityServer4#3518

IdentityServer/IdentityServer4#4971

IdentityServer/IdentityServer4#3571

IdentityServer/IdentityServer4#2215

Hi,

It's not a bug report really, but there was a contribution section on IdentityServer4 that used to guide us on naming of third party packages, it's gone from Duende Identity Server docs.

Wandering what is the guidance here ? given I tried to upload a library for DynamoDB operational store on Nuget, but the last complained with:

This package ID has been reserved. Please request access to upload to this reserved namespace from the owner of the reserved prefix, or re-upload the package with a different ID.

• IdentityServer version
• .NET Version

Keep sid and client list in the default user session when it's the same sub.

IdentityServer/IdentityServer4#4920

URL:

https://duendesoftware-test.azurewebsites.net/connect/endsession?id_token_hint=eyJhbGciOiJSUzI1NiIsImtpZCI6IjFBMTYzRTQzQzI0QUFEQUIyQzM2Q0JGNzMyNzM3ODQxIiwidHlwIjoiSldUIn0.eyJpc3MiOiJodHRwczovL2R1ZW5kZXNvZnR3YXJlLXRlc3QuYXp1cmV3ZWJzaXRlcy5uZXQiLCJuYmYiOjE2MTIyNzUwMzksImlhdCI6MTYxMjI3NTAzOSwiZXhwIjoxNjEyMjc1MzM5LCJhdWQiOiJiYXNpYyIsImFtciI6WyJwd2QiXSwibm9uY2UiOiJRT2JxeWxON3ZRIiwiYXRfaGFzaCI6ImFwNTU3WXI4Rm4wMTlfRFBjNDFqaWciLCJzaWQiOiJDNzIxQTkxQzgxODYxMzU4OTFFNzc4MEM3OEY5QzVDNCIsInN1YiI6Ijg4NDIxMTEzIiwiYXV0aF90aW1lIjoxNjEyMjc1MDM4LCJpZHAiOiJsb2NhbCJ9.u93oVNLSzCR7tRj5kMdnuGUkQ4ckkAXwSlkxcdYyLFlKiqlnqFaEaUG85Bn06HqSLClcL92P7lbwvTzsBa7LEY9APjVdzlbgzqVbi7wmCwGG_G_eEf-3yM1JqtWE_h60S3_-eKtesubPdBfrLsKGMp70-FWBb5wcCUqb8XNhGHrmcojNuJqy-D4VO7OQO2CtcWZjHx3gvSyeP4MsHF87td0zE-DCW8NdoNHXGQOkzgkuRYERoSOCGadO2nLudvrScnmlKxm4iVqyvvogbnTj5FFct9kXYvWbl_dkwIwihEKr8Ykg5R2sKF6F6Fg6_451b_khedVIEZAxGUz7Vu2PoA&post_logout_redirect_uri=https://www.certification.openid.net/test/a/duende_oidc/post_logout_redirect&state=iOaurmcsIxbEylCxbSNbuoXttGmiFGKvsprSEGbteHcgKDBlfX4031238060'~/@~,,%23%3E%22%3D,-%3D%7C_%3E%3D%5C%26%5E.%7B~%5D);,;?

actual
iOaurmcsIxbEylCxbSNbuoXttGmiFGKvsprSEGbteHcgKDBlfX4031238060'~/@~,,#>"=,-=|_>=\&^.{~])
expected
iOaurmcsIxbEylCxbSNbuoXttGmiFGKvsprSEGbteHcgKDBlfX4031238060'~/@~,,#>"=,-=|_>=\&^.{~]);,;?

or

actual
OZCbBvUDAHfKgqBkMmpqWxaQlNKfutbyGEpSnoefWtPItvOUwS8539424422':~%.
expected
OZCbBvUDAHfKgqBkMmpqWxaQlNKfutbyGEpSnoefWtPItvOUwS8539424422':~%.;~.*]'$^,"`>~*`^^;$=</^&#

https://duendesoftware-test.azurewebsites.net/connect/authorize?client_id=hybrid&redirect_uri=https://www.certification.openid.net/test/a/duende_oidc/callback&scope=openid&state=mBKXOvnGL3&response_type=code%20token&response_mode=form_post

expected: should work
actual: nonce required

Which exact version are you using?
5.0.0-preview.2

Describe the bug

DefaultTokenService.cs

            // todo: cleanup
            // add iat claim
            //claims.Add(new Claim(JwtClaimTypes.IssuedAt, Clock.UtcNow.ToUnixTimeSeconds().ToString(), ClaimValueTypes.Integer64));

Is there plans to uncomment this code and get JwtClaimTypes.IssuedAt back as a claim?

track https://tools.ietf.org/html/draft-ietf-oauth-par-04

    <PackageReference Include="Duende.IdentityServer" Version="5.0.0" />
    <PackageReference Include="Duende.IdentityServer.AspNetIdentity" Version="5.0.0" />
    <PackageReference Include="Duende.IdentityServer.EntityFramework" Version="5.0.0" />

The post-login redirect doesn't work in Edge but works fine in Firefox.

I have an MVC redirecting me to the IdentityServer login page where I can enter the alice/Pass123$ test credentials. In the Firefox browser I am redirected back to the MVC while in the Edge browser I land again and again on the IdentityServer login page to enter my credentials.

If I directly login on the IdentityServer login page (instead of being redirected to it), it works fine. I enter the credentials once and can see the claim.

I have found in the internet many references to this issue in the past years, many related to CSP security, and I tried each of them but none of them solved my problem.

Hi.

I've noticed that ApiScope (model, entity, and database) does not follow the same pattern as ApiResource, IdentityResource, and Client, as it does not include the properties mentioned (Created, Updated, LastAccessed, NonEditable).

Do you plan addind them? Or removing them from the other models?
Or may be add some mechanism to extend the database model with this kind of things (we only use Created and Updated).

Thanks.

• use IIssuerNameService
• look at exact logging messages and log levels

https://www.ietf.org/archive/id/draft-meyerzuselhausen-oauth-iss-auth-resp-01.txt

have a look if we can get rid of it

Which exact version are you using?

5.0.3

Describe the bug

I first noticed that local API calls against my controllers on IdentityServer protected by AddLocalApiAuthentication are slowish. So I reviewed the IdentityServer logs, also turned on EF loggin, and found that each time token validation occurs, it goes through:

10 SQL queries against the client store (due to the way EF queries in ClientStore.cs was written)
Duende.IdentityServer.EntityFramework.Stores.ClientStore
MyClient found in database: True
client configuration validation for client MyClient succeeded.

Repeat 10 SQL queries against the client store
Duende.IdentityServer.EntityFramework.Stores.ClientStore
MyClient found in database: True
client configuration validation for client MyClient succeeded.

Duende.IdentityServer.Validation.TokenValidator
Calling into custom token validator: Duende.IdentityServer.Validation.DefaultCustomTokenValidator
Duende.IdentityServer.Validation.TokenValidator
Token validation success

My first question was why the client validation has to be ran for local API authentication, let alone twice? Is it possible to have IdentityServer simply validate the access token against its own signature (like how a third party RP would do) without making DB calls?

Secondly, why ClientStore.cs was written to execute the 9 extra queries separately instead of using one eager load?

Then I reviewed the log for a normal OIDC Authorization Code flow initiated from my app. This time, I counted a total of 6 x client configuration validation runs (so 60 SQL queries for them).

I can post full log if needed (but they're pretty straight forward as described here).

Is this normal or something could be wrong?

Spec
https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html

FAPI profile
https://openid.net/specs/openid-financial-api-ciba-ID1.html

https://tools.ietf.org/html/rfc7591
https://openid.net/specs/openid-connect-registration-1_0.html

migrated from IdentityServer4

IdentityServer/IdentityServer4#1557

Instead of using the extension method on HttpContext/IHttpContextAccessor. This will enable testing, and perhaps multi-tenancy in future.

While everything is already doable with various extensibility points etc - it would be nice to have this as a 1st class citizen

per tenant

• client and resource config
• discovery endpoint and issuer name
• authentication methods configuration (incl. dynamic loading of authN handlers)
• customization of UI

see

IdentityServer/IdentityServer4#4865

once this is done

https://tools.ietf.org/html/draft-ietf-oauth-jwt-introspection-response-10

IdentityServer/IdentityServer4#4789

https://openid.net/specs/openid-connect-rpinitiated-1_0.html

Which exact version are you using?
5.0.0-preview.2.13

Describe the bug

Currently implementation parsing value object by claimName (claim.Type)
https://github.com/DuendeSoftware/IdentityServer/blob/main/src/IdentityServer/Extensions/TokenExtensions.cs#L132-L155

Today when you define your client in code, the classes get quite long and unmaintainable. Often you have one definition for development and one for production that you need to keep in sync.

to avoid configuration drift, then using the C# 9 record syntax, you could then define them using code like this:

var devclient = new Client()
{
    ClientId = "myclient",
    ClientName = "My Client application",
    RedirectUris =
    {
        "https://localhost:5001/signin-oidc",
    },
    ClientSecrets = new List<Secret> { new Secret { Value = "mydevsecret".Sha512() } },

    PostLogoutRedirectUris =
    {
        "https://localhost:5001/signout-callback-oidc"
    }

    // ...
};

var prodclient = devclient with
{
    ClientSecrets = new List<Secret> { new Secret { Value = "myprodsecret".Sha512() } },
    RedirectUris = new List<string>() { "https://localhost:5001/signin-oidc" },
    PostLogoutRedirectUris = new List<string>() {"https://production.com/signout-callback-oidc" }
};

Using the With syntax, you can now very cleanly override some of the settings with the rest is unchanged.

pretty neat I think 👍

migrated from IdentityServer4

IdentityServer/IdentityServer4#1721

Current proposal - add Isolated flag on ApiResource.

https://tools.ietf.org/html/rfc8707

IdentityServer/IdentityServer4#4859

track
https://tools.ietf.org/wg/oauth/draft-ietf-oauth-rar/

also
oauthstuff/draft-oauth-rar#63

Since code flow is the new standard, id_token comes via back channel

pro

• eliminates one extra round trip to userinfo
• easier state management in profile service

cons

• larger id_token for id_token_hint situations

Used version:

<PackageReference Include="Duende.IdentityServer" Version="5.0.1" />

Configuring a "client credentials" client within the appsettings.json file like the following

...
  "AllowedScopes": [
    "demo_api",
  ],
  "ClientClaimsPrefix": "",
  "Claims": [
    {
      "Type": "role",
      "Value": "some_role"
    }
  ]
...

will end with the client claim prefix "client_" within the role-claim in the token ("client_role": "some_role").

If the goal is to have set the role-claimtype set to "role": "some_role" you will need to explicitly set the value to a whitespace like this:

...
  "AllowedScopes": [
    "demo_api",
  ],
  "ClientClaimsPrefix": " ",
  "Claims": [
    {
      "Type": "role",
      "Value": "some_role"
    }
  ]
...

Then the client claim prefix "client_" within the issued token disappears.

The docs says that when setting the ClientClaimsPrefix-property the set value will have effect.

However, it kind of feels like a bug when configuring a client via the appsettings and using a whitespace. This seems a bit odd and probably some kind like a UseClientClaimsPrefix-property would make more sense when configuring a client in the appsettings.

https://darutk.medium.com/implementers-note-about-jar-fff4cbd158fe

https://github.com/DuendeSoftware/IdentityServer/discussions/102