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).
>* 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/. But besides the nitpicking. Could you expand on the extension grants you are thinking of, and how they’d be affected? >* 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? >* 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
