Re: [OAUTH-WG] JWT profile and IdentityServer

Dominick Baier <> Mon, 04 May 2020 08:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EC0CA3A0408 for <>; Mon, 4 May 2020 01:55:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id svVer1CkZNLU for <>; Mon, 4 May 2020 01:55:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4B0BD3A0406 for <>; Mon, 4 May 2020 01:55:44 -0700 (PDT)
Received: by with SMTP id c10so4762657qka.4 for <>; Mon, 04 May 2020 01:55:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=l1pTwey+NioQB5WRoQ5/YmAIjOU3Cijfr3iimJLEfTU=; b=WhC2LinO4qL29k/BG57NGMBAB+QBo+G87vKlm0X2EcyEjQQ+MpwJc4kyKZXQSq232i 22zYOHyaUU/oK3ASvhPX3Dh+XMi+7JgXVjJXiuhbP2aY9KaLX5nQhq6Q3t6zHU0ooC0W jAOqUo9Xa1PKoyUrjU2QI/DOTm8QaVjvI6XWnVyOFzxX2KCU2j0pXkQVGWD6/DANHnOx 2FhdhDi7DQmW3rby8NMGM/VxBFnWT9I4O0cg77llMZ3EYLzrz7zhZeZopHSbSxL3yPyx wapaM3VGv4cmmrBsaxpofJVQzK8fbac7N+6AuQ78NiDWFgXrIXnl/fOkklQO/WR+K0tL +ymQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=l1pTwey+NioQB5WRoQ5/YmAIjOU3Cijfr3iimJLEfTU=; b=Zb0LlBXdryAiVaud7U/8Vs3MUOnKcbSyakTth9aUpTnv69WLVOLqUF4GnPaXKlQCBL 9SKtHcAgEAlYbTm6L6ipQth2pbe43vE3710YSoxXtyedISY6vZpsgvO+bm6l8WMvwr6Y 4VwLy80ju6OZ+fKCMH8rk2FcQTqokd6zsp8V16GaoGJOaRAI0+BkalIJeGVmOadf9POC dewzyInn4TyqPnungV44Q0ypDUYCZJ2ICDyFoyhXMlLLX2q0FotCtLof0c36x7/BuMkW huGkBHhHAEv5JqLbmwQy6BXzZaKEyxOZMbF3pDMnFrY1ClZG1MSh8CtVZ7YNDO6bNN/8 IQiA==
X-Gm-Message-State: AGi0PuZY6kLIB596R9LEy/OjitF/DaDHj0Gjlhf1P3EY9lXn8oq5R5tB TMOif4ssRryoy6Z1dPrMVLrqhWoNcT+sIRU0/U/uh4Y=
X-Google-Smtp-Source: APiQypK7DGJLNlACvYuBm98KfMHFoydXtYuj/rozSv2Q8uuar6VEwHYEkbtk+GW99rsId/ZmMy2cR+99pcSDmaT6GII=
X-Received: by 2002:a37:82c1:: with SMTP id e184mr15674080qkd.186.1588582542574; Mon, 04 May 2020 01:55:42 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Mon, 4 May 2020 04:55:41 -0400
From: Dominick Baier <>
In-Reply-To: <>
References: <> <>
MIME-Version: 1.0
Date: Mon, 4 May 2020 04:55:41 -0400
Message-ID: <>
To: "" <>, Vittorio Bertocci <>
Content-Type: multipart/alternative; boundary="0000000000002599dc05a4ceb2f2"
Archived-At: <>
Subject: Re: [OAUTH-WG] JWT profile and IdentityServer
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 May 2020 08:55:47 -0000


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.

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...

Dominick Baier

On 4. May 2020 at 10:20:16, Vittorio Bertocci (

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

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

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



*From: *Dominick Baier <>
*Date: *Monday, May 4, 2020 at 00:36
*To: *"" <>rg>, "" <>
*Subject: *JWT profile and IdentityServer


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

My 2c / cheers


Dominick Baier