Fix authlib.oauth2.rfc9068.JWTIntrospectionEndpoint documentation mistakes

[twalcari]

A small fix to the documentation of authlib.oauth2.rfc9068.JWTIntrospectionEndpoint

What kind of change does this PR introduce? (check at least one)

• Bugfix
• Feature
• Code style update
• Refactor
• Other, please describe:

Does this PR introduce a breaking change? (check one)

• Yes
• No

---

• You consent that the copyright of your pull request source code belongs to Authlib's author.

[twalcari]

Hi @azmeuk , can you clarify why the documentation of authlib.oauth2.rfc9068.JWTIntrospectionEndpoint mentioned:

authorization_server.register_endpoint(MyRefreshTokenIntrospectionEndpoint)

That class MyRefreshTokenIntrospectionEndpoint is not mentioned in the code example. Does that line need to be removed, or must that class MyRefreshTokenIntrospectionEndpoint be added to the documentation?

The same issue arises for the authlib.oauth2.rfc9068.JWTRevocationEndpoint by the way.

[azmeuk]

This one is definitively an error. 👍

[azmeuk]

The MyRefreshTokenIntrospectionEndpoint is not mentionned in the code, I simply added this to illustrate that there can be several introspection endpoints for different kinds of token (jwt or refresh for instance).

If several introspection endpoints are registered with register_endpoint, the first one will be executed. If a ContinueIteration exception is raised, then the second registration endpoint is executed and so on. Practically, when JWTIntrospectionEndpoint gets a refresh token, it passes it to the next registered introspection endpoint by raising a ContinueIteration.

authlib/authlib/oauth2/rfc9068/introspection.py

Lines 63 to 65 in d589d4f

	# do not attempt to decode refresh_tokens
	if request.form.get('token_type_hint') not in ('access_token', None):
	raise ContinueIteration()

This behavior has been introduced with #576 but not documented. I am opened to ideas for making the documentation clearer about this.