[OpenID] OIDC federation using ID Tokens as OAuth2 grants

[Cal Heldenbrand]

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.

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!

--Cal


On Wed, Apr 22, 2015 at 2:20 PM, Peter Williams <home_pw at msn.com> wrote:

>  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.
>
> Swapping some beater object verified wrt an idtojen is fine.
>
> 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).
>
> Swapping a saml assertion, similarly, I find dubious. It's all very hacky.
>
>
>
>
>
> Sent from my Windows Phone
>  ------------------------------
> From: Cal Heldenbrand <cal at fbsdata.com>
> Sent: ‎4/‎22/‎2015 11:47 AM
> To: Peter Williams <home_pw at msn.com>
> Cc: openid-general at lists.openid.net
> Subject: Re: [OpenID] OIDC federation using ID Tokens as OAuth2 grants
>
>    Hmm, that's interesting.  A few things that I spotted as a little
> different:
>
>  * The issuer and subject are the same
>  * 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?)
>  * The audience is a URL, and not an OAuth2 client_id
>
>   Maybe I skipped something in reading the draft, but section 3.2
> <https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-12#section-3.2>
> is pretty vague and doesn't specify how the client credentials token should
> be constructed.
>
>  Good find though Peter!
>
>  --Cal
>
>  <cal at fbsdata.com>
>
> On Wed, Apr 22, 2015 at 11:34 AM, Peter Williams <home_pw at msn.com> wrote:
>
>
> http://www.cloudidentity.com/blog/2015/02/06/requesting-an-aad-token-with-a-certificate-without-adal/
>
> Someone posted google related info. Here is some that doesn't require one
> to use vendor specific libraries.
>
> 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.
>
> 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.
>
> Sent from my Windows Phone
>  ------------------------------
> From: Cal Heldenbrand <cal at fbsdata.com>
> Sent: ‎4/‎15/‎2015 12:11 PM
> To: openid-general at lists.openid.net
> Subject: [OpenID] OIDC federation using ID Tokens as OAuth2 grants
>
>      Hi everyone,
>
>  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 Page 225 of the book Advanced API Security
> <https://books.google.com/books?id=_-BPBAAAQBAJ&pg=PA225&lpg=PA225#v=onepage&q&f=false>.
> In particular, this quote:
>
> * ...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 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?)
>
>  I've read through the draft-ietf-oauth-jwt-bearer
> <https://tools.ietf.org/html/draft-ietf-oauth-jwt-bearer-12>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.
>
>  Any extra info on this would be very helpful!
>
>  Thank you,
>
>  --Cal
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20150423/39642797/attachment.html>