Oh - and last thing I forgot to mention. We had the luxury of designing IdentityServer from the ground up after OIDC has been released. So it really was fine tuned to be a OIDC + OAuth implementation. Hence the strong semantics of the sub claim for both the OIDC and OAuth parts. We think this is right because all of our customers use both in conjunction.
IOW - you move our cheese ;) But don’t worry about it. ——— Dominick Baier On 4. May 2020 at 10:55:41, Dominick Baier (dba...@leastprivilege.com) wrote: 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 (vittorio.berto...@auth0.com) 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 <dba...@leastprivilege.com> *Date: *Monday, May 4, 2020 at 00:36 *To: *"oauth@ietf.org" <oauth@ietf.org>, "vittorio.berto...@auth0.com" < vittorio.berto...@auth0.com> *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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
