Re: [OAUTH-WG] [token-exchange] Parameters to support external token exchange

[Bill Burke <[e-mail]>]

How the target STS processes the external token is up to the STS.  The
external token could solely be used as an authentication mechanism.
The client must be registered and known by the STS, so it can decide
if the client is allowed to exchange an external token, and what
target audience or resource the client is allowed to ask for.  At
least this is how it works in our implementation.  With Facebook
token, the STS knows that it is a Facebook token and was obtained to
access Facebook APIs.  I don't see the vulnerabilites right now as
much different than an internal exchange or bearer token invocations.
 Clients need to be aware that they should downgrade tokens before
passing them to less trusted target endpoints.

On Mon, Dec 11, 2017 at 6:23 PM, Brian Campbell
<[e-mail]> wrote:
> The words implicit vs. explicit might not have been the best choice but the
> concepts are complicated and subtle and I was (and still am) at a bit of a
> lose for the right language to describe things.
>
> By explicit what I was trying to express is that the token that is going
> cross-domain is explicitly intended for that purpose and includes things
> like an audience restriction that reflect that intention. The OpenID Connect
> ID Token is an example of that for browser based flows and the RFC 7523 JWT
> authorization grant is an example for non-browser flows.
>
> By implicit what I was trying to express are situations where a token that
> issued for a particular purpose (like a Facebook access token for access to
> Facebook APIs) is used implicitly for a different purpose (like getting a
> different access token for access to APIs in a different domain).
>
>
>
> On Fri, Dec 8, 2017 at 2:29 PM, Bill Burke <[e-mail]> wrote:
>>
>> On Fri, Dec 8, 2017 at 12:41 PM, Brian Campbell
>> <[e-mail]> wrote:
>> > I guess I'm going to kind of restate some of what I said in that earlier
>> > thread and a bit more. The access and refresh token URIs from the draft
>> > are
>> > intended to indicate that such tokens are issued by the given
>> > authorization
>> > server acting as the STS (perhaps this could be stated more clearly in
>> > the
>> > doc). As such, there isn't direct explicit support for OAuth access
>> > token to
>> > OAuth access token cross-domain type exchanges. That was intentional and
>> > I
>> > think is appropriate as I don't believe this draft should delve into
>> > pseudo
>> > federating access tokens and all the additional complexity and security
>> > implications that entails.
>>
>> I'll look in my email archives again, but, I wasn't convinced then
>> that there is all this additional complexity.
>>
>> > The assertion based authorization grants (RFCs
>> > 7523 & 7522) are intended to facilitate acquiring an access token from
>> > an
>> > external or cross-domain AS and I prefer that more explicit model for
>> > cross-domain than codifying a rather implicit way of doing it in token
>> > exchange.
>>
>> Not understanding what you mean by implicit vs. explicit.  I don't see
>> how what we've implemented is any more implicit than the current
>> specification.  If anything, I thought our impl was more explicit as
>> you can't derive the issuer from an opaque access token in the current
>> spec.
>>
>>
>> > A Facebook access token, for example, is issued to a client for
>> > delegated access to Facebook APIs. It isn't for delegated access to some
>> > other domain's APIs but an access token for access token exchange
>> > effectively turns it into that. And in some situations that can have
>> > problematic security implications.
>>
>> Internet applications trust Facebook, Google, whoever to identity and
>> authenticate users all the time and to grant access and permission
>> based on that identity.  An external exchange is just a non-browser
>> mechanism to facilitate this relationship.  For our IDP, our userbase
>> often use us as a broker between the various social websites and their
>> apps.  This way, apps don't care where the user was authenticated
>> from, they just see open id connect with a token format and domain
>> they control.  Developers often have apps that they are not able to
>> change how a user logs in or cannot unify their apps with a common
>> STS, token format, or even protocol.  Yet they still have a need to
>> make secure invocations across these domains and apps.
>>
>> > Big providers like Facebook have a lot of
>> > apps (OAuth clients) that can get access tokens. An organization might
>> > well
>> > be okay with an app it controls exchanging a Facebook access token for
>> > an
>> > access token for its own APIs. But a 3rd party Facebook app (like maybe
>> > a
>> > new viral rate my '80's hairdo app) doing the same thing could be very
>> > problematic. It's not exactly the same thing but many of the same
>> > potential
>> > issues arise as when using OAuth for User Authentication.
>> > Standardization
>> > around access token for access token exchange would, at a minimum, need
>> > some
>> > real security analysis and recommendations/considerations.
>> >
>> > The token exchange draft went thought WGLC some time ago and is
>> > currently
>> > being written up by the document shepherd to send to the AD. It's close.
>> > It's been a long time coming and I'd really object to derailing it by
>> > making
>> > big additions to it at this late stage in the process.
>> >
>>
>> That's fair enough.  I didn't know how far in the process the token
>> exchange draft was.  In the least, I wanted to make the WG aware of
>> our work.  We have a decent and growing user base with a problem
>> looking for a solution and we're going to get a lot of feedback on
>> what we've implemented.   At least from our open source project
>> perspective, there's a lot more interest in external exchange than
>> internal.  Which is why I'm posting this.
>>
>>
>> --
>> Bill Burke
>> Red Hat
>
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
> material for the sole use of the intended recipient(s). Any review, use,
> distribution or disclosure by others is strictly prohibited.  If you have
> received this communication in error, please notify the sender immediately
> by e-mail and delete the message and any file attachments from your
> computer. Thank you.



-- 
Bill Burke
Red Hat