Re: [OAUTH-WG] Building on the protocol in the draft "OAuth 2.0 Token Exchange: An STS for the REST of Us" to include Authentication Tokens

[John Bradley <[e-mail]>]

For people using RFC 7521, 7522, 7523 they are taking an assertion and using a WS-* STS to transform it into one with the correct audience to use  in 7521.

I know that some people have just ignored the audience,  however that can have negative security consequences.  When exchanging the token you want to be certain that it is the entity that the token was issued to that is exchanging it.

The STS for the rest of us is a more general framework that should allow you to take a id_token or SAML assertion and securely exchange it for another assertion or access token.

I don’t understand the use case enough to say if that is the best thing for you, but yes that is the intent of that spec.

John B.

> On Apr 20, 2016, at 10:58 AM, Fregly, Andrew <[e-mail]> wrote:
> 
> Thank you again of your input Nat. 
> 
> First of all, I apologize for confusing the situation by referencing the wrong RFCs in a prior email. I transposed two digits. The RFCs I meant to reference where 7521-7523 (see below).
> 
> I get that the original RFC for OAuth has the mechanism for client authentication being out of scope.  What is muddying the water for me is that RFCs 7521, 7522, and 7523 seem to specify the means by which a client can provide an authentication token to an Authorization Service. This purpose is stated at the top of the abstract for RFC 7521:
> 
> "The intent of this specification is to provide a common framework for OAuth 2.0 to interwork with other identity systems using assertions and to provide alternative client authentication mechanisms.”
> 
> In our use case, we need to have users authenticated against identity providers that organizations use internally as the means for authenticating clients accessing our service. We need this because we believe this is the best means for proving a user is still a member of an organization at the time they authenticate. Most, perhaps all of these organizations, will internally use an Identity Provider that provides SAML authentication assertions. This led me to looking for a way to use authentication tokens produced by internal Identity Providers as a means for proving a client had been authenticated by the organization. A bit of investigation in how this might be done led me to OAuth RFCs 7521, 7522 and 7523. They  almost get me there. They specify what needs to be in an Authentication token that is given by a client to an Authorization Service. The gotcha was that these RFCs require an audience claim in the authentication token. This audience claim is used to identify the specific Authorization Service the token is meant for. For this audience claim to get filled in by some arbitrary organization’s Identity Provider, it seems the Identity Provider will need to be told who the Authorization Service is by the client initiating the authentication. I have therefore been looking for a standard that specifies how a client can tell the Identity Provider the identity of the Authorization Service. I was stuck for a bit on how the IETF OAuth working group could address this issue since authentication seemed to be out of scope for the group. Then I found the  IETF draft "OAuth 2.0 Token Exchange: An STS for the REST of Us”. It defines a mechanism for telling a Security Token Service the audience for the token it is being asked to issue. I thought that would solve my problem since an intent of the draft seemed to be on generalizing the described approach to any type of Security Token Service. There was one gotcha in the draft though. It limited the type of STS to which the protocol applied to be just Authorization Services. For my use case, I needed the capability described in the draft, but applicable to Identity Providers too. If it were applicable to Identity Providers, there would then be a full set of existing RFCs and drafts that covered the functionality needed for our use case. 
> 
> There are a couple of possible actions that I have been contemplating relative to OAuth:
> Write extensions to RFCs 7521, 7522 and 7523 that eliminate the need for an audience claim in the authentication token if the Authorization Service has a trust relationship with the Identity Provider that issued the authentication token.
> Ask the authors of the “OAuth 2.0 Token Exchange: An STS for the REST of Us” to explicitly state that the the approach described there-in is applicable to both Identity Providers and Authorization services.
> Before doing either of these steps, I want to make sure that I am not missing something in existing RFCs and drafts that would address our use case. I have only been looking at this issue for a few weeks, so I thought it would be best to go to the experts to get advice. This led to this email chain. 
> 
> Thanks to all following this chain for your time and consideration on this!
> 
> Andy
> 
> From: Nat Sakimura <[e-mail] <mailto:[e-mail]>>
> Date: Tuesday, April 19, 2016 at 5:35 PM
> To: Andrew Fregly <[e-mail] <mailto:[e-mail]>>, John Bradley <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [OAUTH-WG] Building on the protocol in the draft "OAuth 2.0 Token Exchange: An STS for the REST of Us" to include Authentication Tokens
> 
>> Hi Andrew, 
>> 
>> In OAuth 2.0, the resource owner authentication /end user authentication is out of scope. What it deals with is "client authentication". They should not be mixed up. There is no end user identity nor authentication token in the OAuth. You cannot do end user authentication with pure OAuth. For that, you have to rely on something like OpenID Connect. 
>> 
>> As John noted, it is perfectly fine to chain the external authentication and the internal authorization. It is often done. It is just that the RFC6749 Authz server is an RP of OpenID Connect or SP of SAML. Nothing precludes it. 
>> 
>> If you really want to avoid the front channel re-auth with prompt=none, which is more secure and proper ways to do, but just to make sure that the user still exists in the authentication service, you can infer it by making a userinfo request to the userinfo endpoint of OpenID Connect. It would fail in various reasons, but would certainly fail if the user does not exist anymore. Other error conditions like the user revoked the access/refresh token etc. would cause the same invalid_token error though. 
>> 
>> Best, 
>> 
>> Nat
>> 
>> P.S. I do not see why the RFCs you sited are relevant here. I guess you are talking about RFC7521-7523 ;-)
>> 
>> RFC7251 AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS
>> RFC7252 The Constrained Application Protocol (CoAP)
>> RFC7253 The OCB Authenticated-Encryption Algorithm
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 2016年4月20日(水) 5:34 Fregly, Andrew <[e-mail] <mailto:[e-mail]>>:
>>> Thanks for your reply Nat.
>>> 
>>> Does your approach match with an IETF OAuth RFC or Draft describing how an Authorization Service can accept and verify an authentication token provided by a client during the authorization process? If so, please point me to that. The only RFCs I have seen  that address this are RFCs 7251, 7252 and 7253, and they all have a requirement that an “audience” claim corresponding to the Authorization Service is in the authentication token. Getting that claim into an authentication token provided by an Organization’s Identity provider seems to be my fundamental problem.
>>> 
>>> Thanks,
>>>       Andy
>>> 
>>> From: Nat Sakimura <[e-mail] <mailto:[e-mail]>>
>>> Date: Tuesday, April 19, 2016 at 4:13 PM
>>> To: Andrew Fregly <[e-mail] <mailto:[e-mail]>>, John Bradley <[e-mail] <mailto:[e-mail]>>, "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
>>> 
>>> Subject: Re: [OAUTH-WG] Building on the protocol in the draft "OAuth 2.0 Token Exchange: An STS for the REST of Us" to include Authentication Tokens
>>> 
>>>> Get OpenID Connect id_token by the authentication request with prompt=none and verifying the sub to be the same with what you expected seem to suffice your needs. Am I missing something? 
>>>> On Wed, Apr 20, 2016 at 05:05 Fregly, Andrew <[e-mail] <mailto:[e-mail]>> wrote:
>>>>> Thanks for your response John. I also got a good response from Brian Campbell and appreciate that. I will respond separately to Brian’s response as I think it would keep things clearer to do that.
>>>>> 
>>>>> The problem we have for using OpenID Connect is that it combines the role of Authentication Service with the role of Authorization Service. Perhaps the following description of what we want to do will clarify why this won’t work for us:
>>>>> 
>>>>> The basic problem statement is that we need to have a client application authorized by a Service Provider based on proof that a user is currently a member of some organization. This assumes the organization has previously established some level of authorized access with the Service Provider. 
>>>>> 
>>>>> Here is an example: Suppose I am a member of SomeOrg Inc. Suppose SomeOrg Inc. is doing research that requires it to gather data over the Internet from a number of data providers. The data providers require authentication and proof of organizational membership in order to authorize various levels of access to their data. The data providers do not consider having an account with them or a Public Identity Provider to be suitable for proving that I am still a member of SomeOrg at time of authentication. They would have no way of knowing whether or not my relationship with SomeOrg still exists at that time. The data providers would therefore like the Client software to authenticate me against SomeOrgs Identity Provider. This would be good proof that I am still a member of SomeOrg at the time I authenticate. This authentication would enable the data providers Authorization Server to grant me access appropriate to a member of SomeOrg.  Note that as a prerequisite to all of this, SomeOrg will have used an out-of-band process to set up a trust relationship for SomeOrg's Identity Provider with the data provider’s Authorization Service, and will have negotiated authorization claims to be granted to SomeOrgs members.
>>>>> 
>>>>> What I am having difficulty with is in knitting together an approach based on the he OpenID Connect specifications, SAML specifications, and OAuth RFCs and drafts in a way that supports the above use case end-to-end. The OAuth RFCs and drafts almost get me there. What seems to be missing is a way of telling an Identity Provider the URL for the Authorization Service (the required Audience claim in an authentication assertion as defined in RFCs 7251, 7252 and 7253), and then a requirement that the Identity Providers put the supplied Audience Identifier into Authentication Tokens. Perhaps a little further back-and-forth with Brian will resolve this.
>>>>> 
>>>>> I can go into deeper detail if needed. If this is off-topic for the OAuth working group, let me know.
>>>>> 
>>>>> Thanks,
>>>>> Andrew Fregly
>>>>> Verisign Inc.
>>>>> 
>>>>> 
>>>>> From: John Bradley <[e-mail] <mailto:[e-mail]>>
>>>>> Date: Tuesday, April 19, 2016 at 2:06 PM
>>>>> To: Andrew Fregly <[e-mail] <mailto:[e-mail]>>
>>>>> Cc: "[e-mail] <mailto:[e-mail]>" <[e-mail] <mailto:[e-mail]>>
>>>>> Subject: Re: [OAUTH-WG] Building on the protocol in the draft “OAuth 2.0 Token Exchange: An STS for the REST of Us” to include Authentication Tokens
>>>>> 
>>>>>> Looking at OpenID Connect and it’s trust model for producing id_tokens that assert identity may help you.
>>>>>> http://openid.net/wg/connect/ <http://openid.net/wg/connect/>
>>>>>> 
>>>>>> Unfortunately I can’t quite make out what you are trying to do. 
>>>>>> 
>>>>>> It sort of sounds like you want an id_token from a idP and then have the client exchange that assertion for another token?
>>>>>> 
>>>>>> John B.
>>>>>>> On Apr 19, 2016, at 1:18 PM, Fregly, Andrew <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>>> 
>>>>>>> I have a use case where a client application needs to authenticate with a dynamically determined Identity Provider that is separate from the Authorization Service that will be used issue an access token to the client. The use case also requires that as part of authorization, the client provides to the Authorization Service an authentication token signed by an Identity Provider that the Authorization Service has a trust relationship with. The trust relationship is verifiable based on the Authorization Service having recorded the public keys or certificates of trusted Identity Providers in a trust store, this allowing the Authorization Service to verify an Identity Provider’s signature on an authentication token. <>
>>>>>>>  
>>>>>>> In looking at the various OAuth RFCs, particularly RFCs 7521, 7522, and 7523, I see that they get me close in terms of supporting the use case. What is missing is a means for solving the following problem. These RFCs require that the Identity Provider put an Audience claim in the authentication token. The problem with this is that I do not see in the RFCs how the Identity Provider can be told who the Audience is to put into the authentication token. This leads me to the title of this message. The draft “OAuth 2.0 Token Exchange: An STS for the REST of Us” defines a mechanism for identifying the Audience for an STS to put into a token it generates. That would solve my problem except that the draft limits the type of STS to being Authorization Servers. What is needed is this same capability for interacting with an Identity Provider. This would enable RFCs 7521, 7522 and 7523 to be useful in situation where the Identity Provider needs to be told the identity of the Authorization Service.
>>>>>>>  
>>>>>>> I am new to interacting with the IETF. I also am not an expert on the RFCs or prior history of the OAuth group relative to this topic, so please point me to any existing solution if this is a solved problem. Otherwise, I would like to get feedback on my suggestion.
>>>>>>>  
>>>>>>> Thanks You,
>>>>>>> 
>>>>>>> Andrew Fregly
>>>>>>> Verisign Inc.
>>>>>>> _______________________________________________
>>>>>>> OAuth mailing list
>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>