<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I wrote in my blog recently that I’ve been working with a client whose offering is right along those lines but for the AS/RS side: Authlete. <a href="https://www.authlete.com/" class="">https://www.authlete.com/</a> Maybe there could be a similar approach on the client side, though I agree that’s a bit trickier as you’re managing sessions and other fun stuff. <div class=""><br class=""></div><div class="">Basically, you do somethings locally like user authentication but you hand the guts of the protocol itself off to a service, which processes it and tells you what to do next. It’s a different approach, what I’m calling semi-hosted. </div><div class=""><br class=""></div><div class="">The important thing here is that what you gain in pushing off complexity you’re losing in local control. That may or may not be what you think you’ve signed up for, too, so you need to approach it with caution. You’ve got more parties who are exposed to runtime secrets, and you also still have to secure the connection between your app and the service anyway. But I do like that it’s a different place to draw the line of control and responsibility than what was available to folks previously. As always, no matter where the service runs, it’s your problem if it goes south.</div><div class=""><br class=""></div><div class=""><a href="https://medium.com/@justinsecurity/deployment-and-hosting-patterns-in-oauth-a1666dc0d966" class="">https://medium.com/@justinsecurity/deployment-and-hosting-patterns-in-oauth-a1666dc0d966</a></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""> — Justin</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 14, 2017, at 10:58 AM, George Fletcher via Openid-specs-ab <<a href="mailto:openid-specs-ab@lists.openid.net" class="">openid-specs-ab@lists.openid.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">I've run into a few things over the last year rolling out OpenID Connect within the enterprise for our B2B partners. I see the RP dev work falling into three main areas...<br class=""><br class="">1. Code to implement the spec and it's best practice<br class="">2. Securely managing client_id "secrets" whether private key or shared secret<br class="">3. Securely managing returned tokens<br class=""><br class="">There are many libraries that handle #1 but I haven't seen code that addresses items 2 and 3. Any recommendations or interest in items 2 and 3?<br class=""><br class="">On the working group call today, we talked about two architectures to help RPs. One is more of a "gateway" model where the gateway does all the OIDC work and then passes the necessary data down stream to the RP. This could be a service so that RP has no deployment work. The other model is more of a module deployed by the RP that handles items 1-3 on the RPs behalf.<br class=""><br class="">Thanks,<br class="">George<br class="">_______________________________________________<br class="">Openid-specs-ab mailing list<br class=""><a href="mailto:Openid-specs-ab@lists.openid.net" class="">Openid-specs-ab@lists.openid.net</a><br class="">http://lists.openid.net/mailman/listinfo/openid-specs-ab<br class=""></div></div></blockquote></div><br class=""></div></body></html>