<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
<br class="gmail_msg">
IdPs don't support artifact much in practice, so not really a practical option at this point, at least not for the Shibboleth case.<br class="gmail_msg"></blockquote><div><br></div><div>Thats the funny part of OIDC, its essentially the artifact profile encoded in JSON instead of XML.  Makes sense if you think about it.  The hard part about artifact is requiring the back-channel communications between the idp and the sp but since most of the first OIDC idps were public (ie Google, LinkedIn, etc) thats not a problem where as post profile is great when you don't have that back channel pipe.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
But what's broken here is that it can't be the app that consumes the URL and requests the id_token, it has to be a web server the app is talking to. In which case it shouldn't matter what the URL is or what protocol is involved. If it's specific to OIDC, that would imply the client app is doing the id_token call, and that wouldn't be secure.<br class="gmail_msg"></blockquote><div><br></div><div>In saml there's an SP, IdP and Agent (browser).  In OIDC the RP (SP) can ALSO be the agent.  Each device would be an RP and would use the code_token to get an id_token (which is the assertion) which an app can validate to know who you are (just like an assertion it's signed, has attributes, expires, etc).   Now, most apps are going to require that  a backend web service knows who you are.  You can send the id_token in a web service call using OAuth2 bearer tokens (this is how Kubernetes works) OR you can use the id_token to somehow get another token used by your web services but once you have an id_token the IdP is done (until the id_token expires then you use the refresh token to get a new one).</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
So either they got this all really wrong, or more likely they just used it to drive an agenda without a good reason.<br class="gmail_msg"><br></blockquote><div><br></div><div>More like "we hate PKI and XML so we're going to invent an SSO protocol that doesn't need them but it turns out you can't reliable establish trust without PKI so we'll use as little as possible and jump through all sorts of hoops that SAML solved a long time ago".  Its like when SCIM was first created everyone in the room agreed they didn't want to create a JSON verson of LDAP...then they created a JSON version of LDAP. </div></div></div>