Re: [OAUTH-WG] New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt

[Neil Madden <[e-mail]>]

I like this draft, but I want to clarify if it is intended that the response JWT could be interpreted as an OpenID Connect ID Token? As the set of claims can overlap (in particular, all required ID token claims are valid token introspection response fields) and it seems highly likely that an AS will use the same keys for signing both (and it definitely will when the client_secret is used for signing), the signed response JWT could well be indistinguishable from an ID token (for the resource owner) with some additional claims.

If this is not the case, then maybe consider adding a “crit”: [“scope”] claim to the response (https://tools.ietf.org/html/rfc7515#section-4.1.11 <https://tools.ietf.org/html/rfc7515#section-4.1.11>) to indicate that the scope claim must be understood.

I can think of one potential use-case (I’ll let you decide the merits of it) where it might actually be useful to explicitly allow the response to be an ID Token. Consider an application (RS) that uses a traditional authorization model: it authenticates a user, sets a cookie, and then based on who that user is makes dynamic access control decisions to see what they are allowed to do (e.g., ACLs, RBAC, whatever). An easy way to upgrade this app to modern standards would be to replace the home-spun authentication system with OIDC, but leave the rest in place. Now the system uses OIDC to authenticate the user, sets the ID token as the cookie, and then still applies the same access control decisions that it always has done.

Now imagine that a new requirement comes in to support OAuth 2.0 access tokens to allow delegation to third-party apps. A really simple way to achieve that would be to put a filter/reverse proxy in front of the RS that extracts access tokens coming in, performs signed JWT token introspection against the AS to validate the token and then checks the the scopes are appropriate for the request. It can then simply replace the access token in the original request with the signed token introspection response (as ID token) and forward it on to the original RS server. As the introspection response is a valid ID token for the resource owner, the RS will then apply all its normal access control checks to ensure that the resource owner actually has the permissions that they have delegated to the client.

I think potentially that is quite an interesting application of this draft, but I don’t think it was intended! I think probably a decision should be made as to whether that kind of usage should be allowed and explicitly adjust the draft to either allow or deny it. If it is allowed, then possibly there should be a way for the caller to hint that they want the response to be a valid ID token.

Kind regards,

Neil

> On 18 Mar 2018, at 19:33, Torsten Lodderstedt <[e-mail]> wrote:
> 
> Hi all,
> 
> I just submitted a new draft that Vladimir Dzhuvinov and I have written. It proposes a JWT-based response type for Token Introspection. The objective is to provide resource servers with signed tokens in case they need cryptographic evidence that the AS created the token (e.g. for liability).
> 
> I will present the new draft in the session on Wednesday.
> 
> kind regards,
> Torsten.
> 
>> Anfang der weitergeleiteten Nachricht:
>> 
>> Von: [e-mail] <mailto:[e-mail]>
>> Betreff: New Version Notification for draft-lodderstedt-oauth-jwt-introspection-response-00.txt
>> Datum: 18. März 2018 um 20:19:37 MEZ
>> An: "Vladimir Dzhuvinov" <[e-mail] <mailto:[e-mail]>>, "Torsten Lodderstedt" <[e-mail] <mailto:[e-mail]>>
>> 
>> 
>> A new version of I-D, draft-lodderstedt-oauth-jwt-introspection-response-00.txt
>> has been successfully submitted by Torsten Lodderstedt and posted to the
>> IETF repository.
>> 
>> Name:		draft-lodderstedt-oauth-jwt-introspection-response
>> Revision:	00
>> Title:		JWT Response for OAuth Token Introspection
>> Document date:	2018-03-15
>> Group:		Individual Submission
>> Pages:		5
>> URL:            https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspection-response-00.txt <https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-jwt-introspection-response-00.txt>
>> Status:         https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection-response/ <https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-jwt-introspection-response/>
>> Htmlized:       https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-00 <https://tools.ietf.org/html/draft-lodderstedt-oauth-jwt-introspection-response-00>
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspection-response <https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-jwt-introspection-response>
>> 
>> 
>> Abstract:
>>   This draft proposes an additional JSON Web Token (JWT) based response
>>   for OAuth 2.0 Token Introspection.
>> 
>> 
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
>> 
>> The IETF Secretariat
>> 
> 
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth