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
