Skip to content
This repository has been archived by the owner on Dec 13, 2022. It is now read-only.

Refresh token not revoked even though logs say it was #3445

Closed
JarrodJ83 opened this issue Jul 16, 2019 · 5 comments
Closed

Refresh token not revoked even though logs say it was #3445

JarrodJ83 opened this issue Jul 16, 2019 · 5 comments
Labels

Comments

@JarrodJ83
Copy link
Contributor

Issue / Steps to reproduce the problem

If the ClientId of the app trying to revoke the token does not match the ClientId of the token then the token is not revoked. However, the result is true and the logs indicate it was removed. The issue is in TokenRevocationResponseGenerator:

var token = await RefreshTokenStore.GetRefreshTokenAsync(validationResult.Token);

            if (token != null)
            {
                if (token.ClientId == validationResult.Client.ClientId)
                {
                    Logger.LogDebug("Refresh token revoked");
                    await RefreshTokenStore.RemoveRefreshTokenAsync(validationResult.Token);
                    await ReferenceTokenStore.RemoveReferenceTokensAsync(token.SubjectId, token.ClientId);
                }
                else
                {
                    Logger.LogWarning("Client {clientId} tried to revoke a refresh token belonging to a different client: {clientId}", validationResult.Client.ClientId, token.ClientId);
                }

                return true;
            }

            return false;

I'm not sure what the desired behavior is here. If it is to just warn the user but still revoke the token then we should always do the revoke and issue the warning if the clientIds differ. If the desired behavior is to prevent the revocation if the clientIds don't match then we need to return false after issuing the warning.

In my case (and perhaps this is not the right way to do this) I am building an admin app that we will be able to use internally to revoke refresh tokens if necessary. I secure this app with the IdP using client credentials. In this case my clientids will not match but I would want the app to be able to delete refresh tokens of other clients.

I'm happy to fix this if someone can give me direction on which way it should be.

Steps to Reproduce

Try and revoke a token using a different client than the one that issued the token.

Relevant parts of the log file

Warning: Client "Mobile_Code" tried to revoke a refresh token belonging to a different client: "Mobile_Code"
Information: Token successfully revoked
Information: 200 "POST" "/connect/revocation"

@leastprivilege
Copy link
Member

The spec says the result of a revocation request must always be success to prevent token scanning attacks.

@JarrodJ83
Copy link
Contributor Author

Thanks for pointing this out, @leastprivilege . I should have read the spec before posting. After reading it this all makes sense.

That said I don't believe the logs are accurately representing what is happening on the server. Here is what is being logged currently:

Warning: Client "Mobile_Code" tried to revoke a refresh token belonging to a different client: "Mobile_Code"
Information: Token successfully revoked
Information: 200 "POST" "/connect/revocation"

Here is something like I would expect to see:

Warning: Client "Mobile_Code" tried to revoke a refresh token belonging to a different client: "Mobile_Code". Tokens will not be revoked.
Information: Token revocation process succeeded
Information: 200 "POST" "/connect/revocation"

At this point it is clear to those who haven't read all the specs completely that this is desired behavior. What do you think?

Also, in the warning line the same clientId is used in the log template so it doesn't log both clientIds:
Logger.LogWarning("Client {clientId} tried to revoke a refresh token belonging to a different client: {clientId}", validationResult.Client.ClientId, token.ClientId);

results in:

Warning: Client "Mobile_Code" tried to revoke a refresh token belonging to a different client: "Mobile_Code"

This is is just about clarity at this point. Let me know if you'd like me to make the above suggestions. Otherwise feel free to close this issue!

@leastprivilege
Copy link
Member

OK - want to send a PR?

@JarrodJ83
Copy link
Contributor Author

Will do!

@JarrodJ83 JarrodJ83 mentioned this issue Jul 24, 2019
2 tasks
leastprivilege pushed a commit that referenced this issue Jul 24, 2019
* #3445 Modify token revocation logs to more clearly indicate behavior

* #3445 Modify log to log both client id's

* #3445 Test revoke of another client's refresh token should not skipped but still return success

* #3445 Revoking another client's access token should return success but not revoke the token
leastprivilege pushed a commit that referenced this issue Jul 24, 2019
* #3445 Modify token revocation logs to more clearly indicate behavior

* #3445 Modify log to log both client id's

* #3445 Test revoke of another client's refresh token should not skipped but still return success

* #3445 Revoking another client's access token should return success but not revoke the token

(cherry picked from commit 0038e71)
leastprivilege added a commit that referenced this issue Sep 8, 2019
* updated storage

* update version

* Update azure-pipelines.yml for Azure Pipelines

* install right SDK for Linux

* start modifying IdentityServer itself

* compiles on 3

* update to new hosting model

* added endpoint info to request logger

* started working on EF

* remove extra line

* Cherry Pick request object PR

* fix cherry pick

* Set client id in user login events from resource owner password validator (#3442)

(cherry picked from commit 6ef66a1)

* Easier Authorization Code extensibility (#3463)

* separate code creation and storage

* added properties to AuthorizationCode

* updated dictionary

(cherry picked from commit f7362df)

* Easier support for impersonating clients (#3464)

* add new property to ValidatedTokenRequest

* check for impersonation flag in default claims service

* add test

* requested changes

(cherry picked from commit 94ee194)

* 3445 refresh token logs (#3468)

* #3445 Modify token revocation logs to more clearly indicate behavior

* #3445 Modify log to log both client id's

* #3445 Test revoke of another client's refresh token should not skipped but still return success

* #3445 Revoking another client's access token should return success but not revoke the token

(cherry picked from commit 0038e71)

* update to .NET Core Preview 7

* move Storage back to netstandard

* workaround for strongly typed HttpClientFactory problem

* add todo

* temporarily disable tests

* fix artifacts directory

* csproj cleanup

* consolidate strong naming keys

* migrated EF.Storage - tests don't work - skipped for now.

* more fixes for tests required

* updated EF

* update AspId

* install right SDK for CI

* clean up

* ensure SDK version for MinVer is installed (#3490)

* updgrade bullseye

* change middleware order

* CORS validation handling normalized URIs (#3478)

* Added failing tests

* Changed CORS origin check to allow for normalized ports

(cherry picked from commit 80d7a39)

* fix JS for automatic signout redirect (#3491)

* fix JS for automatic signout redirect to wait until iframe is done loading #3475

* revert back to the load event for redirect after signout

(cherry picked from commit 13430dc)

* remove extra out of index msg template that cause exception during logging (#3494)

To resolve #3482

(cherry picked from commit 1a7fb8e)

* Fix/3431 (#3467)

* Protected data members should be properties, not fields (CA1051).

* Using structured logging messages to avoid unnecessary string allocations at runtime.

* Restricting refresh_token's sliding lifetime when creating new refresh_tokens. Adding warning about incorrectly configured clients.

* Adding test.

(cherry picked from commit 3752f76)

* set Json.Net version to 12.0.1

* remove IdentityServerPrincipal

* Update add_apis.rst (#3508)

(cherry picked from commit c719bfc)

* Update request_object.rst (#3509)

(cherry picked from commit 7a50dcc)

* update build scripts

* Add support for additional signing algorithms (#3511)

* allow specifying signing algorithm on all helper methods

* add support for variable length c_hash and at_hash

* add EC

* add StateHash property to authorization code

* add s_hash support

* added test for s_hash for code flow

* cleanup crypto extensions

* consolidate StateHash and StateToHash

* Move to IdentityModel v4

* update tests

* update IdM version

* work on EF tests

* move context accessor access (#3517)

(cherry picked from commit 835f519)

* Set typ header for access tokens (#3513)

* set typ header for access tokens (and enforce in API)

* add jwt type to options

* update token validator to use jwt type

* adjust testrs

* adjust tests

* clean up DefaultCustomTokenValidator

* exclude vs directory from clean script

* update migrations

* skip one more test where ef in-mem provider seems broken

* update connection strings and host for 3.0 style

* update aspnet identity host for 3.0 style

* add docs for jwt access token type setting

* add support for ECDSA keys in disovery

* add helper for ECDSA

* update clients to 3.0

* add Json.Net to host

* sponsors update for july

(cherry picked from commit 3c109dc)

* Update readme.md (#3525)

fix  discription for hybrid authentication

(cherry picked from commit cfd2d5d)

* make EC work by hard-coding crv (for now)

* Update README.md

(cherry picked from commit 56eaba8)

* update to netcore preview8

* Update specs.rst (#3556)

(cherry picked from commit ca5e557)

* Ecdsa curve handling (#3534)

* Handling for crv values

* Added handling for curve mismatch

* Set id_token_signing_alg_values_supported based on signing credential

* Used CryptoHelper.GetCrvValueFromCurve to use constants

* update IdentityModel

* cleanup ECDSA code

* update samples

* Add convenience overloads for setting signing keys

(cherry picked from commit f8a7c51)

* Support specific signing algorithms per validation key (#3561)

* Add convenience overloads for setting signing keys

* add indirection to signing keys to support specific algorithms per key

* added null checks around getting the signing credential + cleanup

* Added test for validation keys with different algorithms (#3532) (#3562)

* changed ClaimValueTypes.Integer to Integer64 (#3563)

* Fix ConsentGrantedEvent xml document (#3540)

(cherry picked from commit 28b971d)

* Update 8_aspnet_identity.rst (#3476)

Remove "the a"

(cherry picked from commit 00fb686)

* move logging before removal so the PromptMode is included in the logging (#3523)

(cherry picked from commit 0c097ee)

* Fixed null reference (#3565)

* cleanup

* cleanup crypto

* update dependency

* update serilog

* add comment for azure diagnostics

* update IdentityModel

* Re-factor logic to turn Secrets into SecurityKeys (#3584)

* added extension method to turn secret collection to SecurityKeys

* changed JwtRequestValidator and PrivateKeyJwtValidator to use new extension method

* update host logging

* add return code for host

* update to netcore preview9

* update samples

* update AzDO

* Fixed Typo (#3595)

dynamical to ydynamically

(cherry picked from commit 86da612)

* Updated tests for EF Core 3 (#3582)

* Removed usage of in-memory database until EF Core 3 is ready

* Made CORS service pull full client record into memory until EF Core 3 is ready

* Added integration tests for token cleanup

* reenable in-mem tests

* added package icon

* re-enabled tests

* move cors service to EF project

* split clean scripts

* moved unit tests

* rework token cleanup service

* add expiration index

* updated migrations

* update automapper

* update source link

* reverted to icon url

* identify the builds for each solution in the logs (#3586)

* key management samples (#3606)

(cherry picked from commit a401ec2)
@lock
Copy link

lock bot commented Jan 11, 2020

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Jan 11, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants