<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body 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.&nbsp;<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="">&nbsp;— 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 &lt;<a href="mailto:luiz.omori@duke.edu" class="">luiz.omori@duke.edu</a>&gt; wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" 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 &lt;<a href="mailto:jricher@mit.edu" class="">jricher@mit.edu</a>&gt;<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 &lt;<a href="mailto:luiz.omori@dm.duke.edu" class="">luiz.omori@dm.duke.edu</a>&gt;<br class="">
<span style="font-weight:bold" class="">Cc: </span>"<a href="mailto:mitreid-connect@mit.edu" class="">mitreid-connect@mit.edu</a>" &lt;<a href="mailto:mitreid-connect@mit.edu" class="">mitreid-connect@mit.edu</a>&gt;<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="">&nbsp;— Justin</div>
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Jul 30, 2015, at 4:00 PM, Luiz Omori &lt;<a href="mailto:luiz.omori@duke.edu" class="">luiz.omori@duke.edu</a>&gt; 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&nbsp;</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 &lt;<a href="mailto:jricher@mit.edu" class="">jricher@mit.edu</a>&gt;<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 &lt;<a href="mailto:luiz.omori@dm.duke.edu" class="">luiz.omori@dm.duke.edu</a>&gt;, "<a href="mailto:mitreid-connect@mit.edu" class="">mitreid-connect@mit.edu</a>" &lt;<a href="mailto:mitreid-connect@mit.edu" class="">mitreid-connect@mit.edu</a>&gt;<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 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><br class="">
<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><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="">
&nbsp;-- 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 face="Calibri,sans-serif" class="">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" href="http://tools.ietf.org/html/rfc7523" style="font-family: Calibri, sans-serif; font-size: 14px;" class=""></a><a class="moz-txt-link-freetext" href="http://tools.ietf.org/html/rfc7523">http://tools.ietf.org/html/rfc7523</a><font face="Calibri,sans-serif" class="">).
 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&nbsp;</font><span style="font-family: Calibri, sans-serif; widows: 1;" class="">"urn:ietf:params:oauth:grant-</span><span style="widows: 1;" class=""><font face="Calibri,sans-serif" class="">type:jwt-bearer”
 as defined in the RFC for this flow.&nbsp;</font></span></div>
<div style="widows: 1;" class=""><span style="widows: 1;" class=""><font face="Calibri,sans-serif" class=""><br class="">
</font></span></div>
<div style="widows: 1;" class=""><span style="widows: 1;" class=""><font face="Calibri,sans-serif" class="">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 wrap="" class="">_______________________________________________
mitreid-connect mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mitreid-connect@mit.edu">mitreid-connect@mit.edu</a><a 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></body></html>