Unable to redeem refresh_token

[andoks]

I'm using oauth2-proxy together with rauthy to self-host, but I have issues redeeming refresh_tokens, as I get an error: {"error": "Unauthorized"}, with now apparent further explanation in the logs.

I use Rauthy ghcr.io/sebadob/rauthy:0.26.2-lite (I am unable to upgrade as of yet), and to try to make a more minimal reproduction, I was able to trigger the same behaviour easily using oauth2c.

Is there anything I may have missed with regards to refresh_tokens that may be the reason why I am not able to redeem them? Is there a rate-limit? or dont-use-before or maybe I'm doing something obviously wrong? I can make a more automated minimal reprodution if needs be, just wanted to get the question out before in case it is something obvious I have missed.

# scripts and commands needs oauth2c and jq installed
# run ghcr.io/sebadob/rauthy:0.26.2-lite locally
# set up client as screenshots below show
# update the client-secret in the scripts below
# then execute these two scripts in succession
./start_session.bash > tokens.json
./refresh_session.bash $(cat tokens.json | jq -r '.refresh_token')

start_session.bash

oauth2c \
    --client-id test \
    --client-secret '7mLGUT2bfyA0Gln0b22j9dEks60WBEXnjyalFVxQ4zXMTmkQNET7bTFNzwNdasDk' \
    --insecure \
    --pkce \
    --scopes "openid profile email offline_access" \
    --response-types code \
    --response-mode query \
    --grant-type authorization_code \
    --auth-method client_secret_post \
    https://localhost/auth/v1

refresh_session.bash

oauth2c \
    --client-id test \
    --client-secret '7mLGUT2bfyA0Gln0b22j9dEks60WBEXnjyalFVxQ4zXMTmkQNET7bTFNzwNdasDk' \
    --insecure \
    --pkce \
    --scopes "openid profile email offline_access" \
    --response-types code \
    --response-mode query \
    --grant-type refresh_token \
    --auth-method client_secret_post \
    --refresh-token $1 \
    https://localhost/auth/v1

This is my client setup

[sebadob]

How exactly are you trying to redeem it, with which kind of request?

Rauthy is super strict about refresh tokens. No matter what the outcome of the request is, if it turns out to be a successfuly request or a malformed request, you can only use any refresh token once, then it's gone. Even further, when you use a refresh token for an existing session either before its validity, after it has expired, or in combination with any malformed request, not only the token itself will be deleted, but also the whole session with all linked tokens will be invalidated as well, just in case a token leaked somehow on a client.

[andoks]

I redeem it like I described in the post, calling the scripts in with ~10 seconds in between (meaning the refresh token might only be 10 seconds old). Is there a minimum time I must wait for it to be redeemable perhaps?

Or do you mean how oauth2-proxy redeems it? I was hoping I have triggered the same sad-path using the setup above in the post as oauth2-proxy triggers, but there is of course a chance for that not to be the case.

[sebadob]

Is there a minimum time I must wait for it to be redeemable perhaps?

Yes. The refresh token comes with an nbf claim and it will only become valid 60 seconds before the current access token expires. If you use it before it's valid, Rauthy considers this an invalid usage and will delete everything that is somehow linked to this token + all other sessions and all other refresh tokens.

The reason that there is an nbf is to prevent simple refresh token spam whenever a client needs to do something, which is in the end just a very bad and lazy implementation, because the access token will still be valid at that point.

Edit:

If you reduce the access token lifetime for your test to 60 seconds, it should work right away.

[andoks]

Damn, yeah. That is probably my issue. Is there a way to relax this behaviour somehow? I thought the refresh_token was opaque to the client, and unfortunately oauth2-proxy does not support inspecting the lifetime of access/id tokens.

Regardless, I am pretty sure this is my problem, thanks for the info!

EDIT: Yup, that was the problem, thanks!!

[sebadob]

Is there a way to relax this behaviour somehow?

Not yet, because is was never needed. It would be very simple to make this modifyable though, it's only a single line of code:

rauthy/src/service/src/token_set.rs

Line 385 in 85ad095

let nbf = Utc::now().add(chrono::Duration::seconds(access_token_lifetime - 60));

I thought the refresh_token was opaque to the client

It can be considered as opaque, but when oauth2-proxy is trying to refresh when it still has a valid access token, its probably worth an issue there, because it should inspect and respect at least the exp of the access token and why should you refresh all the time and waste ressources and time when it's completely unnecessary.

Another solution then would be, if it refreshes all the time anyway, to keep the access token lifetime low enough that it does not produce issues, or increase the session lifetime on Rauthy and don't issue refresh tokens. Then it would redirect you each time but with a still valid session will get an new token set without user interaction.

[sebadob]

Btw, you only get the very opaque unauthorized error to not leak any information to possible attackers.

[andoks]

Is there a way to relax this behaviour somehow?

Not yet, because is was never needed. It would be very simple to make this modifyable though, it's only a single line of code:

rauthy/src/service/src/token_set.rs

Line 385 in 85ad095

let nbf = Utc::now().add(chrono::Duration::seconds(access_token_lifetime - 60));

Ok. Just knowing about the NBF helps immensely =)

I thought the refresh_token was opaque to the client

It can be considered as opaque, but when oauth2-proxy is trying to refresh when it still has a valid access token, its probably worth an issue there, because it should inspect and respect at least the exp of the access token and why should you refresh all the time and waste resources and time when it's completely unnecessary.

I agree, and this has and is being discussed over in that project (e.g oauth2-proxy/oauth2-proxy#1836), but AFAIK there is not yet consensus on how to do this, and no one have yet provided an acceptable PR. Also there is other code-base-spanning work in progress in the project that makes it very inconvenient ATM (refactoring of configuration).

Another solution then would be, if it refreshes all the time anyway, to keep the access token lifetime low enough that it does not produce issues, or increase the session lifetime on Rauthy and don't issue refresh tokens. Then it would redirect you each time but with a still valid session will get an new token set without user interaction.

Yeah, the first one sounds very palatable in my case, since the amount of users is expected to be very low.

BTW, you only get the very opaque unauthorized error to not leak any information to possible attackers.

Yeah, that was what I thought.

In case you are interested in some ideas of how to make this easier to debug:

• Maybe the error could be more detailed for clients using both ID and secret (confidential clients)
• Maybe the debug log could show invalidation of sessions together with the reason when in debug or higher verbosity
• Maybe document the refresh token NBF in the rauthy docs and example configuration

Thanks for the assistance! I'll close this issue since I am indeed able to redeem the refresh token =D

[sebadob]

Oh don't close yet, I was about to add an option to solve your issue. ^^
Will come anyway.

[andoks]

Ok! Feel free to close it when you feel like it. I unfortunately can't assist with testing the feature for a while though, since I am kind of stuck on the release before the bump of the OpenAPI spec version for a while ^_^"

[sebadob]

There is already additional logging in such an error case, but it's in either debug or trace level, not sure about it. I can bump this up a little bit and at least lot some information without leaking secrets to help debugging.

[sebadob]

I am kind of stuck on the release before the bump of the OpenAPI spec version for a while ^_^"

Yeah, sorry about that. I just didn't realize there were breaking changes.

The good news is, you can opt-out of the nbf claim in the future and each error on the /token endpoint will be logged for better debugging and auditing. The only one that slips through currently is the device_code flow because it's taking another route, but I will fix that in the future as well.