Skip to content
This repository has been archived by the owner on Jul 31, 2024. It is now read-only.

Scope behaviour is inconsistent between flows #5400

Closed
AlexKubiesa opened this issue Dec 8, 2021 · 1 comment
Closed

Scope behaviour is inconsistent between flows #5400

AlexKubiesa opened this issue Dec 8, 2021 · 1 comment

Comments

@AlexKubiesa
Copy link

AlexKubiesa commented Dec 8, 2021

The behaviour of the scope parameter is different between the different types of flow:

  • In the Auth Code flow, if the scope parameter is missing or empty, I get an "invalid scope" error.
  • In the Resource Owner Password flow and in extension grant flows, if the scope parameter is missing or empty, the access token contains all allowed scopes.

I have tried to make the token request fail when no scopes are requested reduce the list of returned scopes to only the ones requested by injecting a custom scope parser, a custom resource validator, and a custom token request validator, but on entry to the relevant methods, it looks like all the scopes have been requested even though they haven't.

When the scope parameter is missing or empty, I think the request should fail - or at least it shouldn't contain the offline_access scope because that causes refresh tokens to be unnecessarily put in the persisted grant store and not deleted.

Relevant parts of the log file

Here is part of the console log when I go through the Resource Owner Password flow with a missing scope parameter.

[12:57:41 Debug] IdentityServer4.Endpoints.TokenEndpoint
Start token request.

[12:57:41 Debug] IdentityServer4.Validation.ClientSecretValidator
Start client validation

[12:57:41 Debug] IdentityServer4.Validation.BasicAuthenticationSecretParser
Start parsing Basic Authentication secret

[12:57:41 Debug] IdentityServer4.Validation.ISecretsListParser
Parser found secret: BasicAuthenticationSecretParser

[12:57:41 Debug] IdentityServer4.Validation.ISecretsListParser
Secret id found: 0753c2cd-acb7-42d8-b3d7-8aec31b6efab

[12:57:43 Debug] IdentityServer4.Stores.ValidatingClientStore
client configuration validation for client 0753c2cd-acb7-42d8-b3d7-8aec31b6efab succeeded.

[12:57:43 Debug] IdentityServer4.Validation.ISecretsListValidator
Secret validator success: HashedSharedSecretValidator

[12:57:43 Debug] IdentityServer4.Validation.ClientSecretValidator
Client validation success

[12:57:43 Debug] IdentityServer4.Validation.TokenRequestValidator
Start token request validation

[12:57:43 Debug] IdentityServer4.Validation.TokenRequestValidator
Start resource owner password token request validation

[12:57:44 Debug] IdentityServer4.Test.TestUserProfileService
IsActive called from: ResourceOwnerValidation

[12:57:44 Debug] IdentityServer4.Validation.TokenRequestValidator
Resource owner password token request validation success.

[12:57:44 Information] IdentityServer4.Validation.TokenRequestValidator
Token request validation success, {"ClientId": "0753c2cd-acb7-42d8-b3d7-8aec31b6efab", "ClientName": null, "GrantType": "password", "Scopes": "design.domain email offline_access openid profile supply.domain user.access user.details", "AuthorizationCode": "********", "RefreshToken": "********", "UserName": "alex.kubiesa@altium.com", "AuthenticationContextReferenceClasses": null, "Tenant": null, "IdP": null, "Raw": {"grant_type": "password", "username": "alex.kubiesa@altium.com", "password": "***REDACTED***"}, "$type": "TokenRequestValidationLog"}

[12:57:44 Debug] IdentityServer4.Services.DefaultClaimsService
Getting claims for access token for client: 0753c2cd-acb7-42d8-b3d7-8aec31b6efab

[12:57:44 Debug] IdentityServer4.Services.DefaultClaimsService
Getting claims for access token for subject: 39A6A139-7E20-4F79-89F9-B868FB8AB65F

[12:57:44 Debug] IdentityServer4.Test.TestUserProfileService
Get profile called for subject 39A6A139-7E20-4F79-89F9-B868FB8AB65F from client 0753c2cd-acb7-42d8-b3d7-8aec31b6efab with claim types [] via ClaimsProviderAccessToken

[12:57:44 Debug] IdentityServer4.Test.TestUserProfileService
Issued claims: []

[12:57:44 Debug] IdentityServer4.Services.DefaultRefreshTokenService
Creating refresh token

[12:57:44 Debug] IdentityServer4.Services.DefaultRefreshTokenService
Setting an absolute lifetime: 2145872736

[12:57:44 Debug] IdentityServer4.EntityFramework.Stores.PersistedGrantStore
lXxUPqjAVenaqWaOhMWPv6PL83xJbEj+Kbs6RHrs/OA= not found in database

[12:57:44 Debug] IdentityServer4.Endpoints.TokenEndpoint
Token request success.
@AlexKubiesa AlexKubiesa changed the title Scope header behaviour is inconsistent between flows Scope behaviour is inconsistent between flows Dec 8, 2021
@leastprivilege
Copy link
Member

Important update

This organization is not maintained anymore besides critical security bugfixes (if feasible). This organization will be archived when .NET Core 3.1 end of support is reached (3rd Dec 2022). All new development is happening in the new Duende Software organization.

The new Duende IdentityServer comes with a commercial license but is free for dev/testing/personal projects and companies or individuals making less than 1M USD gross annnual revenue. Please get in touch with us if you have any question.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants