Problems with Token Introspection

[angelakis]

There are some issues regarding the token introspection endpoint:

• Currently, do_jws method returns a reply in case of any exception, which manages to pass all checks and return active = True! I think any valid jwt with a wrong algorithm or an unknown key id will raise an exception in do_jws and return active = true. (Maybe do_jws should instead return None in that case)
• The do_access_token fails to do any time checks.
• Tokens are never checked for revocation (black_list).
• self.endpoint_context.sdb[token] in do_access_token raises KeyError in the case of not-existing token. This is not handled (the if/else could be changed to a try except)
• The rfc states that tokens should be within its given time window of validity, which means that the iss/nbf should be checked also to be before the current time.

This may be a little off-topic, but we are also interested in allowing configurable claims per client for the introspection response.

[rohe]

I think I've taken care of the 5 bullet points.
Have to think a bit more about the configurable claims per client support.

[rohe]

Regarding configurable claims per client. Would it not be reasonable to have that information in some kind of database ? With perhaps a default if the client can't be found in the database ?

[angelakis]

Regarding configurable claims per client. Would it not be reasonable to have that information in some kind of database ? With perhaps a default if the client can't be found in the database ?

Yes, we were thinking of using the client database for this. Then follows the question if registration should be modified too, to allow setting the default claims on client creation. But that could be another conversation.

[rohe]

That would definitely be another discussion.
To use the client database seems reasonable.

[rohe]

We should probably deal with claims in the similar way to how scopes are now dealt with.

[rohe]

After some work, this is what I have right now:

1. If nothing is specified the set of claims in oidcmsg.oidc.OpenIDSchema is the default.
2. You can change the default set by setting claims_supported in endpoint_context. This is done by configuration.
3. If you add new custom scopes, new claims in those scopes are added to the default set of claims.
4. You can set the default set for a specific client by specifying allowed_claims for that client in the client database. This will override the service wide default. This governs what is returned in an ID Token or from the user info endpoint.
5. To specifically set what claims are returned in an JWT access token you can set access_token_claims per client in the client database.

[angelakis]

So if I understand this correctly, adding a claim to claims_supported will add that claim in the ID token, user info endpoint and introspection endpoint?
If yes, it would be nice to have configurable claims only for the introspection endpoint (like access_token_claims I guess).

#52 the PR with configurable introspection claims allows this, although I guess you would like to combine it with the custom scopes etc.

[rohe]

Do you want claims_supported to only affect ID Token and user info endpoint data and have specific configurable sets for access_token and introspection endpoint ?
All per client.
I'm not sure I want to mix and match.
I'd rather have it clean such that:
claims_supported affects ID Token and user info endpoint,
access_token_claims for access tokens and
introspection_claims for introspection endpoint.

This means that we might have claims that appear in access tokens or are returned from the introspection endpoint that are not among the claims supported.
Or do we stipulate that access token and introspection claims must be a subset of claims_supported ?

[angelakis]

claims_supported affects ID Token and user info endpoint,
access_token_claims for access tokens and
introspection_claims for introspection endpoint.

Yes that's what I meant and wanted.

This means that we might have claims that appear in access tokens or are returned from the introspection endpoint that are not among the claims supported.

This seems good.

[peppelinux]

@rohe this Is a good thread to explain in the documentation I think