<div dir="ltr"><div><div>I don't disagree with you on all of that. Since swapping an ID token between providers requires the providers to trust each other, there's a lot of undefined backchannel stuff that needs to happen. One provider needs to trust another app's client_id on a different provider in order to proceed. And, I can't think of any standard OAuth2 method to do this on-behalf-of on-behalf-of style authorization check. <br><br></div>Is it all hacky and held together with duct tape? Yes. Is it totally awesome? YES! But, I certainly wouldn't push for something like this unless it was well defined and vetted first. It's a nice discussion topic though!<br><br></div>--Cal<br><div><div><div><div class="gmail_extra"><br clear="all"><br><div class="gmail_quote">On Wed, Apr 22, 2015 at 2:20 PM, Peter Williams <span dir="ltr"><<a href="mailto:home_pw@msn.com" target="_blank">home_pw@msn.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>
<div style="font-family:Calibri,sans-serif;font-size:11pt">I find swapping id tokens for api tokens to be architecturally dubious. It goes against the dod theory about how to manage huge scale key distribution (in complex infrastructure with multiple players)
I was trained in a different era, if course.<br>
<br>
Swapping some beater object verified wrt an idtojen is fine.<br>
<br>
idcerts are not issued for that purpose and only swapping an idtoken at its own issuer is not an open security model (just more American silos).<br>
<br>
Swapping a saml assertion, similarly, I find dubious. It's all very hacky. <br><span class="">
<br>
<br>
<br>
<br>
<br>
Sent from my Windows Phone</span></div>
</div>
<div dir="ltr">
<hr>
<span style="font-family:Calibri,sans-serif;font-size:11pt;font-weight:bold">From:
</span><span style="font-family:Calibri,sans-serif;font-size:11pt"><a href="mailto:cal@fbsdata.com" target="_blank">Cal Heldenbrand</a></span><br>
<span style="font-family:Calibri,sans-serif;font-size:11pt;font-weight:bold">Sent:
</span><span style="font-family:Calibri,sans-serif;font-size:11pt">4/22/2015 11:47 AM</span><br>
<span style="font-family:Calibri,sans-serif;font-size:11pt;font-weight:bold">To:
</span><span style="font-family:Calibri,sans-serif;font-size:11pt"><a href="mailto:home_pw@msn.com" target="_blank">Peter Williams</a></span><br>
<span style="font-family:Calibri,sans-serif;font-size:11pt;font-weight:bold">Cc:
</span><span style="font-family:Calibri,sans-serif;font-size:11pt"><a href="mailto:openid-general@lists.openid.net" target="_blank">openid-general@lists.openid.net</a></span><br>
<span style="font-family:Calibri,sans-serif;font-size:11pt;font-weight:bold">Subject:
</span><span style="font-family:Calibri,sans-serif;font-size:11pt">Re: [OpenID] OIDC federation using ID Tokens as OAuth2 grants</span><br>
<br>
</div><div><div class="h5">
<div>
<div dir="ltr">
<div>
<div>
<div>Hmm, that's interesting. A few things that I spotted as a little different:<br>
<br>
</div>
* The issuer and subject are the same<br>
</div>
* The issuer is not a URL as with ID Tokens. (Does this hint that it's self-signed by the client? And if an OIDC Provider were to implement this, it would hypothetically be the URL?)<br>
</div>
* The audience is a URL, and not an OAuth2 client_id<br>
<br>
<div>
<div>
<div>
<div>Maybe I skipped something in reading the draft, but <a href="https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-12#section-3.2" target="_blank">
section 3.2</a> is pretty vague and doesn't specify how the client credentials token should be constructed.<br>
<br>
</div>
<div>Good find though Peter!<br>
<br>
</div>
<div>--Cal<br clear="all">
</div>
<div>
<div>
<div><br>
<a href="mailto:cal@fbsdata.com" target="_blank"></a></div>
</div>
<br>
<div>On Wed, Apr 22, 2015 at 11:34 AM, Peter Williams <span dir="ltr">
<<a href="mailto:home_pw@msn.com" target="_blank">home_pw@msn.com</a>></span> wrote:<br>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>
<div style="font-family:Calibri,sans-serif;font-size:11pt"><a href="http://www.cloudidentity.com/blog/2015/02/06/requesting-an-aad-token-with-a-certificate-without-adal/" target="_blank">http://www.cloudidentity.com/blog/2015/02/06/requesting-an-aad-token-with-a-certificate-without-adal/</a><br>
<br>
Someone posted google related info. Here is some that doesn't require one to use vendor specific libraries.<br>
<br>
Sign a jwt you construct, and attach a cert to help the std verify the signature. Present the signed blob as a bearer, seeking ti have the std swap it for azure signed blob. Azure will then send suitable logging information (to NSA as part of fedramp) to a
cybersecututy scanning firm looking for pattern based signatures.<br>
<br>
The last part is not well known. I've no doubt google has the same "added value", as does yahoo and salesforce. It's all voluntary, note.<span><br>
<br>
Sent from my Windows Phone</span></div>
</div>
<div dir="ltr">
<hr>
<span><span style="font-family:Calibri,sans-serif;font-size:11pt;font-weight:bold">From:
</span><span style="font-family:Calibri,sans-serif;font-size:11pt"><a href="mailto:cal@fbsdata.com" target="_blank">Cal Heldenbrand</a></span><br>
<span style="font-family:Calibri,sans-serif;font-size:11pt;font-weight:bold">Sent:
</span><span style="font-family:Calibri,sans-serif;font-size:11pt">4/15/2015 12:11 PM</span><br>
<span style="font-family:Calibri,sans-serif;font-size:11pt;font-weight:bold">To:
</span><span style="font-family:Calibri,sans-serif;font-size:11pt"><a href="mailto:openid-general@lists.openid.net" target="_blank">openid-general@lists.openid.net</a></span><br>
<span style="font-family:Calibri,sans-serif;font-size:11pt;font-weight:bold">Subject:
</span><span style="font-family:Calibri,sans-serif;font-size:11pt">[OpenID] OIDC federation using ID Tokens as OAuth2 grants</span><br>
<br>
</span></div>
<span>
<div>
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>Hi everyone,<br>
<br>
</div>
I've been doing a lot of reading on OpenID Connect, and there's one area that I'm a little confused on -- federated identities. My curiosity was piqued from
<a href="https://books.google.com/books?id=_-BPBAAAQBAJ&pg=PA225&lpg=PA225#v=onepage&q&f=false" target="_blank">
Page 225 of the book Advanced API Security</a>. In particular, this quote: <i><br>
<br>
...you need to find a way to exchange the ID token received in OpenID Connect authentication for an OAuth access token, which is defined in the JWT grant types for the OAuth 2.0 specification. Once the web application receives the ID token ... it has to exchange
it for an access token by talking to the OAuth authorization server. The authorization server must trust the OpenID Connect identity provider.</i><br>
<br>
</div>
I realize this is a grey area between OIDC and OAuth2... but are there any spec documents that outline this trust relationship, and how it applies to ID Tokens in particular? (Also, are there any known implementations out there that actually use this?)<br>
<br>
</div>
I've read through the <a href="https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-12" target="_blank">
draft-ietf-oauth-jwt-bearer </a>document, and it seems very close to what I was looking for. But the JWT format is a little different from an ID Token, and the audience is not in the format of a typical client_id. And, I was assuming Authorized Party (azp)
would somehow fit into this flow.<br>
<br>
</div>
Any extra info on this would be very helpful!<br>
<br>
</div>
Thank you,<br>
<br>
</div>
--Cal<br>
<div>
<div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</span></div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div></div></div>
</blockquote></div><br></div></div></div></div></div>