Re: [OAUTH-WG] JWT profile and IdentityServer

[Dominick Baier <[e-mail]>]

Hey,

No problem - this email was not intended to make you change the document.
Just my conclusions.

OK - let me just set the scene first

* IdentityServer is not a “off the shelf” product or SaaS - it is a
framework. IOW - developers have much greater flexibility and less
constraints to implement custom scenarios. This - as a consequence - allows
doing something “dangerous” - e.g.we cannot enforce how subs or client_id
are generated.

* Every token/identity handling logic in IdentityServer is based on a
simple rule: “if there is a sub - a user is involved, if not - then not”.
Call me old-school - but simplicity wins ;) And this formula has worked
very well for us and our customers. Changing this means we need to re-visit
every place where this logic is applied - so do our customers in both their
STS and resource server implementations. This change is of course doable -
but def. not at this moment in time especially since I am still struggling
if this is the right thing to do or not.

Lastly - I am not sure I understand this comment "not to be enough to
violate 7519”.

The sub claim is OPTIONAL.

https://tools.ietf.org/html/rfc7519#section-4.1.2

And so is aud btw.

So I do not really need to comment on the below scenarios in detail because
they are all a consequence of the above. I could make all these changes,
but they might require a substantial internal change of our logic. So we
decided to not do it. I can only imagine that other STS implementations
come to the same conclusion. And yes I know - you cannot please everybody ;)


Still some comment inline...


thanks
———
Dominick Baier

On 4. May 2020 at 10:20:16, Vittorio Bertocci ([e-mail])
wrote:

Thank you Dominick, very useful!

I’d like to understand more about the security risks you mention. My goal
is not to change your mind on the implementatio, just to make sure I better
understand the general implication.

*>* the user info endpoint needs to do extra checking*

This is an interesting use case. Often the token issued for the userinfo is
formatless, given that it is colocated within the AS, but I can see how
using JWT for your own userinfo might be useful if you don’t particularly
care about token size or you don’t want to handle an internal token
format/reference.


Could you expand on the security risk? Either the sub doesn’t correspond to
a user, or if it does, the AS itself was the issuer hence it had full
control of whether a sub for a user would end up in a token obtained via
client creds grant… the main way I can see this going south would be if the
developer is allowed to place an arbitrary sub value, but in that case the
issue seem larger (eg in a grant including a user, placing the sub of
another user).


We use the JWT. Sub = user ID. OIDC scopes = what data is returned. This
needs slightly updated logic



*>* extension grants that did not use to present users*

Technically we are still not presenting users- the sub is the authenticated
subject, which can be a user or an app. Here I am channeling the consensus
that was reached after quite a few back and forths, see
https://mailarchive.ietf.org/arch/msg/oauth/F2lLetla0K27W0o2b9oWo0Z8lbM/.

That’s fine - not trying to change your mind



But besides the nitpicking. Could you expand on the extension grants you
are thinking of, and how they’d be affected?

Again our internal extension grant logic is based on the existence of the
sub claim after the response data has been generated. If sub is present we
invoke a whole pipeline around user centric claims. Needs to be changed.



*>* token exchange scenarios*

This is another really interesting point. I admit I haven’t studied the RFC
and I might be remembering an older version, but I believe the specs
referred to principals, which aren’t necessarily human; and I remember one
dev from the community describing a scenario where he would have liked to
be able to do OBO with machine identities, and his scenario was reasonable.

Is there anything specific that breaks in your implementation of token
exchange if you have a sub not corresponding to a user?

See above.





>* enforce a collision domain for sub and client_id

If your product allows developers to arbitrarily set values for one or both
of those, I totally see how enforcement would be extra work! I would argue
that in that case perhaps you don’t have to, if the user can set arbitrary
values they can already do things that would break standards (like
assigning the same sub to two different users) hence in that case you can’t
be responsible for it at product design, it’s kind of up to them.



Note, I know that answering the above might require extra work in
investigating and writing about it, I don’t mean to burden you with it. My
aim here is understanding whether the challenges you identified mostly stem
from the underlying assumption “presence of a sub=>it’s a user”, which is
understandable but was established in the discussions referenced above not
to be enough to violate 7519, or if there are other factors at play that
introduce challenges when sub is used that way.

Thanks again for putting time in checking this and considering implementing
it!

Cheers,

V.



*From: *Dominick Baier <[e-mail]>
*Date: *Monday, May 4, 2020 at 00:36
*To: *"[e-mail]" <[e-mail]>, "[e-mail]" <
[e-mail]>
*Subject: *JWT profile and IdentityServer



Hey,



Just some notes on applying the JWT profile to IdentityServer



* we emit the at+jwt typ - that’s very useful

* we emit iat in addition to nbf (if we would remove nbf, we would break
the .NET JWT library from Microsoft - I guess that’s the reason AAD emits
it as well)

* we have an option to emit scope as a space delimited string (we used a
string array for historic reasons - also because that’s how the claims
plumbing in .NET prefers it)



* aud



Audience is optional in IdentityServer if you request scopes that do not
have an association to a resource. I personally think this is the right way
to go. You can “force” an audience even for this situation if you
absolutely want to



* sub vs client_id



In IdentityServer access tokens that do not have a user present, do not
have a sub claim - only client_id. If there is a user present, sub ALWAYS
represents the user.



I was prototyping a setting to emit the sub claim for situation where there
is no user, which would not be hard to do - but we found out that there are
many situations where this would need VERY THOROUGH testing of all the
various flows to not introduce subtle security bugs



* the user info endpoint needs to do extra checking

* extension grants that did not use to present users

* token exchange scenarios

* enforce a collision domain for sub and client_id



This could all be sorted probably if I would have enough time right now -
but the bottom line is, that this ambiguity and special casing requires
careful re-writing and I guess this applies to any reasonably complex
system that is already out there. So I am still not sold that the “dual
purpose” claims are the best choice. YMMV.



IOW - we will not adopt the sub/client_id semantics as proposed by the
document.





My 2c / cheers

———

Dominick Baier