[OpenID] OIDC federation using ID Tokens as OAuth2 grants

[Peter Williams]

I think that  is somewhat of an edge case, that allows old and new to meet, and lower impedance mismatch between libs, vendors, offerings and security architecture.

I'm going with the simple case. Ask for code and id, the former inducing an access token suitable for calling API or accessing server side credential/token store for use when mobile sites supporting device apps pass several API guards, each with different  token sets

Yes I know there are now 14 more edge case flows. Like x509 turned into pki bloat as things professionalized, so has oauth. Stay focused on core. For this year.



Sent from my Windows Phone
________________________________
From: Cal Heldenbrand<mailto:cal at fbsdata.com>
Sent: ‎4/‎15/‎2015 12:11 PM
To: openid-general at lists.openid.net<mailto: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/20150415/ad89c439/attachment.html>
-------------- next part --------------
_______________________________________________
general mailing list
general at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general