Re: [OAUTH-WG] OAuth & Enteprise federation ... 5 years from now

Paul Madsen <> Thu, 27 March 2014 13:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D92741A00F8 for <>; Thu, 27 Mar 2014 06:29:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q1G_NquW_jqm for <>; Thu, 27 Mar 2014 06:29:53 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::22a]) by (Postfix) with ESMTP id CF9D51A00B4 for <>; Thu, 27 Mar 2014 06:29:52 -0700 (PDT)
Received: by with SMTP id uq10so1457731igb.3 for <>; Thu, 27 Mar 2014 06:29:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=kVjWvD1aM6Dj0/JziMamIsMhh9CU0TOsnjzZggqnYx8=; b=I7StJCjknzTALhnmJfeqEiv/qicd6k4VDUgynkHozYcQAYGOgy+CivKv35i8ZL395w vMvnq1VmQa9LOGBfo4P/4SFR92+XhoxPCQ9lO/olYkaeapMdjFHEOFwxUHLGCkiCCuoZ VcQi3kAlduNjTI89DuKGzxyneu5nLCWraldyBbyIMt4mMMW26UeZc6t5G+wQXpfP4tc8 nudbu/h2Csp9v0zmYSP4cYCaPnpSi0dpm4o7kxHlYgC0Qx6HSEfpEbJMqhcLJYIsJQSh QFmYiqlaJSpBHUyOFRzPEG5H5lqTvxk/7M9535oUrCQKe6sfhm3kQuPnT4zI2/ySXX5F sDCA==
X-Received: by with SMTP id wx14mr1853342icb.43.1395926990921; Thu, 27 Mar 2014 06:29:50 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id bf7sm5307107igb.9.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Mar 2014 06:29:50 -0700 (PDT)
Message-ID: <>
Date: Thu, 27 Mar 2014 09:29:48 -0400
From: Paul Madsen <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Lewis Adam-CAL022 <>, "" <>
References: <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------070002090302070101080009"
Subject: Re: [OAUTH-WG] OAuth & Enteprise federation ... 5 years from now
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Mar 2014 13:29:56 -0000

Hi Adam, we are confronting this issue in the NAPPS effort and are 
exploring a model that resembles your Option 2

The Token Agent (TA) obtains an id-token from the first AS1, this 
targetted at the second AS2 (the one local to the target RS). The TA 
then exchanges that id_token at AS2 for an access token that the RS will 
be able to validate

Option 3 is indeed today's default for layering federation onto OAuth


On 3/27/14, 9:06 AM, Lewis Adam-CAL022 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