-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introspection #217
Introspection #217
Conversation
…ken Introspection Spec being incorporated into IndieAuth
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All looks good to me.
$tokens->update( $token, $return ); | ||
if ( array_key_exists( 'exp', $return ) ) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🔧 to reduce the diff noise this could be moved up to where it was
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Implementation looks good - main thing I'm wary of is the move of the expiration
to exp
in the token, which looks like a breaking change that'd invalidate existing tokens?
It checks for the old parameter and uses it as well, for the migration. |
As per indieweb/indieauth#33, we're adopting the response used by the Token Introspection specification. This means the properties I used, which were internal only, 'expiration' and 'issued_at' should be changed to 'iat' and 'exp' to match. While I could just change them on the response, there was no reason to retain the old structure.
I also changed expires_in to no longer be stored. It is generated only on return, as there is no need to store it.
While the return parameters of the GET token verification are amended, it still, like the original spec, returns a 400 series error for backward compatibility. The new introspection endpoint, which is a POST request, always returns a 200. At some point when clients have caught up, will likely adjust accordingly.
There is a slight reformatting of the POST action handler, which now uses two switch statements, one for action, the other for grant_type=. The reason for this is somewhat practical.
For grant_type, we only support 1 right now, but the new amendment decided at the popup was to include refresh_tokens as a recommendation in the spec(indieweb/indieauth#81) so there would be a new grant_type, which I intend to submit as a separate PR. In indieweb/indieauth#87, @Zegnat proposes extending action as part of the Ticket Auth proposal, so might as well structure for that as well.