
<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

</head>

<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">

<div>

<blockquote type="cite" class="">

<div class="">

<div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; direction: inherit;" class="">

The OIDC add-on that we had written for Shib also provides OAuth2.0 support. </div>

</div>

</blockquote>

<br class="">

</div>

<div>Even better, but I assume this uses the real storage service and thus makes the IdP stateful, yes?  A shim would allow you to make only that piece stateful.</div>

<div><br class="">

</div>

<div>It's a defensible trade-off in either direction.</div>

<div><br class="">

</div>

<div>Regardless, the two big caveats:</div>

<div><br class="">

</div>

<div>A)  Over time, this will effectively turn that hostname into an entityID unless their OAuth 2.0 implementation(and any others that come along) supports metadata or discovery.  I have a hunch.</div>

<div>B)  This is reintroducing the back channel unless you come up with a way to encode nodes into the OAuth tokens and teach a reverse proxy how to read them.  There is, AFAIK, no standard way to do that.  It's on my wishlist for OAuth, CAS, and more.</div>

</body>

</html>