Subject: Re: [OAUTH-WG] For a client credentials grant, what are you returning as the value of the "sub" element in an introspection response?

From: Todd W Lainhart <[email-masked]>
Date: Thu, 12 Jun 2014 16:50:29 -0400

One problem we've discovered when returning the client_id value as "sub" 
is client impersonation.  That is, in a system where a user can 
self-register, it's possible that the user could register an id/sub value 
that is the same as the client_id value, and thus be granted the same 
privileges as the application principal based on the introspection 
response.

We're leaning towards returning the grant_type in the introspection 
response to disambiguate this case.  i.e. if grant_type == 
"client_credentials" then you know that the bearer represents the app 
principal.

http://tools.ietf.org/html/draft-richer-oauth-introspection-04 expired 
last Nov.  Were you thinking of picking it up?  I'm recalling that Nat 
Sakimura expressed an interest a while back.

Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
[email-masked]

From:   Justin Richer <[email-masked]>
To:     Todd W Lainhart/Lexington/IBM@IBMUS, IETF oauth WG 
<[email-masked]>, 
Date:   05/22/2014 10:45 AM
Subject:        Re: [OAUTH-WG] For a client credentials grant, what are 
you returning as the value of the "sub" element in an introspection 
response?

We return the client_id of the client that the token was issued to.

 -- Justin

On 5/22/2014 10:08 AM, Todd W Lainhart wrote:
For folks who have implemented the client credentials grant and 
introspection, I'm interested to know what you're returning for the value 
of "sub" in the token introspection response (
http://tools.ietf.org/html/draft-richer-oauth-introspection-04#section-2.2
).  The "client_id" value requesting the grant, or some other client 
registration metadata value? 

Todd Lainhart
Rational software
IBM Corporation
550 King Street, Littleton, MA 01460-1250
1-978-899-4705
2-276-4705 (T/L)
[email-masked]

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Thu, 12 Jun 2014 17:18:21 -0400

I haven’t touched the draft for a while because the basics have fit most of our use cases and there hasn’t been a clamor from the working group to standardize it. I’d be happy to pick it back up if the working group wanted to make it an official document.

Having run this in production for a little while, there are a handful of things that would make sense to include in the standard response set. Things like returning the grant type, response type, as it’s all a part of the request that made the token. We’ve also had questions recently about returning both the ‘sub’ of a user as defined by OpenID Connect in addition to a more traditional user_id/username field (our deployment does both, and they’re different — the former is stable but the latter is used to cross-index into other systems). 

 — Justin

On Jun 12, 2014, at 4:50 PM, Todd W Lainhart <[email-masked]> wrote:

> One problem we've discovered when returning the client_id value as "sub" is client impersonation.  That is, in a system where a user can self-register, it's possible that the user could register an id/sub value that is the same as the client_id value, and thus be granted the same privileges as the application principal based on the introspection response. 
> 
> We're leaning towards returning the grant_type in the introspection response to disambiguate this case.  i.e. if grant_type == "client_credentials" then you know that the bearer represents the app principal. 
> 
> http://tools.ietf.org/html/draft-richer-oauth-introspection-04 expired last Nov.  Were you thinking of picking it up?  I'm recalling that Nat Sakimura expressed an interest a while back.
> 
> 
> 
> 
> Todd Lainhart
> Rational software
> IBM Corporation
> To:        Todd W Lainhart/Lexington/IBM@IBMUS, IETF oauth WG <[email-masked]>, 
> Subject:        Re: [OAUTH-WG] For a client credentials grant, what are you returning as the value of the "sub" element in an introspection response? 
> 
> 
> 
> For folks who have implemented the client credentials grant and introspection, I'm interested to know what you're returning for the value of "sub" in the token introspection response (http://tools.ietf.org/html/draft-richer-oauth-introspection-04#section-2.2).  The "client_id" value requesting the grant, or some other client registration metadata value?
> 
> 
> 
> Todd Lainhart
> Rational software
> IBM Corporation

---

From: Todd W Lainhart <[email-masked]>
Date: Thu, 12 Jun 2014 17:39:32 -0400

> I’d be happy to pick it back up if the working group wanted to make it 
an official document.

+1

Todd Lainhart
Rational software
IBM Corporation

From:   Justin Richer <[email-masked]>
To:     Todd W Lainhart/Lexington/IBM@IBMUS, 
Cc:     IETF oauth WG <[email-masked]>
Date:   06/12/2014 05:18 PM
Subject:        Re: [OAUTH-WG] For a client credentials grant, what are 
you returning as the value of the "sub" element in an introspection 
response?

I haven’t touched the draft for a while because the basics have fit most 
of our use cases and there hasn’t been a clamor from the working group to 
standardize it. I’d be happy to pick it back up if the working group 
wanted to make it an official document.

Having run this in production for a little while, there are a handful of 
things that would make sense to include in the standard response set. 
Things like returning the grant type, response type, as it’s all a part of 
the request that made the token. We’ve also had questions recently about 
returning both the ‘sub’ of a user as defined by OpenID Connect in 
addition to a more traditional user_id/username field (our deployment does 
both, and they’re different — the former is stable but the latter is used 
to cross-index into other systems). 

 — Justin

Todd Lainhart
Rational software
IBM Corporation

To:        Todd W Lainhart/Lexington/IBM@IBMUS, IETF oauth WG <
[email-masked]>, 

-- Justin

Todd Lainhart
Rational software
IBM Corporation

[attachment "signature.asc" deleted by Todd W Lainhart/Lexington/IBM]