Hi Adam, 3 is the most common today. In the Salesforce case it has the additional benefit that when Domain 1 is federating to SalesForce via OpenID Connect it can provide access tokens for it's API to sales force scoped for that user for use in the SalesForce custom logic.
1 and 2 are similar and likely it is more of a deployment choice between them. We do see examples of this currently with the Android play store providing third-party id_tokens/JWT assertions to OAuth clients. The reason for doing 1 or 2 vs 3 probably comes down to connivence and security if there is an agent for the user's IdP on the device that can act as a confidential client to the IdP for security and provide a more consistent UI for the user. That is what we are working on in the NAPPS WG at OIDF. We have examples of 1/2 now, the problem is that they are not as universally applicable as 3 but hopefully with standardization for developers we will se more in the next year or so. John B. On Mar 27, 2014, at 10:06 AM, Lewis Adam-CAL022 <adam.le...@motorolasolutions.com> wrote: > I am curious it ping the thoughts of others on the list of how OAuth is going > to continue to mature, especially with respect to enterprise federation > scenarios. This is something that I spend a whole lot of time thinking > about. Specifically, consider the following use case: > > An end user in domain 1 downloads a native application to access an API > exposed by domain 2, to access a protected resource in domain 2, under the > administrative control of the domain 2 enterprise. > > > There are in my mind three basic means by which OAuth can federate, which I > know I have discussed with some of you in the past: > > 1. First option … End user in domain 1 requests a JWT-structured > access_token from the OAuth provider in domain 1, and sends it in the HTTP > header directly to the RS in domain 2. The JWT access_token looks a whole > lot like a OIDC id_token (maybe it even is one?). The RS in domain 2 is able > to make attributed-based access control decisions based on the contents of > the JWT. This is architecturally the simplest approach, but enterprises > aren’t exactly setting up OAuth providers these days for the intent of > accessing protected resources in foreign domains. Anybody think this might > be the case 5 years from now? > > 2. Second option … similar to the first, but the JWT-structured > access_token from domain 1 is sent to the OAuth provider in domain 2, ala the > JWT assertion profile. Domain 1 access token is exchanged for a domain 2 > access token, and the native client uses the domain 2 access token to send to > the protected resource in domain 2. I like this slightly more than the first > option, because the resources servers in domain 2 only need to understand the > token format of their own AS. But it still suffers from the same basic > challenge of option 1, that enterprises don’t’ setup OAuth providers today > for the purpose of federating, the way that setup SAML providers for WebSSO. > > 3. Third option. Native client contacts the OAuth provider in domain 2 > directly. The authorization endpoint is federation enabled (NASCAR or other) > and the user in domain 1 selects their home IdP (SAML or OIDC) and does > WebSSO to federated into the domain 2 OAuth provider. I believe this is the > model that Salesforce supports today, and it the most tactical, since > enterprise that want to federate today run out and buy a SAML provider. > > So option 3 is the most obvious approach today. Does anybody foresee > enterprises setting up an STS in the future to federate to foreign RS’s (the > way they setup SAML providers today)? Anybody think we will see options 1 or > 2 in the future? > > > adam > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
