Assert that array-key exists on decoded refresh token.

[mrtus]

When users are using the RefreshTokenGrant they seem to be using the AuthCodeGrant its token value as refresh_token value.
Which is of course incorrect, but the framework does not handle this scenario correctly.

Since both tokens use the same encryption key, the decryption simply happens without any error.
However, when the token is json decoded the array is missing an array-key refresh_token_id.

This causes if ($this->refreshTokenRepository->isRefreshTokenRevoked($refreshTokenData['refresh_token_id']) === true) { to throw a TypeError because a null argument is given to a string $tokenId method signature.

Suggestion
Validate that all array-keys exist before using them, otherwise throw a throw OAuthServerException::invalidRequest('refresh_token') exception

[Sephster]

Do you have any insight into how widespread this is or why people are passing non-refresh tokens to this function? I've not heard of folks doing this before. This does feel more like an implementation issue that could be sorted by users without us having to put in guard rails but if there is something indicating this issue is widespread, we can certainly take a look. Thank you

[mrtus]

Do you have any insight into how widespread this is or why people are passing non-refresh tokens to this function? I've not heard of folks doing this before. This does feel more like an implementation issue that could be sorted by users without us having to put in guard rails but if there is something indicating this issue is widespread, we can certainly take a look. Thank you

Thank you for chipping in here @Sephster

Hard to say really about the frequency, we threw in a custom implementation with the guard to avoid getting errors all the time. But before that it was at least one user a day trying multiple times.
Not a lot of our users / integrators are very savy with OAuth, so that doesn't really help either.

In my opinion, there is a validation / design issue here in the framework, either the validation must be there, or the auth-code must not be encrypted with the same encryption-keys. But since they are encrypted with the same keys, there must at least be some validation on the payload expectations.

Regardless, an invalid token must not be resulting in a hard failure right? An invalid token must simply result in a "bad request" for the end-user who is using, or trying to use OAuth.

I'm not sure how else we'd have to implement OAuth, without having to duplicate & modify the grants... and do the validation of token payload ourselves, which removes a bit of purpose of using the framework.

This does feel more like an implementation issue that could be sorted by users without us having to put in guard rails

Yes, entirely correct, however, we can teach users / integrators but there will always be one. So this must be fool-proof from within, if the user failed to use OAuth correctly, they must see a proper error message, and not something that resulted in a hard-failure.

What are your thoughts on this?