Adds user_secret validation for auth_token and refresh_token

[henrikwirth]

Related issue: #79

So I tried myself on some php today and implemented the validation for user_secrets.

• Added user_secret to auth_token, not just refresh_token
• Added a validation step, that throws an error if no user_secret is present in the token or the user_secret doesn't match the one in graphql_jwt_auth_secret meta data.
• Oh and I changed the expiry time to 30 days instead of 365. When I read about expiry times, it was mostly not more than 30 days I think.

If we want to keep the statelessness of auth_tokens, we could make this optional, so you could opt in, to have the user_secret in auth_tokens?

I'd like to give that option actually, so the users can decide themselves. Also we could let them override the expiry time days. What would be the best option to give that choice? A backend option_page or just a define in config.php?

Well it is not the most beautiful code and I haven't written tests for it, but @jasonbahl said the code will likely be refactored and we just wanna get things working for now.

[henrikwirth]

I just added $auth_token_is_stateful, so we can decide on one point in the code, if the auth_token is stateful or not. Then we only need a way for the user to define this flag.

[jasonbahl]

I'd like to give that option actually, so the users can decide themselves. Also we could let them override the expiry time days. What would be the best option to give that choice? A backend option_page or just a define in config.php?

For now, if we provide proper hooks/filters, folks can use them to override these types of settings.

Some sort of backend option page I think will need a larger discussion on how to best approach that. Do we want the main WPGraphQL plugin to add a graphql menu item, and extensions can have pages below it? Do we want to have some admin ui class that can be re-used for extension plugins for building setting pages, etc?

I'm hesitant to add admin pages for these plugins as it creates a lot of maintenance overhead, etc.

[jasonbahl]

Added user_secret to auth_token, not just refresh_token

If we go this way, we can probably go to a single-token flow then? 🤔

The 2-token approach was because the access token couldn't be revoked or otherwise invalidated, but was short lived, so the 2nd token allowed to refresh, but do nothing else.

If the auth-token now has the user_secret as well, the 2 tokens are the same and there's not really any need for both types of tokens, or a refresh flow at all, eh?