<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
We implemented what's there in order to have a way to refresh ID
tokens and do some very weak session management. It was never widely
used and we didn't push the implementation beyond that because there
was no demand for it.<br>
<br>
To use the assertion properly (which I still don't think you need in
order to do what you're trying to do), you need to figure out not
only how to process the assertions but also which assertions you
trust. You really can't just take in any old assertion that's
inbound and mint a token based on what's inside -- that's nuts and
wildly insecure. You can only trust assertions from trusted
providers with the appropriate attributes in place, and that are
cryptographically protected. So there's a lot more than jus treading
the mandatory fields here, unless you want a security hole the size
of asia in your code.<br>
<br>
-- Justin<br>
<br>
<div class="moz-cite-prefix">On 8/4/2015 5:07 PM, Luiz Omori wrote:<br>
</div>
<blockquote cite="mid:D1E6A068.213C%25luiz.omori@dm.duke.edu"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div>OK.</div>
<div><br>
</div>
<div>Back to the JWT Assertion grant type, why is the existing and
incomplete code expecting an ID token previously generated by
MitreID? Isn’t it just a matter of generating one, and a new
access token, based on the information in the mandatory (for
this flow) JWT token fields (e.g. sub) and request parameters
(e.g. scope)?</div>
<div><br>
</div>
<div>Regards,</div>
<div>Luiz </div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt;
text-align:left; color:black; BORDER-BOTTOM: medium none;
BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT:
0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;
BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Justin Richer
<<a moz-do-not-send="true" href="mailto:jricher@mit.edu">jricher@mit.edu</a>><br>
<span style="font-weight:bold">Date: </span>Thursday, July
30, 2015 at 5:08 PM<br>
<span style="font-weight:bold">To: </span>Luiz Omori <<a
moz-do-not-send="true" href="mailto:luiz.omori@dm.duke.edu"><a class="moz-txt-link-abbreviated" href="mailto:luiz.omori@dm.duke.edu">luiz.omori@dm.duke.edu</a></a>><br>
<span style="font-weight:bold">Cc: </span>"<a
moz-do-not-send="true" href="mailto:mitreid-connect@mit.edu"><a class="moz-txt-link-abbreviated" href="mailto:mitreid-connect@mit.edu">mitreid-connect@mit.edu</a></a>"
<<a moz-do-not-send="true"
href="mailto:mitreid-connect@mit.edu">mitreid-connect@mit.edu</a>><br>
<span style="font-weight:bold">Subject: </span>Re:
[mitreid-connect] JSON Web Token (JWT) Profile for OAuth 2.0
Client Authentication and Authorization Grants<br>
</div>
<div><br>
</div>
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space;
-webkit-line-break: after-white-space;" class="">
You don’t need to use a structure auth code in that case,
since the clients aren’t generating it it can be an opaque
random value.
<div class=""><br class="">
</div>
<div class=""><b class="">However</b>: in that case, your
clients aren’t using the strongly recommended ‘state’
field and are susceptible to cross-site scripting attacks
and session fixation attacks. Much better to use something
like the OpenID Connect “third party login” function which
starts the OAuth process from the client side. You
basically go to a URL on the client app that says which
issuer to start the process with.
<div class=""><br class="">
</div>
<div class=""> — Justin</div>
<div class=""><br class="">
<div class="">
<div>
<blockquote type="cite" class="">
<div class="">On Jul 30, 2015, at 4:14 PM, Luiz
Omori <<a moz-do-not-send="true"
href="mailto:luiz.omori@duke.edu" class="">luiz.omori@duke.edu</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div style="word-wrap: break-word;
-webkit-nbsp-mode: space; -webkit-line-break:
after-white-space; font-size: 14px;
font-family: Calibri, sans-serif;" class="">
<div class="">They are being launched straight
through the redirect_url. Basically they
think that they got an authorization_code
and will exchange it by an access_token. I
agree, we will have to re-think this
scenario as it’s getting too “deviant”.</div>
<div class=""><br class="">
</div>
<div class="">Regards,</div>
<div class="">Luiz</div>
<div class=""><br class="">
</div>
<span id="OLK_SRC_BODY_SECTION" class="">
<div style="font-family: Calibri; font-size:
11pt; text-align: left; border-width: 1pt
medium medium; border-style: solid none
none; padding: 3pt 0in 0in;
border-top-color: rgb(181, 196, 223);"
class="">
<span style="font-weight:bold" class="">From:
</span>Justin Richer <<a
moz-do-not-send="true"
href="mailto:jricher@mit.edu" class=""><a class="moz-txt-link-abbreviated" href="mailto:jricher@mit.edu">jricher@mit.edu</a></a>><br
class="">
<span style="font-weight:bold" class="">Date:
</span>Thursday, July 30, 2015 at 4:04 PM<br
class="">
<span style="font-weight:bold" class="">To:
</span>Luiz Omori <<a
moz-do-not-send="true"
href="mailto:luiz.omori@dm.duke.edu"
class=""><a class="moz-txt-link-abbreviated" href="mailto:luiz.omori@dm.duke.edu">luiz.omori@dm.duke.edu</a></a>><br
class="">
<span style="font-weight:bold" class="">Cc:
</span>"<a moz-do-not-send="true"
href="mailto:mitreid-connect@mit.edu"
class="">mitreid-connect@mit.edu</a>"
<<a moz-do-not-send="true"
href="mailto:mitreid-connect@mit.edu"
class="">mitreid-connect@mit.edu</a>><br
class="">
<span style="font-weight:bold" class="">Subject:
</span>Re: [mitreid-connect] JSON Web
Token (JWT) Profile for OAuth 2.0 Client
Authentication and Authorization Grants<br
class="">
</div>
<div class=""><br class="">
</div>
<div class="">
<div style="word-wrap: break-word;
-webkit-nbsp-mode: space;
-webkit-line-break: after-white-space;"
class="">
If they’re doing grant_type=code, then
they’re not doing the JWT Assertion
grant type. It sounds to me like you’re
possibly conflating the two types. You
can have different clients doing
different grant types, so I don’t see
what the issue would be implementing the
new type. What kind of clients do you
have that think they’re doing the code
flow but need the assertions flow?
<div class=""><br class="">
</div>
<div class=""> — Justin</div>
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Jul 30, 2015, at
4:00 PM, Luiz Omori <<a
moz-do-not-send="true"
href="mailto:luiz.omori@duke.edu"
class=""><a class="moz-txt-link-abbreviated" href="mailto:luiz.omori@duke.edu">luiz.omori@duke.edu</a></a>>
wrote:</div>
<br
class="Apple-interchange-newline">
<div class="">
<div style="word-wrap:
break-word; -webkit-nbsp-mode:
space; -webkit-line-break:
after-white-space; font-size:
14px; font-family: Calibri,
sans-serif;" class="">
<div class="">Thanks. A
problem for us to implement
another flow is that some
external clients are doing
grant_type=code for this
scenario.</div>
<div class=""><br class="">
</div>
<div class="">Regards,</div>
<div class="">Luiz </div>
<div class=""><br class="">
</div>
<span
id="OLK_SRC_BODY_SECTION"
class="">
<div style="font-family:
Calibri; font-size: 11pt;
text-align: left;
border-width: 1pt medium
medium; border-style:
solid none none; padding:
3pt 0in 0in;
border-top-color: rgb(181,
196, 223);" class="">
<span
style="font-weight:bold"
class="">From: </span>Justin
Richer <<a
moz-do-not-send="true"
href="mailto:jricher@mit.edu"
class=""><a class="moz-txt-link-abbreviated" href="mailto:jricher@mit.edu">jricher@mit.edu</a></a>><br
class="">
<span
style="font-weight:bold"
class="">Date: </span>Thursday,
July 30, 2015 at 3:50 PM<br
class="">
<span
style="font-weight:bold"
class="">To: </span>Luiz
Omori <<a
moz-do-not-send="true"
href="mailto:luiz.omori@dm.duke.edu"
class=""><a class="moz-txt-link-abbreviated" href="mailto:luiz.omori@dm.duke.edu">luiz.omori@dm.duke.edu</a></a>>,
"<a moz-do-not-send="true"
href="mailto:mitreid-connect@mit.edu" class="">mitreid-connect@mit.edu</a>"
<<a
moz-do-not-send="true"
href="mailto:mitreid-connect@mit.edu"
class=""><a class="moz-txt-link-abbreviated" href="mailto:mitreid-connect@mit.edu">mitreid-connect@mit.edu</a></a>><br
class="">
<span
style="font-weight:bold"
class="">Subject: </span>Re:
[mitreid-connect] JSON Web
Token (JWT) Profile for
OAuth 2.0 Client
Authentication and
Authorization Grants<br
class="">
</div>
<div class=""><br class="">
</div>
<div class="">
<div bgcolor="#FFFFFF"
text="#000000" class="">We
do have an issue to
support this grant type,
but no immediate plans:<br
class="">
<br class="">
<a
moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/issues/616"><a class="moz-txt-link-freetext" href="https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/issues/616">https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/issues/616</a></a><br
class="">
<a
moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/issues/411"><a class="moz-txt-link-freetext" href="https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/issues/411">https://github.com/mitreid-connect/OpenID-Connect-Java-Spring-Server/issues/411</a></a><br
class="">
<br class="">
The correct way to
implement this is not to
coopt the Authorization
Code flow but rather to
implement a new handler
for it specifically.
What you're doing right
now is very off-spec,
and I wouldn't recommend
it. We've got the hooks
in place for supporting
the assertion processing
(see the above issues)
but we don't yet have
all the processing to do
it.<br class="">
<br class="">
We'd be happy to take a
pull request to add this
functionality, assuming
that it didn't break any
of the other grant
types.<br class="">
<br class="">
-- Justin<br class="">
<br class="">
<div
class="moz-cite-prefix">On
7/30/2015 3:46 PM,
Luiz Omori wrote:<br
class="">
</div>
<blockquote
cite="mid:D1DFF74C.2005%25luiz.omori@dm.duke.edu"
type="cite" class="">
<div
style="font-family:
Calibri, sans-serif;
font-size: 14px;"
class="">Hi,</div>
<div
style="font-family:
Calibri, sans-serif;
font-size: 14px;"
class=""><br
class="">
</div>
<div style="widows:
1;" class=""><font
class=""
face="Calibri,sans-serif">We
have an use case
for exchanging a
JWT by an
access_token,
exactly how is
described by JSON
Web Token (JWT)
Profile for OAuth
2.0 Client
Authentication and
Authorization
Grants (</font><a
moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://tools.ietf.org/html/rfc7523"><a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/rfc7523">http://tools.ietf.org/html/rfc7523</a></a><font
class=""
face="Calibri,sans-serif">).
Basically SSO for
us. We did some
prototyping
replacing the
defaultOAuth2AuthorizationCode
by a class that
extends it and
also recognizes
trusted JWTs
(consumerAuthorizationCode).
The parameters
necessary to
create an
OAuthAuthentication
object are coming
from from the
trusted JWT and
application
registration DB.
This appears to be
working as
expected, the only
thing is that the
grant_type has to
be “code” instead
of </font><span
style="font-family:
Calibri,
sans-serif;
widows: 1;"
class="">"urn:ietf:params:oauth:grant-</span><span
style="widows: 1;"
class=""><font
class=""
face="Calibri,sans-serif">type:jwt-bearer”
as defined in
the RFC for this
flow. </font></span></div>
<div style="widows:
1;" class=""><span
style="widows: 1;"
class=""><font
class=""
face="Calibri,sans-serif"><br
class="">
</font></span></div>
<div style="widows:
1;" class=""><span
style="widows: 1;"
class=""><font
class=""
face="Calibri,sans-serif">Thoughts?
Any plans to
support this
grant type?</font></span></div>
<div
style="font-family:
Calibri,
sans-serif;"
class=""><br
class="">
</div>
<div
style="font-family:
Calibri,
sans-serif;"
class="">Regards,</div>
<div
style="font-family:
Calibri, sans-serif;
font-size: 14px;"
class="">Luiz</div>
<br class="">
<fieldset
class="mimeAttachmentHeader"></fieldset>
<br class="">
<pre class="" wrap="">_______________________________________________
mitreid-connect mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:mitreid-connect@mit.edu">mitreid-connect@mit.edu</a><a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://mailman.mit.edu/mailman/listinfo/mitreid-connect">http://mailman.mit.edu/mailman/listinfo/mitreid-connect</a></pre>
</blockquote>
<br class="">
</div>
</div>
</span></div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</span></div>
</div>
</blockquote>
</div>
<br class="">
</div>
</div>
</div>
</div>
</div>
</span>
</blockquote>
<br>
</body>
</html>