<div dir="ltr">Thank you for the info John!<br><div class="gmail_extra"><br clear="all">
<br><div class="gmail_quote">On Wed, Apr 15, 2015 at 3:14 PM, John Bradley <span dir="ltr"><<a href="mailto:ve7jtb@ve7jtb.com" target="_blank">ve7jtb@ve7jtb.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Google is the main user of this at the moment. <div><a href="https://developers.google.com/identity/protocols/CrossClientAuth" target="_blank">https://developers.google.com/identity/protocols/CrossClientAuth</a></div><div><br></div><div>They are using structured scopes to indicate the required audience.  It is something we allowed for in Connect  by adding the “azp” claim, but have not standardized yet.</div><div><br></div><div>There is work ongoing in the NAPPS WG looking at how enterprise AS can authorize SaaS applications to access 3rd party backend servers.<br><div><br></div><div>The book you point to leaves out how the audience would be correct.  Taking a id_token with an audience of “A"  and passing it on to "B" is not a good practice.</div><div><br></div><div>I know SalesForce supports the SAML and JWT assertion flows.</div><div><a href="https://help.salesforce.com/HTViewHelpDoc?id=remoteaccess_oauth_jwt_flow.htm" target="_blank">https://help.salesforce.com/HTViewHelpDoc?id=remoteaccess_oauth_jwt_flow.htm</a></div><div><br></div><div>John B.</div><div><br><div><blockquote type="cite"><div><div class="h5"><div>On Apr 15, 2015, at 4:11 PM, Cal Heldenbrand <<a href="mailto:cal@fbsdata.com" target="_blank">cal@fbsdata.com</a>> wrote:</div><br></div></div><div><div><div class="h5"><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></div>
_______________________________________________<br>general mailing list<br><a href="mailto:general@lists.openid.net" target="_blank">general@lists.openid.net</a><br><a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br></div></blockquote></div><br></div></div></div></blockquote></div><br></div></div>