From nobody Tue Jan 3 08:52:27 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 538A412968E for ; Tue, 3 Jan 2017 08:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vthmuUVS0nal for ; Tue, 3 Jan 2017 08:52:23 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CF1112965A for ; Tue, 3 Jan 2017 08:52:23 -0800 (PST) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id 2676D7803DC for ; Tue, 3 Jan 2017 17:52:20 +0100 (CET) To: oauth@ietf.org References: From: Denis Message-ID: Date: Tue, 3 Jan 2017 17:52:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------105FC74356C43C7F3AEF10A8" Archived-At: Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-jwsreq X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 16:52:26 -0000 This is a multi-part message in MIME format. --------------105FC74356C43C7F3AEF10A8 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hello, I have only recently subscribed to this mailing list and hence I was not present when the WGLC was launched on this document. I have several concerns and comments about this draft : *1°. The draft will be unable to move to Draft Standard* The Intended status of draft-ietf-oauth-jwsreq is Standards Track. RFC 5657 states: Advancing a protocol to Draft Standard requires documentation of the *interoperation *and implementation *o**f the protocol.* The goal of RFC standard Track document is define *interoperable protocols, *hence not simply to define the syntax of a request leaving dozens of possibilities about the treatment of the parameters that may be included in the request to the AS. Generally speaking, the text is silent about the treatment of _every_ parameter of the JAR. In particular, what kind of verification and processing SHALL be done by the Authorization Server on "aud", since both "iss" and "aud" SHOULD be present (see page 6) in the Authorization Request. The document currently fails to *clearly indicate which parameters of the JAR are used by the Authorization Server to validate the JAR itself and which parameters are used to build the requested access token*. For example, is the "aud" parameter supposed to identify the AS or the RS ? This means that the text should be sufficiently clear so that two different implementations can interoperate. This will not be the case if the text stays like this. The goal of Standard Tracks RFCs is not to define frameworks but *interoperable protocols.* In addition to this major concern, I have other concerns: *2°. Security consideration: the Alice and Bob Collaboration attack (ABC attack)* Since the time RFC 6819 was written, a new kind of attack has been mentioned on the WG mailing list: the ABC attack (*Alice and Bob Collaboration attack*) where Bob accepts to collaborate with Alice to get an access token that Alice will then be able to use. There is no external attacker, but only two users who agree to collaborate to cheat an application server. It is a major problem typically when an access token only contains a claim like "older then 18". This kind of attack is not mentioned in this draft, nor if it can be countered in the context of RFC 6749 (OAuth 2.0 Authorization Framework). It would not be reasonable to consider the Alice and Bob Collaboration attack as being out of scope of the OAuth 2.0 Authorization Framework; or ... if it is, this should be clearly stated in the abstract and in the security considerations section. But in the later case, this would be as if a security hole would be left out of the scope of the OAuth 2.0 Authorization Framework. OAuth was designed from a perspective that there is a trust relationship between the AS and RS so that things like AT token format were left unspecified. This is a major design error. As long as the AT token format will be left unspecified, it will not be possible to counter the ABC attack. JAR is applicable to all kinds of OAuth authorization request. It is considered as just another kind of encoding instead of query parameters. In case query parameters are being transmitted within the URL, the ABC attack remains. So the ABC attack is not specific to this document only, but to all this series of documents. :-( Readers might think that the authentication of authorization requests solves one left opened security issue but in practice it does not. Hence, this document can mislead many readers. IMO, in order to counter the ABC attack it is first necessary to specify one or more token syntax and the trust relationships : -between the token requestor and the AS, -between the AS ands the RS, and -between the token requestor and the RS, The global security picture is governed by: -the two ways protocol between the token requestor and the AS, as well as the format the access token request and the processing of each of its parameters by the AS, -the construction of each of parameter of the access token by the AS, -the two ways protocol between the token requestor and the RS, as well as the format of the access token itself and the validation of each of its parameters by the RS, *3°.**Privacy consideration: Authorization Servers may be able to act as Big Brother* Section 11 (Privacy Considerations) does not contain text to explain that an Authorization Server might be able to act as Big Brother if it is able to know where each access token it issues will be used. The use of a audience parameter without any semantics in it should be recommended. Other people have already pointed it out. Basically, in this context, trust means that a user A trusts a server /_B for doing some actions C_/ (and not for any kind of action). Thus, a user A can trust a server B to provide him with a subset of his attributes in an access token but he does not necessarily trust that same server B to keep private the list of the servers where he will use this access token (if B would be in a position to know the identity of these resource servers). OpenID Connect is based on OAuth 2.0. OpenID Connect does either take into consideration this privacy issue. *4°. Minors issues (when compared to the others):* 1) The abstract states: While it is easy to implement, it means that (a) the communication through the user agents are not integrity protected and thus the parameters can be tainted, and (b) the source of the communication is not authenticated. (...) This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be JWS signed and/or JWE encrypted so that the integrity, source authentication and confidentiality property of the Authorization Request is attained. Since the main purpose is integrity protection and authentication, the JAR SHALL be signed and MAY be encrypted. Replace with: (...) which allows the request to be JAR to be signed and optionally encrypted (...) 2) On page 9 the text states: The authorization request object MUST be either (a) JWS signed; or (b) JWE encrypted; or (c) JWS signed and JWE encrypted. This should be replaced by: The authorization request object MUST be either (a) JWS signed; (b) JWE encrypted (when secret keys are being used); or (c) JWS signed and JWE encrypted. 4) On page 14, in section 6.3, the text states: the Authorization Server then validates the request as specified in OAuth 2.0 [RFC6749]. This is rather vague, since no specific section from RFC 6749 is being pointed at.RFC 6749 is a framework with many options. In the context of this draft, it would be beneficial to indicate which kind processing of the JAR parameters shall be done by the Authorization Server. This issue clearly relates to the first major issue: interoperability. Denis --------------105FC74356C43C7F3AEF10A8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hello,

 

I have only recently subscribed to this mailing list and hence I was not present when the WGLC was launched on this document.


I have several concerns and comments about this draft :


 

1°. The draft will be unable to move to Draft Standard

The Intended status of draft-ietf-oauth-jwsreq is Standards Track.

RFC 5657 states: Advancing a protocol to Draft Standard requires documentation of the interoperation and implementation of the protocol.

The goal of RFC standard Track document is define interoperable protocols, hence not simply to define the syntax of a request leaving
dozens of possibilities about the treatment of the parameters that may be included in the request to the AS.

Generally speaking, the text is silent about the treatment of every parameter of the JAR. In particular, what kind of verification and processing
SHALL be done by the Authorization Server on "aud", since both "iss" and "aud" SHOULD be present (see page 6) in the Authorization Request.

The document currently fails to clearly indicate which parameters of the JAR are used by the Authorization Server to validate the JAR itself
and which parameters are used to build the requested access token.

For example, is the "aud" parameter supposed to identify the AS or the RS ?

This means that the text should be sufficiently clear so that two different implementations can interoperate. This will not be the case if the text stays like this.

The goal of Standard Tracks RFCs is not to define frameworks but interoperable protocols.

 


In addition to this major concern, I have other concerns:

 

 

2°. Security consideration: the Alice and Bob Collaboration attack (ABC attack)

 

Since the time RFC 6819 was written, a new kind of attack has been mentioned on the WG mailing list:
the ABC attack (Alice and Bob Collaboration attack) where Bob accepts to collaborate with Alice to get an access token that Alice will then be able to use.

There is no external attacker, but only two users who agree to collaborate to cheat an application server.
It is a major problem typically when an access token only contains a claim like "older then 18".

This kind of attack is not mentioned in this draft, nor if it can be countered in the context of RFC 6749 (OAuth 2.0 Authorization Framework).

 

It would not be reasonable to consider the Alice and Bob Collaboration attack as being out of scope of the OAuth 2.0 Authorization Framework;
or ... if it is, this should be clearly stated in the abstract and in the security considerations section.


But in the later case, this would be as if a security hole would be left out of the scope of the OAuth 2.0 Authorization Framework.


OAuth was designed from a perspective that there is a trust relationship between the AS and RS so that things like AT token format were left unspecified.
This is a major design error. As long as the AT token format will be left unspecified, it will not be possible to counter the ABC attack.


JAR is applicable to all kinds of OAuth authorization request. It is considered as just another kind of encoding instead of query parameters.
In case query parameters are being transmitted within the URL, the ABC attack remains. So the ABC attack is not specific to this document only,
but to all this series of documents. :-(

 

Readers might think that the authentication of authorization requests solves one left opened security issue but in practice it does not.
Hence, this document can mislead many readers.

 

IMO, in order to counter the ABC attack it is first necessary to specify one or more token syntax and the trust relationships :

-          between the token requestor and the AS,

-          between the AS ands the RS, and

-          between the token requestor and the RS,

 

The global security picture is governed by:

-          the two ways protocol between the token requestor and the AS, as well as the format the access token request and the processing of each of its parameters by the AS,

-          the construction of each of parameter of the access token by the AS,

-          the two ways protocol between the token requestor and the RS, as well as the format of the access token itself and the validation of each of its parameters by the RS,

 

 

3°. Privacy consideration: Authorization Servers may be able to act as Big Brother

 

Section 11 (Privacy Considerations) does not contain text to explain that an Authorization Server might be able to act as Big Brother
if it is able to know where each access token it issues will be used. The use of a audience parameter without any semantics in it should be recommended.

 

Other people have already pointed it out.

 

Basically, in this context, trust means that a user A trusts a server B for doing some actions C (and not for any kind of action).
Thus, a user A can trust a server B to provide him with a subset of his attributes in an access token but he does not necessarily trust
that same server B to keep private the list of the servers where he will use this access token (if B would be in a position to know
the identity of these resource servers).

 

OpenID Connect is based on OAuth 2.0. OpenID Connect does either take into consideration this privacy issue.

 

 

4°. Minors issues (when compared to the others):

 

1) The abstract states:

While it is easy to implement, it means that (a) the communication through the user agents are not integrity protected

and thus the parameters can be tainted, and (b) the source of the communication is not authenticated. 

(...)

This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows

the request to be JWS signed and/or JWE encrypted so that the integrity, source authentication and confidentiality

property of the Authorization Request is attained.

 

Since the main purpose is integrity protection and authentication, the JAR SHALL be signed and MAY be encrypted.

Replace with:

(...) which allows the request to be JAR to be signed and optionally encrypted (...)

 

 

2) On page 9 the text states:

The authorization request object MUST be either

   (a)  JWS signed; or

   (b)  JWE encrypted; or

   (c)  JWS signed and JWE encrypted.

 

This should be replaced by:

The authorization request object MUST be either

   (a)  JWS signed;

   (b)  JWE encrypted (when secret keys are being used); or

   (c)  JWS signed and JWE encrypted.

 

4) On page 14, in section 6.3, the text states:

    the Authorization Server then validates the request as specified in OAuth 2.0 [RFC6749].


This is rather vague, since no specific section from RFC 6749 is being pointed at. RFC 6749 is a framework with many options.
In the context of this draft, it would be beneficial to indicate which kind processing of the JAR parameters shall be done by the Authorization Server.
This issue clearly relates to the first major issue: interoperability.

Denis



 --------------105FC74356C43C7F3AEF10A8-- From nobody Tue Jan 3 09:37:06 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01BA129A6A for ; Tue, 3 Jan 2017 09:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2AHjzNb21I9v for ; Tue, 3 Jan 2017 09:37:00 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11C161295F0 for ; Tue, 3 Jan 2017 09:37:00 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id u144so103921158wmu.1 for ; Tue, 03 Jan 2017 09:36:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ei2Brvlta+gBIR/4MgQfncQSJpmilYXO8nbPQXzy0xs=; b=SEuRM9OEQRiJ4lApDIbHP0ZiQTczNI7BvV1qvaeVeneYVYhzvPrWJfPcXGAK+uXoah a13GvDehxg48BvGabDIQxI3CKERFP7ZFwq2F95E9MVdDB3c+oH6MGeDHC078YiUrGTYn r1vbiDMPcN/0Hb7SkOskoWpw0TbR43Hd+g2pQPMf7kFU84THr1e7a4y9HTFF/jkCqD28 ybZgMEwAQVQ1FSfSn0qQ0r+uwusuNLJl9wwRNKFa0P5syZVStt9I3Qq/kf+8imGPTHbT bXDCOe7PkMxHGmCvs3LT6n8gRLVlVStuGaiYhHXewpEk65jMaBXwDecVymFb8O63iSCT a+ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ei2Brvlta+gBIR/4MgQfncQSJpmilYXO8nbPQXzy0xs=; b=htNOxYZuZLZyB4kiG7e78QJBOMe8IweqRMU3ljRMsoAjOzKIB7XhxdJa0K4PM4aOPX CWzIJn6HhcykFGY/VFrC5P9aNFN0UWgh3ck+Z9Xvo/xg/oXKQ4owSKGxDqtNCgW21U1Z yLIAGsEwD3fFqBBXHnZ5opyikcvMdZ3mEdYiG3rJLYN5pA/nNu6wDbo0cX8SZxLgpiK9 42ccF3dNXw9Vp3gYVjZ3Kz8DuUHlrbtUm+YY/pQJL1ru3vqpnLnC/sfwmq8HSOIxAPRl fn0aU1SZ4h8bRatg/HLqz+vYzDIPZvfYcrbcOaDCGZBDGzm4uduxQXIpRNLt/Xjdc1Hr q5+A== X-Gm-Message-State: AIkVDXI/Al8C1xbQqZvZDOpfWmgOCxqLrX7viArzzskahDZRL6DAxZFJqV++8AFNnvnVIY6jlrkqjwEKg50PvQ== X-Received: by 10.28.58.14 with SMTP id h14mr59277667wma.7.1483465018357; Tue, 03 Jan 2017 09:36:58 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nat Sakimura Date: Tue, 03 Jan 2017 17:36:46 +0000 Message-ID: To: Denis , oauth@ietf.org Content-Type: multipart/alternative; boundary=001a1148f6f274db060545341de0 Archived-At: Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-jwsreq X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 17:37:05 -0000 --001a1148f6f274db060545341de0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Comments inline: 2017=E5=B9=B41=E6=9C=884=E6=97=A5(=E6=B0=B4) 1:52 Denis : > Hello, > > > > I have only recently subscribed to this mailing list and hence I was not > present when the WGLC was launched on this document. > > > I have several concerns and comments about this draft : > > > > > *1=C2=B0. The draft will be unable to move to Draft Standard* > > The Intended status of draft-ietf-oauth-jwsreq is Standards Track. > > RFC 5657 states: Advancing a protocol to Draft Standard requires > documentation of the *interoperation *and implementation *o**f the > protocol.* > > The goal of RFC standard Track document is define *interoperable > protocols, *hence not simply to define the syntax of a request leaving > dozens of possibilities about the treatment of the parameters that may be > included in the request to the AS. > > Generally speaking, the text is silent about the treatment of *every* > parameter of the JAR. In particular, what kind of verification and > processing > > SHALL be done by the Authorization Server on "aud", since both "iss" and > "aud" SHOULD be present (see page 6) in the Authorization Request. > > The document currently fails to > *clearly indicate which parameters of the JAR are used by the > Authorization Server to validate the JAR itself and which parameters are > used to build the requested access token*. > > For example, is the "aud" parameter supposed to identify the AS or the RS= ? > > This means that the text should be sufficiently clear so that two > different implementations can interoperate. This will not be the case if > the text stays like this. > > The goal of Standard Tracks RFCs is not to define frameworks but *interop= erable > protocols.* > It is interoperabole, in so much as RFC6749 and RFC7515 is. > > > > In addition to this major concern, I have other concerns: > > > > > > *2=C2=B0. Security consideration: the Alice and Bob Collaboration attack = (ABC > attack)* > > > > Since the time RFC 6819 was written, a new kind of attack has been > mentioned on the WG mailing list: > the ABC attack (*Alice and Bob Collaboration attack*) where Bob accepts > to collaborate with Alice to get an access token that Alice will then be > able to use. > > There is no external attacker, but only two users who agree to collaborat= e > to cheat an application server. > It is a major problem typically when an access token only contains a clai= m > like "older then 18". > > This kind of attack is not mentioned in this draft, nor if it can be > countered in the context of RFC 6749 (OAuth 2.0 Authorization Framework). > > > > It would not be reasonable to consider the Alice and Bob Collaboration > attack as being out of scope of the OAuth 2.0 Authorization Framework; > or ... if it is, this should be clearly stated in the abstract and in the > security considerations section. > > > But in the later case, this would be as if a security hole would be left > out of the scope of the OAuth 2.0 Authorization Framework. > > > OAuth was designed from a perspective that there is a trust relationship > between the AS and RS so that things like AT token format were left > unspecified. > This is a major design error. As long as the AT token format will be left > unspecified, it will not be possible to counter the ABC attack. > I disagree. In OAuth, AS and RS has pre-defined relationship - they are tightly bound together and knows how to interpret/resolve the access token. Access token format is totally out of scope of OAuth. > > JAR is applicable to all kinds of OAuth authorization request. It is > considered as just another kind of encoding instead of query parameters. > Indeed it is. > In case query parameters are being transmitted within the URL, the ABC > attack remains. So the ABC attack is not specific to this document only, > but to all this series of documents. :-( > ABC attack is out of socpe for OAuth. It is not a new attack. The resource owner handing a bearer token to another party willfully is not a threat in the bearer token model. > > Readers might think that the authentication of authorization requests > solves one left opened security issue but in practice it does not. > Hence, this document can mislead many readers. > OAuth is not a federated authentication protocol. OAuth is not even a federated authorization protocol by itself. You need to build a profile upon it to do so. > > > IMO, in order to counter the ABC attack it is first necessary to specify > one or more token syntax and the trust relationships : > > - between the token requestor and the AS, > > - between the AS ands the RS, and > > - between the token requestor and the RS, > Sorry, but they are out of scope of this document as ABC attack is out of scope of RFC6749 and RFC6750. They can be dealt with in POP document but not this one. > > > The global security picture is governed by: > > - the two ways protocol between the token requestor and the AS, > as well as the format the access token request and the processing of each > of its parameters by the AS, > > - the construction of each of parameter of the access token by > the AS, > > - the two ways protocol between the token requestor and the RS, > as well as the format of the access token itself and the validation of ea= ch > of its parameters by the RS, > > > That depends on the security assumptions. You should challenge RFC6749 and not this document. This document merely provides another encoding for the authorization request so that the request can be integrity protected and source authenticated. > > > *3=C2=B0.* *Privacy consideration: Authorization Servers may be able to a= ct as > Big Brother* > > > > Section 11 (Privacy Considerations) does not contain text to explain that > an Authorization Server might be able to act as Big Brother > if it is able to know where each access token it issues will be used. The > use of a audience parameter without any semantics in it should be > recommended. > > > > Other people have already pointed it out. > > > > Basically, in this context, trust means that a user A trusts a server *B > for doing some actions C* (and not for any kind of action). > Thus, a user A can trust a server B to provide him with a subset of his > attributes in an access token but he does not necessarily trust > There is no notion of "his attributes" in OAuth. You seem to be conflating general OAuth framework with some kind of identity protocols. > that same server B to keep private the list of the servers where he will > use this access token (if B would be in a position to know > the identity of these resource servers). > Big Brother or "calling home problem" is very well known, but as I have pointed out earlier, in OAuth, the authorization server and resource servers are tightly bound together, so it is not a problem. In this kind of model, if you cannot trust your authorization server, you had better stop using it altogether instead of asking for "better privacy". The consequence of using an untrusted authorization server is much more grave. > > OpenID Connect is based on OAuth 2.0. OpenID Connect does either take int= o > consideration this privacy issue. > OpenID Connect is a federated identity protocol built upon OAuth 2.0 and that's why it is considering these privacy issues. OAuth does not need to do the same. > > > > > *4=C2=B0. Minors issues (when compared to the others):* > > > > 1) The abstract states: > > While it is easy to implement, it means that (a) the communication throug= h > the user agents are not integrity protected > > and thus the parameters can be tainted, and (b) the source of the > communication is not authenticated. > > (...) > > This document introduces the ability to send request parameters in a JSON > Web Token (JWT) instead, which allows > > the request to be JWS signed and/or JWE encrypted so that the integrity, > source authentication and confidentiality > > property of the Authorization Request is attained. > > > > Since the main purpose is integrity protection and authentication, the JA= R > SHALL be signed and MAY be encrypted. > > Replace with: > > (...) which allows the request to be JAR to be signed and optionally > encrypted (...) > As far as the integrity protection is concerned, JWE covers it. For the source authentication, if the JWE uses symmetric key, it is also covered. So, JWS is not always required. > > > > > 2) On page 9 the text states: > > The authorization request object MUST be either > > (a) JWS signed; or > > (b) JWE encrypted; or > > (c) JWS signed and JWE encrypted. > > > > This should be replaced by: > > The authorization request object MUST be either > > (a) JWS signed; > > (b) JWE encrypted (when secret keys are being used); or > > (c) JWS signed and JWE encrypted. > That's acceptable. (Thanks for amending your proposal after several private exchanges.) > > > 4) On page 14, in section 6.3, the text states: > > the Authorization Server then validates the request as specified in > OAuth 2.0 [RFC6749]. > > This is rather vague, since no specific section from RFC 6749 is being > pointed at. > RFC 6749 is a framework with many options. > In the context of this draft, it would be beneficial to indicate which > kind processing of the JAR parameters shall be done by the Authorization > Server. > This issue clearly relates to the first major issue: interoperability. > Indeed it would be beneficial, but is also error prone. The implementer of this document needs to consult RFC6749 closely anyways as all the verificaiton requirements still holds, so as an editor, I would rather keep it as it is. It is not "reader friendly" but cannot go wrong with the approach to just referencing RFC6749. Nat > > > Denis > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --=20 Nat Sakimura Chairman of the Board, OpenID Foundation --001a1148f6f274db060545341de0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Comments inline:=C2=A0

2017=E5=B9=B41=E6=9C=884= =E6=97=A5(=E6=B0=B4) 1:52 Denis <d= enis.ietf@free.fr>:
=20 =20 =20
=20

Hello,

=C2=A0

I have only recently subscribed to this mailing list and hence I was not present when the WGLC was launched on this document.


I have several concerns and comments about this draft :


=

=C2=A0

1=C2=B0. The draft wi= ll be unable to move to Draft Standard

The Intended status of draft-ietf-oauth-jwsreq is Standards Track.

RFC 5657 states: Advancing a protocol to Draft Standard requires documentation of the interoperation and implementation of the protocol. <= /u>

The goal of RFC standard Track document is define int= eroperable protocols, hence not simply to define the syntax of a request leaving
dozens of possibilities about the treatment of the parameters that may be included in the request to the AS.

<= span style=3D"font-family:Arial" lang=3D"EN-US" class=3D"gmail_msg">=

<= span style=3D"font-family:Arial" lang=3D"EN-US" class=3D"gmail_msg">General= ly speaking, the text is silent about the treatment of every parameter of the JAR. In particular, what kind of verification and processing

SHALL be done by the Authorization Server on "aud", since both "= iss" and "aud" SHOULD be present (see page 6) in the Authorizati= on Request.

<= span style=3D"font-family:Arial" lang=3D"EN-US" class=3D"gmail_msg">The document currently fails to clearly indicate which = parameters of the JAR are used by the Authorization Server to validate the JAR itself
and which parameters are used to build the requested access token.

<= span style=3D"font-family:Arial" lang=3D"EN-US" class=3D"gmail_msg">For example, is the "aud" parameter supposed to identify the AS or the = RS ?

This means that the text should be sufficiently clear so that two different implementations can interoperate. This will not be the case if the text stays like this.

The goal of Standard Tracks RFCs is not to define frameworks but interoperable protocol= s.


It is interoperabol= e, in so much as RFC6749 and RFC7515 is. =C2=A0

=C2=A0


In addition to this major concern, I have other concerns:

=C2=A0

=C2=A0

2=C2=B0. Security con= sideration: the Al= ice and Bob Collaboration attack (ABC attack)

=C2=A0

Since the time RFC 6819 was written, a new kind of attack has been mentioned on the WG mailing list:
the ABC attack (Alice and Bob Collaboration attack) where Bob accepts to collaborate with Alice to get an access token that Alice will then be able to use.

There is no external attacker, but only two users who agree to collaborate to cheat an application server.
It is a major problem typically when an access token only contains a claim like "older then 18".

<= span style=3D"font-family:Arial" lang=3D"EN-US" class=3D"gmail_msg">This kind of attack is not mentioned in this draft, nor if it can be countered in the context of RFC 6749 (OAuth 2.0 Authorization Framework).<= u class=3D"gmail_msg">

=C2=A0

It would not be reasonable to consider the Alice and Bob Collaboration attack as being out of scope of the OAuth 2.0 Authorization Framework;
or ... if it is, this should be clearly stated in the abstract and in the security considerations section.


But in the later case, this would be as if a security hole would be left out of the scope of the OAuth 2.0 Authorization Framework.


=

OAuth was designed from a perspective that there is a trust relationship between the AS and RS so that things like AT token format were left unspecified.
This is a major design error. As long as the AT token format will = be left unspecified, it will not be possible to counter the ABC attack.


I disagree. In OAuth, AS and = RS has pre-defined relationship - they are tightly bound together and knows= how to interpret/resolve the access token.=C2=A0
Access token fo= rmat is totally out of scope of OAuth.=C2=A0
=C2=A0

JAR is applicable to all kinds of OAuth authorization request. It is considered as just another kind of encoding instead of query parameters.

<= div>
Indeed it is.=C2=A0
=C2=A0

In case query parameters are being transmitted within the URL, the ABC attack remains. So the ABC attack is not specific to this document only,
but to all this series of documents. :-(


ABC attack is out of socpe for OAuth. It is not a ne= w attack. The resource owner handing a bearer token to another party willfu= lly is not a threat in the bearer token model.=C2=A0

=C2=A0

Readers might think that the authentication of authorization requests solves one left opened security issue but in practice it does not.
Hence, this document can mislead many readers.


OAuth is not a federated authentication protocol.=C2=A0
OAuth is not even a federated authorization protocol by itself. You= need to build a profile upon it to do so.=C2=A0
=C2=A0

=C2=A0

IMO, in order to counter the ABC attack it is first necessary to specify one or more token syntax and the trust relationships :

-=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 between the token requestor and the AS,

-=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 between the AS ands the RS, and<= u class=3D"gmail_msg">

-=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 between the token requestor and the RS,


Sorry, but they are out of scope of this docu= ment as ABC attack is out of scope of RFC6749 and RFC6750. They can be deal= t with in POP document but not this one. =C2=A0

<= /u>

=C2=A0

The global security picture is governed by:<= u class=3D"gmail_msg">

-=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the two ways protocol between the token requestor and the AS, as well as the format the access token request and the processing of each of its parameters by the AS,

-=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the construction of each of parameter of the access token by the AS,

-=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the two ways protocol between the token requestor and the RS, as well as the format of the access token itself and the validation of each of its parameters by the RS,

=C2=A0

That depends on the security assumptions. You should challenge = RFC6749 and not this document. This document merely provides another encodi= ng for the authorization request so that the request can be integrity prote= cted and source authenticated.=C2=A0
=C2=A0

=C2=A0

3=C2=B0. Privacy consideration: Authorization Servers may be able to act as Big Brother

=C2=A0

Section 11 (Privacy Considerations) does not contain text to explain that an Authorization Server might be able to act as Big Brother
if it is able to know where each access token it issues will be used. The use of a audience parameter without any semantics in it should be recommended.

=C2=A0

Other people have already pointed it out.

=C2=A0

Basically, in this context, trust means that a user A trusts a server B for doing some actions C (and not for any kind of action).
Thus, a user A can trust a server B to provide him with a subset of his attributes in an access token but he does not necessarily trust


There is no notion of= "his attributes" in OAuth. You seem to be conflating general OAu= th framework with some kind of identity protocols.=C2=A0
=C2=A0

that same server B to keep private the list of the servers where he will use this access token (if B would be in a position to know
the identity of these resource servers).


Big Brother or "calling home problem" is v= ery well known, but as I have pointed out earlier, in OAuth, the authorizat= ion server and resource servers are tightly bound together, so it is not a = problem. In this kind of model, if you cannot trust your authorization serv= er, you had better stop using it altogether instead of asking for "bet= ter privacy". The consequence of using an untrusted authorization serv= er is much more grave. =C2=A0

<= /span>

=C2=A0

OpenID Connect is based on OAuth 2.0. OpenID Connect does either take into consideration this privacy issue.


OpenID Connect is a federated identity protocol built = upon OAuth 2.0 and that's why it is considering these privacy issues. O= Auth does not need to do the same.=C2=A0
=C2=A0

=C2=A0

=C2=A0

4=C2=B0. Minors issue= s (when compared to the others):

=C2=A0

1) The abstract states:

While it is easy to implement, it means that (a) the communication through the user agents are not integrity protected

and thus the parameters can be tainted, and (b) the source of the communication is not authenticated.=C2=A0

(...)

This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows

the request to be JWS signed and/or JWE encrypted so that the integrity, source authentication and confidentiality

property of the Authorization Request is attained.

=C2=A0

Since the main purpose is integrity protection and authentication, the JAR SHALL be signed and MAY be encrypted.

Repla= ce with: <= /u>

(...= ) which allows the request to be JAR to be signed and optionally encrypted (...)


As = far as the integrity protection is concerned, JWE covers it.=C2=A0
For the source authentication, if the JWE uses symmetric key, it is also = covered.=C2=A0
So, JWS is not always required. =C2=A0

=C2=A0

=C2= =A0

2) On page 9 the text states:

The authorization request object MUST be either

=C2=A0=C2=A0 (a)=C2=A0 JWS signed; or

=C2=A0=C2=A0 (b)=C2=A0 JWE encrypted; or

=C2=A0=C2=A0 (c)=C2=A0 JWS signed and JWE encrypted.

=C2= =A0

This should be replaced by:

The authorization request object MUST be either<= u class=3D"gmail_msg">

=C2= =A0=C2=A0 (a)=C2=A0 JWS signed;

=C2=A0=C2= =A0 (b)=C2=A0 JWE e= ncrypted (when secret keys are being used); or

=C2= =A0=C2=A0 (c)=C2=A0 JWS signed and JWE encrypted.


That's acceptable. (Thanks for amending = your proposal after several private exchanges.) =C2=A0

=C2=A0

4) On page 14, in section 6.3, the text states:<= u class=3D"gmail_msg">

=C2= =A0=C2=A0=C2=A0 the Authorizati= on Server then validates the request as specified in OAuth 2.0 [RFC6749].


This is rather vague, since no specific section from RFC 6749 is being pointed at.
RFC 6749 is a framework with many options.
In the context of this draft, it would be beneficial to indicate which kind processing of the JAR parameters shall be done by the Authorization Server.
This issue clearly relates to the first major issue: interoperability.

Indeed it would be beneficial, but is also error prone. The implementer = of this document needs to consult RFC6749 closely anyways as all the verifi= caiton requirements still holds, so as an editor, I would rather keep it as= it is. It is not "reader friendly" but cannot go wrong with the = approach to just referencing RFC6749.=C2=A0

Nat = =C2=A0


Denis



_______________________________________________
OAuth mailing list
OAu= th@ietf.org
https://www.ietf.org/mailman/listinfo= /oauth
--

Nat Sakimura

Chairman of the Board, OpenID Foundation

--001a1148f6f274db060545341de0-- From nobody Tue Jan 3 11:45:50 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6F6129B38 for ; Tue, 3 Jan 2017 11:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDeN7S2d6Xha for ; Tue, 3 Jan 2017 11:45:46 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67D32129B35 for ; Tue, 3 Jan 2017 11:45:46 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id h201so246274031qke.1 for ; Tue, 03 Jan 2017 11:45:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=IHi/qtjnAzy+nqIglP7mb1hia1ChrAwy7FEZqlrMbWw=; b=IIA29GCinQXQKOT2tmq9cUXXGIrLflfuMddgkp83Iamy+CT0RVk21qfs5DY1JKopT1 YYF3zA73aN1RTMz5f9yCeAYzRGE5oInOhG/jOxCyzlu2kXn5NobDAYADunqvmX6sIpxY 38pZ5VxiGiV++GTmHGkAUfvDKLtaVIcl8LiqPG7ZuDWqRqM7F6Zf+vwgKtecxiaxqDXj 4Wz3jTz2aeKjmV5dOCgzECWb07QG+1912LScK3lNP/UHUS4eLD7KlELvWmMwVoWxjYkH fHZv/YcBCGNgFXtExNuc7VV5Ae1PDwG7Lp3yfZ7rX8UlUPiYNpyl1sFmLRZQ1pV2Za0Q 4xQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=IHi/qtjnAzy+nqIglP7mb1hia1ChrAwy7FEZqlrMbWw=; b=eR8ZdBKIRN5Ybua2WTYzWlW2jLmvLJSfBqOAe0BbEfuFCVGhWKP2aGTcypusig11M7 feSNl2vx/ivowpnJNQ1+KtUZwXQciRds5QlDXspB/bVFweG9T3X6r2ElI5qBOh+C6z+2 dyqsqb2ganmzXLablXQfo4gfw5SofePVs3LZIewOnOum3msnEJk3KUpAUY+AGvzecDfO VVNjCxS8DCgRcLqQwLTVdeLPR1RIJdihkCqUZcE6MVuTwg+9kBF9tiLfkC1XZgt3OmYu JuJZ/xaZY/ls2FMYqqHTfYWQIwA1IiFA3Uiw3S6qwJsjXxQMJTeHYIGLqtUFNR/sLXEw Sqmg== X-Gm-Message-State: AIkVDXIOhHqQCpaj3X9FPpH9u0+ujGoBu7PnpTjHUdY8ebTizXguUC0Jr9AHBn5qMU+H7oKN X-Received: by 10.55.91.193 with SMTP id p184mr61259228qkb.301.1483472745477; Tue, 03 Jan 2017 11:45:45 -0800 (PST) Received: from jbradley-r.lan ([191.115.70.183]) by smtp.gmail.com with ESMTPSA id x40sm44232026qtx.12.2017.01.03.11.45.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jan 2017 11:45:44 -0800 (PST) From: John Bradley Message-Id: <9819C8B0-E1DB-47E0-9639-F85CACA8DB23@ve7jtb.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_9A343615-204E-4D63-B682-F05ECD6C9A83" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 3 Jan 2017 16:45:10 -0300 In-Reply-To: To: Nat Sakimura References: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-jwsreq X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 19:45:48 -0000 --Apple-Mail=_9A343615-204E-4D63-B682-F05ECD6C9A83 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Snip > On Jan 3, 2017, at 2:36 PM, Nat Sakimura wrote: >=20 > =20 >=20 > =20 > 2) On page 9 the text states: > The authorization request object MUST be either > (a) JWS signed; or > (b) JWE encrypted; or > (c) JWS signed and JWE encrypted. > =20 > This should be replaced by: > The authorization request object MUST be either > (a) JWS signed;=20 > (b) JWE encrypted (when secret keys are being used); or > (c) JWS signed and JWE encrypted. >=20 > That's acceptable. (Thanks for amending your proposal after several = private exchanges.) =20 >=20 Secret is not a clear term to use. It should be JWE encrypted (when = symmetric keys are bing used) =20 The private part of a RSA keypair is also secret. John B.= --Apple-Mail=_9A343615-204E-4D63-B682-F05ECD6C9A83 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Snip
On Jan 3, 2017, at 2:36 PM, Nat Sakimura = <sakimura@gmail.com> wrote:

 

 

2) On page 9 the text = states:

The authorization = request object MUST be either

   (a)  JWS signed; = or

   (b)  JWE encrypted; = or

   (c)  JWS signed and = JWE encrypted.

 

This should be replaced = by:

The authorization request object MUST be = either

   (a)  JWS signed; 

   (b)  JWE encrypted (when secret keys are = being used); or

   (c)  JWS signed and = JWE encrypted.


That's acceptable. (Thanks for amending = your proposal after several private exchanges.)  


=


Secret is not a clear term to use.  It should be JWE = encrypted (when symmetric keys are bing used)  
The private part of a RSA keypair is also secret.

John = B.
= --Apple-Mail=_9A343615-204E-4D63-B682-F05ECD6C9A83-- From nobody Tue Jan 3 22:41:46 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB7F129483 for ; Tue, 3 Jan 2017 22:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqGEnrBtjCqn for ; Tue, 3 Jan 2017 22:41:43 -0800 (PST) Received: from nrifs01.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61A9126D73 for ; Tue, 3 Jan 2017 22:41:41 -0800 (PST) Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs01.index.or.jp (Postfix) with ESMTP id 34F3B77ED8; Wed, 4 Jan 2017 15:41:41 +0900 (JST) Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id 0356D4E0046; Wed, 4 Jan 2017 15:41:41 +0900 (JST) Received: from nriea05.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id v046feoh005501; Wed, 4 Jan 2017 15:41:40 +0900 Received: from nrims00b.nri.co.jp ([192.50.135.12]) by nriea05.index.or.jp with ESMTP id v046fexr005498; Wed, 04 Jan 2017 15:41:40 +0900 Received: from nrims00b.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id v046feFV002538; Wed, 4 Jan 2017 15:41:40 +0900 Received: (from mailnull@localhost) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id v046fet5002537; Wed, 4 Jan 2017 15:41:40 +0900 X-Authentication-Warning: nrims00b.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf12.index.or.jp ([172.100.25.21]) by nrims00b.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id v046feAx002529; Wed, 4 Jan 2017 15:41:40 +0900 From: "Nat Sakimura" To: "'John Bradley'" , "'Nat Sakimura'" References: <9819C8B0-E1DB-47E0-9639-F85CACA8DB23@ve7jtb.com> In-Reply-To: <9819C8B0-E1DB-47E0-9639-F85CACA8DB23@ve7jtb.com> Date: Wed, 4 Jan 2017 15:41:48 +0900 Message-ID: <026701d26655$a00cea60$e026bf20$@nri.co.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0268_01D266A1.0FF68E30" X-Mailer: Microsoft Outlook 15.0 X-MailAdviser: 20141126 thread-index: AQJXUKfdpVtfeHi9xJkdDON5i8N4cwGEHProAhobz/oCfSMdqwOkKcpBn9ANOGA= Content-Language: ja Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-jwsreq X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 06:41:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0268_01D266A1.0FF68E30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yes, indeed. And when I wrote "acceptable", I meant "in principle", not verbatim ;-) Nat -- PLEASE READ :This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of John Bradley Sent: Wednesday, January 4, 2017 4:45 AM To: Nat Sakimura Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-jwsreq Snip On Jan 3, 2017, at 2:36 PM, Nat Sakimura > wrote: 2) On page 9 the text states: The authorization request object MUST be either (a) JWS signed; or (b) JWE encrypted; or (c) JWS signed and JWE encrypted. This should be replaced by: The authorization request object MUST be either (a) JWS signed; (b) JWE encrypted (when secret keys are being used); or (c) JWS signed and JWE encrypted. That's acceptable. (Thanks for amending your proposal after several private exchanges.) Secret is not a clear term to use. It should be JWE encrypted (when symmetric keys are bing used) The private part of a RSA keypair is also secret. John B. ------=_NextPart_000_0268_01D266A1.0FF68E30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Y= es, indeed. And when I wrote “acceptable”, I meant “in = principle”, not verbatim ;-)

<= o:p> 

N= at

<= o:p> 

--

PLEASE = READ :This e-mail is confidential and intended for = the

named = recipient only. If you are not an intended = recipient,

please = notify the sender  and delete this = e-mail.

<= o:p> 

From:<= /b> OAuth = [mailto:oauth-bounces@ietf.org] On Behalf Of John = Bradley
Sent: Wednesday, January 4, 2017 4:45 AM
To: = Nat Sakimura <sakimura@gmail.com>
Cc: = oauth@ietf.org
Subject: Re: [OAUTH-WG] AD review of = draft-ietf-oauth-jwsreq

 

Snip

On Jan 3, 2017, at 2:36 PM, Nat = Sakimura <sakimura@gmail.com> = wrote:

 

 

 

2) On page 9 the = text states:

The = authorization request object MUST be either

   (a)  JWS = signed; or

   (b)  JWE = encrypted; or

   (c)  JWS = signed and JWE encrypted.

 

This should be = replaced by:

The authorization = request object MUST be either

   (a)  JWS = signed; 

   (b)  JWE encrypted = (when secret keys are being used); or

   (c)  JWS signed and JWE = encrypted.

 

That's acceptable. (Thanks for = amending your proposal after several private exchanges.) =  

 

 

 

Secret is not a clear term to use. =  It should be JWE encrypted (when symmetric keys are bing used) =  

The private part of a RSA keypair is also = secret.

 

John = B.

------=_NextPart_000_0268_01D266A1.0FF68E30-- From nobody Wed Jan 4 19:09:19 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9206D129880 for ; Wed, 4 Jan 2017 19:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.321 X-Spam-Level: X-Spam-Status: No, score=-7.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmAp9_kbB57P for ; Wed, 4 Jan 2017 19:09:16 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B67812987F for ; Wed, 4 Jan 2017 19:09:16 -0800 (PST) X-AuditID: 12074422-153ff70000002a9a-fd-586db8da2557 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 9A.19.10906.AD8BD685; Wed, 4 Jan 2017 22:09:15 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id v0539EUJ010354; Wed, 4 Jan 2017 22:09:14 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v0539AUb028383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Jan 2017 22:09:13 -0500 Date: Wed, 4 Jan 2017 21:09:10 -0600 From: Benjamin Kaduk To: Denis Message-ID: <20170105030910.GT8460@kduck.kaduk.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IR4hTV1r29IzfCYNtxcYv1XXYWJ9++YnNg 8uhf95nVY8mSn0wBTFFcNimpOZllqUX6dglcGXf+/WYpuMlfMfH1FOYGxn08XYycHBICJhIv Xh9j6WLk4hASaGOS6L82kxnC2cAosezTAqjMFSaJ3z92MoK0sAioSEw8MosFxGYDshu6LzOD 2CICchKr7l0Ds5kFhCQ+XGoCqxEWsJHYvKmXCcTmFTCW2L1gB9TQE4wS+5c3QiUEJU7OfMIC 0awjsXPrHbYuRg4gW1pi+T8OiLC8RPPW2WDzOQWsJX6sXATWKiqgLNEw4wHzBEbBWUgmzUIy aRbCpFlIJi1gZFnFKJuSW6Wbm5iZU5yarFucnJiXl1qka6qXm1mil5pSuokRFNbsLko7GCf+ 8zrEKMDBqMTDe+NHToQQa2JZcWXuIUZJDiYlUd7EqtwIIb6k/JTKjMTijPii0pzU4kOMEhzM SiK83MBoEuJNSaysSi3Kh0lJc7AoifNeynSPEBJITyxJzU5NLUgtgsnKcHAoSfCygzQKFqWm p1akZeaUIKSZODhBhvMADb+/HWR4cUFibnFmOkT+FKOilDhvyTaghABIIqM0D64XlHYksvfX vGIUB3pFmNcGpJ0HmLLgul8BDWYCGrw9IBtkcEkiQkqqgdGTv/FZ6Xx3yZkrDsapFeZlMgtn OrNJxN7b8LTygy1HcqVId0V+utKdm2HbyxT9CkrDFkyTTFvqoSX/5OysOKYPqg2Sl+96SjKt lC8um7jmacypqiNtXQ9ivBKvKbgnelXyF8dJJP1uD75quzM7SIrT2Gen/YJSie7Pjdtlrn1N f3N5bdhyJZbijERDLeai4kQAryUeBxYDAAA= Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-jwsreq X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 03:09:17 -0000 On Tue, Jan 03, 2017 at 05:52:22PM +0100, Denis wrote: > > > *1°. The draft will be unable to move to Draft Standard* > > The Intended status of draft-ietf-oauth-jwsreq is Standards Track. > > RFC 5657 states: Advancing a protocol to Draft Standard requires > documentation of the *interoperation *and implementation *o**f the > protocol.* > > The goal of RFC standard Track document is define *interoperable > protocols, *hence not simply to define the syntax of a request leaving > dozens of possibilities about the treatment of the parameters that may > be included in the request to the AS. > > Generally speaking, the text is silent about the treatment of _every_ > parameter of the JAR. In particular, what kind of verification and > processing > SHALL be done by the Authorization Server on "aud", since both "iss" and > "aud" SHOULD be present (see page 6) in the Authorization Request. > > The document currently fails to *clearly indicate which parameters of > the JAR are used by the Authorization Server to validate the JAR itself > and which parameters are used to build the requested access token*. > > For example, is the "aud" parameter supposed to identify the AS or the RS ? > > This means that the text should be sufficiently clear so that two > different implementations can interoperate. This will not be the case if > the text stays like this. > > The goal of Standard Tracks RFCs is not to define frameworks but > *interoperable protocols.* While I applaud the goal of interoperability, I must raise the big flag that no one said anything about "Draft Standard" for this document, and RFC 6410 eliminates the "Draft Standard" status. And from a pragmatic point of view, if it is necessary to first specify a framework before one can get consensus to specify something fully specified and interoperable, then that's a fine step to take. So, I'm not sure that I'm convinced by this particular item from your list. -Ben From michael.reizelman14@gmail.com Thu Jan 5 10:33:47 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E03129694 for ; Thu, 5 Jan 2017 10:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOQj4EtExOyH for ; Thu, 5 Jan 2017 10:33:46 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 938D9129693 for ; Thu, 5 Jan 2017 10:33:46 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id y9so55448049uae.2 for ; Thu, 05 Jan 2017 10:33:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=4VyZDVMs+bq51jSTTMMryymx/oenctC3TTiABzaAgiE=; b=l/2qjoHOTET2H+ujQ4GBpm6iojepOzYp5KQpx4Blac6D+/PqMVybOtnIgJlETAxUaO PMzUM0qX+pMePjAnheqwT+MdITfvIVyI/DYgP5NFG6ScJvDmGPUjXqu4wQDcBTtIIrTN KkbADtyZrPtAYLmTX6vCAwKk+KIAPrq4QIxmqkfYY1HN4B5d5Wml6s+YBI8Hh6sYirfw deeF3MeeNCE4kCPCJCFdMfGlPhHqiDk2/2NYkH4g9eDSI/YxVIWrkfHddYOqt9P9hVoN z7FINkH3d2vt8gbKeXy/REtnV9GaFXN61+LA/wVl6rfm/4VXKuHn6dwRzgD5moAfFKip xP0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4VyZDVMs+bq51jSTTMMryymx/oenctC3TTiABzaAgiE=; b=ozTmMFuI9fDTelSqX9Q7lxXQBWZlag9x37lvnwqteO/OjR6AOdqsqZ1ORugjrFpvtM u8/O3OeOvweJlGXxUPJmHV/GVZppiMgVM71eUAMgeJIidWfse0mDX5vWmqY/b5Vzo60p I+tzrxuO2Viek/F96J2ELk5LX4dBMyvRLgX50MvZt4n/KMBV505ZDjBx6nVAGMlQ7LY7 0CamLfL+V8QdKnaiUKD7/Z4rqxxt83zdEhomiKHA6gLWT1gTNyRa/TaUG2aNbW/9Plgw Xvh0Ne+/1NiqFEjWHr+OfuXQABmjaEGmK0HbA5iOIJ2SDxFVEA0R6GXZ5tkb0s/WYD1E KBIA== X-Gm-Message-State: AIkVDXIHOCbGlmia+3X5t1VQdFBivMCcBdbLcGsXLBw1PS0UQfgXKx6Req/GkSTysDm4j90IAKHy42c4LssxAw== X-Received: by 10.176.23.3 with SMTP id j3mr593010uaf.78.1483641225558; Thu, 05 Jan 2017 10:33:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.18.225 with HTTP; Thu, 5 Jan 2017 10:33:45 -0800 (PST) From: Michael Reizelman Date: Thu, 5 Jan 2017 20:33:45 +0200 Message-ID: To: oauth@ietf.org Content-Type: multipart/alternative; boundary=f40304361f38393ee405455d247f Archived-At: X-Mailman-Approved-At: Thu, 05 Jan 2017 11:44:32 -0800 Subject: [OAUTH-WG] Vulnerability in the OAuth2 Mobile flow May lead to access token leakage X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 18:35:27 -0000 --f40304361f38393ee405455d247f Content-Type: text/plain; charset=UTF-8 Hi, During my tests of the Facebook OAuth2.0 implementation I have discovered a vulnerability which I first thought was due to bad implementation. However, after reporting it to them and analyzing the official specification, including the PKCE standard, I have realized that this attack can be used against any OAuth2.0 current specification. I have encountered this email on http://www.rfc-editor.org/info/rfc7636 so I have wanted to make sure whether this is the place to securely report this flow (Which may lead to compromise of access tokens on every OAuth2.0 mobile implementation)? And if not, who can I contact about this? Thanks, Michael --f40304361f38393ee405455d247f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

During my tests of the Facebook OAuth2.0 implementation I have = discovered a vulnerability which I first thought was due to bad implementat= ion. However, after reporting it to them and analyzing the official specifi= cation, including the PKCE standard, I have realized that this attack can b= e used against any OAuth2.0 current specification. I have encountered this = email on=C2=A0http://www= .rfc-editor.org/info/rfc7636 so I have wanted to make sure whether this= is the place to securely report this flow (Which may lead to compromise of= access tokens on every OAuth2.0 mobile implementation)? And if not, who ca= n I contact about this?

Th= anks,
Michael
--f40304361f38393ee405455d247f-- From nobody Thu Jan 5 11:54:38 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED901295F9 for ; Thu, 5 Jan 2017 11:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucGcFMuF4RJd for ; Thu, 5 Jan 2017 11:54:22 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9131129662 for ; Thu, 5 Jan 2017 11:54:20 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id a20so54768029qkc.1 for ; Thu, 05 Jan 2017 11:54:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mnS8UjQKRSj5yy7OOMuZwShoo/+j0WsJqXGmtdBKIck=; b=nHVkaJ1Nej0JJqJxaPYkdePs11QZH9DHABu3UEXDQ1LJLutpYWoDpWp0QScEOscVbk DxuQp79BiIa1Tg5f8kvnuVp27140Zc2F7M8G96XOxPRqGK1kNWfpFluDijv/J/fQiNGZ 2BZMVcNoAOFBtIRUtV2FFfYu2apZ0lFzz9lV3PkYIDZpXwtwBpXs2SDOpblL1jPtOxm1 IaTx17zTBNuAdWyYxwny5ohrNi+ITfKQcmxsXYiRmiEHqiyxGtENUFAnPNEx4rhCGkDY 6CkfAzsZCPsZqQaWEXGlUTOK2UogtnQmVbVjl9rbJUZ8Fskdh1QFR7TNcTDUEjJ1jP6S ruCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mnS8UjQKRSj5yy7OOMuZwShoo/+j0WsJqXGmtdBKIck=; b=g5Tr9pPNU8N7137A4GC6NAA6Tsd3hI/XSeaVQfDkT7IiieCNQ9s763Ft5FN4H/jZse 7YVZ8RzNOXah0k7zZZrUfBnu70Xsqnob/rAPOWb7GrPeSGDRXlMA1GkKPeuMQYielsyC a7oT2weXrTH48g8t8RWcRbbc1ChmbK0L4xDYEjNxZd/13j2Npk6WhvuxwInsGYZysLlK 6D+28ESrZiCT3ZCmH9tlh2hoZL1GoF5MWTXyDFfbZuw87L+J6H1nHl8eiXDOGmD3WPJa VH+DSqan3X0MgiG8CFy5sCgRouU/XOuaY3OcqfdM2QPLFZhj0SwZi2leI1XfOKVplJlv HtFg== X-Gm-Message-State: AIkVDXK3Dwps7kuQft9Zzu1bOxpgavUX/6mboNJrNg0NdFCiJJtslW6Sdok5qpQ/JUqogb1w X-Received: by 10.55.197.28 with SMTP id p28mr70812002qki.255.1483646059891; Thu, 05 Jan 2017 11:54:19 -0800 (PST) Received: from [192.168.86.118] ([191.115.185.61]) by smtp.gmail.com with ESMTPSA id c2sm48792569qkg.8.2017.01.05.11.54.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Jan 2017 11:54:19 -0800 (PST) From: John Bradley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_0E1D0D62-CFE0-4A52-8F50-F0C359A47895" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 5 Jan 2017 16:54:00 -0300 In-Reply-To: To: Michael Reizelman References: X-Mailer: Apple Mail (2.3259) Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Vulnerability in the OAuth2 Mobile flow May lead to access token leakage X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 19:54:26 -0000 --Apple-Mail=_0E1D0D62-CFE0-4A52-8F50-F0C359A47895 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is a public list, so it would not be the place if confidentially = disclose a vulnerability. I think Hannes was going to set up a confidential security list. If it relates to PKCE you can contact myself or Nat as a place to start. It would be news to me if Facebook was using RFC7636. Likely they = accept and ignore the parameters if you were to send it to them. =20 I know Google has it implemented. We are finishing work on = https://tools.ietf.org/html/draft-ietf-oauth-native-apps, so if you have = something relevant to native app security that we are not covering now = would be a good time to bring it up. Myself or William Denniss can be contacted as the editors for that. Regards John B. > On Jan 5, 2017, at 3:33 PM, Michael Reizelman = wrote: >=20 > Hi, >=20 > During my tests of the Facebook OAuth2.0 implementation I have = discovered a vulnerability which I first thought was due to bad = implementation. However, after reporting it to them and analyzing the = official specification, including the PKCE standard, I have realized = that this attack can be used against any OAuth2.0 current specification. = I have encountered this email on http://www.rfc-editor.org/info/rfc7636 = so I have wanted to make sure = whether this is the place to securely report this flow (Which may lead = to compromise of access tokens on every OAuth2.0 mobile implementation)? = And if not, who can I contact about this? >=20 > Thanks, > Michael > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_0E1D0D62-CFE0-4A52-8F50-F0C359A47895 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii This is a public list, so it would not be the place if = confidentially disclose a vulnerability.

I think Hannes was going to set up a = confidential security list.

If it relates to PKCE you can contact myself or Nat as a = place to start.

It would be news to me if Facebook was using RFC7636.   = Likely they accept and ignore the parameters if you were to send it to = them.  

I = know Google has it implemented.

We are finishing work on  https://tools.ietf.org/html/draft-ietf-oauth-native-apps, = so if you have something relevant to native app security that we are not = covering now would be a good time to bring it up.
Myself or William Denniss can be contacted as the editors for = that.

Regards
John B.



On = Jan 5, 2017, at 3:33 PM, Michael Reizelman <michael.reizelman14@gmail.com> wrote:

Hi,

During my = tests of the Facebook OAuth2.0 implementation I have discovered a = vulnerability which I first thought was due to bad implementation. = However, after reporting it to them and analyzing the official = specification, including the PKCE standard, I have realized that this = attack can be used against any OAuth2.0 current specification. I have = encountered this email on http://www.rfc-editor.org/info/rfc7636 so I have wanted = to make sure whether this is the place to securely report this flow = (Which may lead to compromise of access tokens on every OAuth2.0 mobile = implementation)? And if not, who can I contact about this?

Thanks,
Michael
_______________________________________________
OAuth = mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

= --Apple-Mail=_0E1D0D62-CFE0-4A52-8F50-F0C359A47895-- From nobody Thu Jan 5 13:07:42 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E582312942F for ; Thu, 5 Jan 2017 13:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_EvRSKy-1fP for ; Thu, 5 Jan 2017 13:07:36 -0800 (PST) Received: from smtp6-g21.free.fr (smtp6-g21.free.fr [IPv6:2a01:e0c:1:1599::15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BC671293D8 for ; Thu, 5 Jan 2017 13:07:36 -0800 (PST) Received: from [192.168.0.13] (unknown [88.182.125.39]) by smtp6-g21.free.fr (Postfix) with ESMTP id F2054780396; Thu, 5 Jan 2017 22:07:29 +0100 (CET) To: Nat Sakimura , oauth@ietf.org References: From: Denis Message-ID: Date: Thu, 5 Jan 2017 22:07:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------83DC042B56BB47B767DCE129" Archived-At: Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-jwsreq X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 21:07:40 -0000 This is a multi-part message in MIME format. --------------83DC042B56BB47B767DCE129 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello Nat, I have several text proposals to accommodate my previous comments. 1. On page 4, delete : ** *The parameters "request" and "request_uri" are introduced as* *additional authorization request parameters for the OAuth 2.0* *[RFC6749] flows.The "request" parameter is a JSON Web Token (JWT)* *[RFC7519] whose JWT Claims Set holds the JSON encoded OAuth 2.0* *authorization request parameters.This JWT is integrity protected* *and source authenticated using JWS.* and move it after the first paragraph of section 4 where this text belongs. 2. At the very end of the Introduction on Page 5, add : *This document defines the syntax of the JAR but does not define the semantics of every parameter of the request nor the way the Authorization Server shall process each parameter of the request. As a consequence, the document defines a framework for protecting the parameters of the token request, but does not specify how to construct an access token using the parameters of the request. This document used alone does not allow for interoperability. Additional documents are needed.* 3. On page 7, replace: ***To encrypt, JWE [RFC7516] is used.Unless the algorithm used in JWE* *allows for the source to be authenticated, JWS signature should also* *be applied.* by: *To encrypt, JWE [RFC7516] is used.Unless the algorithm used in JWE* *uses symmetrical cryptography and thus allows for the source to be authenticated, JWS signature should also be applied.* 4. In section 5, on page 9 replace: *The authorization request object MUST be either* ** *(a)JWS signed; or * *(b)JWE encrypted; or * *(c)JWS signed and JWE encrypted.* by: *The authorization request object MUST be either* ** *(a)JWS signed using an asymmetrical algorithm; or * *(b)JWE encrypted using a symmetrical algorithm; or * *(c)JWS signed using an asymmetrical algorithm and JWE encrypted using an asymmetrical algorithm.* 5. In section 6.3 on page 14, ad at the very end of this section: *This document does not define how the parameters of the request should be processed. * 6. On page 16, at the end of section 10 add: *10.5.Alice and Bob collaboration attack* ** *This is an attack towards the Authorization server where Bob works in collaboration with Alice in order to obtain an access token that Alice could then use. Integrity protection and authentication of the source of the communication of the JAR is not sufficient to counter that type of attack. * 7. On page 18, at the end of section 11 add: *11.3. No disclosure to the AS where the access tokens will be used* ** *One of the request parameters of the JAR may indicate where the access token to be issued shall be used (e.g. using an "aud" parameter). If this parameter is specified as a URL, the Authorization Server will be able to know exactly where each access token it issues will be used. It is thus recommended to use a value that contains no semantics and that changes for every access token request.* ** In addition, there are two typos: 8. On page 1 in the abstract, change : *authentication and confidentiallity property of the Authorization* into: *authentication and confidentiality property of the Authorization* 9. On page 17, section 11.1 change: ***Provider.Then, the Auhtorization Server issues HTTP GET request to* into: *Provider.Then, the Authorization Server issues HTTP GET request to* Denis > Hi, > > Comments inline: > > 2017年1月4日(水) 1:52 Denis >: > > Hello, > > I have only recently subscribed to this mailing list and hence I > was not present when the WGLC was launched on this document. > > > I have several concerns and comments about this draft : > > > *1°. The draft will be unable to move to Draft Standard* > > The Intended status of draft-ietf-oauth-jwsreq is Standards Track. > > RFC 5657 states: Advancing a protocol to Draft Standard requires > documentation of the *interoperation *and implementation *o**f the > protocol.* > > The goal of RFC standard Track document is define *interoperable > protocols, *hence not simply to define the syntax of a request > leaving > dozens of possibilities about the treatment of the parameters that > may be included in the request to the AS. > > Generally speaking, the text is silent about the treatment of > _every_ parameter of the JAR. In particular, what kind of > verification and processing > > SHALL be done by the Authorization Server on "aud", since both > "iss" and "aud" SHOULD be present (see page 6) in the > Authorization Request. > > The document currently fails to *clearly indicate which parameters > of the JAR are used by the Authorization Server to validate the > JAR itself > and which parameters are used to build the requested access token*. > > For example, is the "aud" parameter supposed to identify the AS or > the RS ? > > This means that the text should be sufficiently clear so that two > different implementations can interoperate. This will not be the > case if the text stays like this. > > The goal of Standard Tracks RFCs is not to define frameworks but > *interoperable protocols.* > > > It is interoperabole, in so much as RFC6749 and RFC7515 is. > > > In addition to this major concern, I have other concerns: > > *2°. Security consideration: the Alice and Bob Collaboration > attack (ABC attack)* > > Since the time RFC 6819 was written, a new kind of attack has been > mentioned on the WG mailing list: > the ABC attack (*Alice and Bob Collaboration attack*) where Bob > accepts to collaborate with Alice to get an access token that > Alice will then be able to use. > > There is no external attacker, but only two users who agree to > collaborate to cheat an application server. > It is a major problem typically when an access token only contains > a claim like "older then 18". > > This kind of attack is not mentioned in this draft, nor if it can > be countered in the context of RFC 6749 (OAuth 2.0 Authorization > Framework). > > It would not be reasonable to consider the Alice and Bob > Collaboration attack as being out of scope of the OAuth 2.0 > Authorization Framework; > or ... if it is, this should be clearly stated in the abstract and > in the security considerations section. > > > But in the later case, this would be as if a security hole would > be left out of the scope of the OAuth 2.0 Authorization Framework. > > > OAuth was designed from a perspective that there is a trust > relationship between the AS and RS so that things like AT token > format were left unspecified. > This is a major design error. As long as the AT token format will > be left unspecified, it will not be possible to counter the ABC > attack. > > > I disagree. In OAuth, AS and RS has pre-defined relationship - they > are tightly bound together and knows how to interpret/resolve the > access token. > Access token format is totally out of scope of OAuth. > > > JAR is applicable to all kinds of OAuth authorization request. It > is considered as just another kind of encoding instead of query > parameters. > > > Indeed it is. > > In case query parameters are being transmitted within the URL, the > ABC attack remains. So the ABC attack is not specific to this > document only, > but to all this series of documents. :-( > > > ABC attack is out of socpe for OAuth. It is not a new attack. The > resource owner handing a bearer token to another party willfully is > not a threat in the bearer token model. > > Readers might think that the authentication of authorization > requests solves one left opened security issue but in practice it > does not. > Hence, this document can mislead many readers. > > > OAuth is not a federated authentication protocol. > OAuth is not even a federated authorization protocol by itself. You > need to build a profile upon it to do so. > > IMO, in order to counter the ABC attack it is first necessary to > specify one or more token syntax and the trust relationships : > > -between the token requestor and the AS, > > -between the AS ands the RS, and > > -between the token requestor and the RS, > > > Sorry, but they are out of scope of this document as ABC attack is out > of scope of RFC6749 and RFC6750. They can be dealt with in POP > document but not this one. > > The global security picture is governed by: > > -the two ways protocol between the token requestor and the AS, as > well as the format the access token request and the processing of > each of its parameters by the AS, > > -the construction of each of parameter of the access token by the AS, > > -the two ways protocol between the token requestor and the RS, as > well as the format of the access token itself and the validation > of each of its parameters by the RS, > > > That depends on the security assumptions. You should challenge RFC6749 > and not this document. This document merely provides another encoding > for the authorization request so that the request can be integrity > protected and source authenticated. > > *3°.**Privacy consideration: Authorization Servers may be able to > act as Big Brother* > > Section 11 (Privacy Considerations) does not contain text to > explain that an Authorization Server might be able to act as Big > Brother > if it is able to know where each access token it issues will be > used. The use of a audience parameter without any semantics in it > should be recommended. > > Other people have already pointed it out. > > Basically, in this context, trust means that a user A trusts a > server /_B for doing some actions C_/ (and not for any kind of > action). > Thus, a user A can trust a server B to provide him with a subset > of his attributes in an access token but he does not necessarily > trust > > > There is no notion of "his attributes" in OAuth. You seem to be > conflating general OAuth framework with some kind of identity protocols. > > that same server B to keep private the list of the servers where > he will use this access token (if B would be in a position to know > the identity of these resource servers). > > > Big Brother or "calling home problem" is very well known, but as I > have pointed out earlier, in OAuth, the authorization server and > resource servers are tightly bound together, so it is not a problem. > In this kind of model, if you cannot trust your authorization server, > you had better stop using it altogether instead of asking for "better > privacy". The consequence of using an untrusted authorization server > is much more grave. > > OpenID Connect is based on OAuth 2.0. OpenID Connect does either > take into consideration this privacy issue. > > > OpenID Connect is a federated identity protocol built upon OAuth 2.0 > and that's why it is considering these privacy issues. OAuth does not > need to do the same. > > *4°. Minors issues (when compared to the others):* > > 1) The abstract states: > > While it is easy to implement, it means that (a) the communication > through the user agents are not integrity protected > > and thus the parameters can be tainted, and (b) the source of the > communication is not authenticated. > > (...) > > This document introduces the ability to send request parameters in > a JSON Web Token (JWT) instead, which allows > > the request to be JWS signed and/or JWE encrypted so that the > integrity, source authentication and confidentiality > > property of the Authorization Request is attained. > > Since the main purpose is integrity protection and authentication, > the JAR SHALL be signed and MAY be encrypted. > > Replace with: > > (...) which allows the request to be JAR to be signed and > optionally encrypted (...) > > > As far as the integrity protection is concerned, JWE covers it. > For the source authentication, if the JWE uses symmetric key, it is > also covered. > So, JWS is not always required. > > 2) On page 9 the text states: > > The authorization request object MUST be either > > (a) JWS signed; or > > (b) JWE encrypted; or > > (c) JWS signed and JWE encrypted. > > This should be replaced by: > > The authorization request object MUST be either > > (a) JWS signed; > > (b) JWE encrypted (when secret keys are being used); or > > (c) JWS signed and JWE encrypted. > > > That's acceptable. (Thanks for amending your proposal after several > private exchanges.) > > 4) On page 14, in section 6.3, the text states: > > the Authorization Server then validates the request as specified > in OAuth 2.0 [RFC6749]. > > > This is rather vague, since no specific section from RFC 6749 is > being pointed at. > RFC 6749 is a framework with many options. > In the context of this draft, it would be beneficial to indicate > which kind processing of the JAR parameters shall be done by the > Authorization Server. > This issue clearly relates to the first major issue: interoperability. > > > Indeed it would be beneficial, but is also error prone. The > implementer of this document needs to consult RFC6749 closely anyways > as all the verificaiton requirements still holds, so as an editor, I > would rather keep it as it is. It is not "reader friendly" but cannot > go wrong with the approach to just referencing RFC6749. > > Nat > > > > Denis > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > -- > > Nat Sakimura > > Chairman of the Board, OpenID Foundation > --------------83DC042B56BB47B767DCE129 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hello  Nat,

I have several text proposals to accommodate my previous comments.

 

1. On page 4, delete :

 

   The parameters "request" and "request_uri" are introduced as
   additional authorization request parameters for the OAuth 2.0
   [RFC6749] flows.  The "request" parameter is a JSON Web Token (JWT)
   [RFC7519] whose JWT Claims Set holds the JSON encoded OAuth 2.0
   authorization request parameters.  This JWT is integrity protected
   and source authenticated using JWS.


and move it after the first paragraph of section 4 where this text belongs.

 

2. At the very end of the Introduction on Page 5, add :

 

   This document defines the syntax of the JAR but does not define the
   semantics of every parameter of the request nor the way the
   Authorization Server shall process each parameter of the request. As a
   consequence, the document defines a framework for protecting the
   parameters of the token request, but does not specify how to construct
   an access token using the parameters of the request. This document
   used alone does not allow for interoperability.  Additional documents
   are needed.

 

3. On page 7, replace:

 

   To encrypt, JWE [RFC7516] is used.  Unless the algorithm used in JWE
   allows for the source to be authenticated, JWS signature should also

   be applied. 

by:

 

   To encrypt, JWE [RFC7516] is used.  Unless the algorithm used in JWE
   uses symmetrical cryptography and thus allows for the source to be
   authenticated, JWS signature should also be applied.  

 

4. In section 5, on page 9 replace:

 

The authorization request object MUST be either
 
   (a)  JWS signed; or 
   (b)  JWE encrypted; or 
   (c)  JWS signed and
        JWE encrypted.

by:

 

The authorization request object MUST be either
 
   (a)  JWS signed using an asymmetrical algorithm; or 
   (b)  JWE encrypted using a symmetrical algorithm; or 
   (c)  JWS signed using an asymmetrical algorithm and
        JWE encrypted using an asymmetrical algorithm.
 

 

5. In section 6.3 on page 14, ad at the very end of this section:

 

   This document does not define how the parameters of the request
   should be processed.

 

6. On page 16, at the end of section 10 add:

 

10.5.  Alice and Bob collaboration attack
 
   This is an attack towards the Authorization server where Bob works
   in collaboration with Alice in order to obtain an access token that
   Alice could then use.  Integrity protection and authentication of
   the source of the communication of the JAR is not sufficient to
   counter that type of attack.

 

 

7. On page 18, at the end of section 11 add:

 

11.3. No disclosure to the AS where the access tokens will be used
 

   One of the request parameters of the JAR may indicate where the
   access token to be issued shall be used (e.g. using an "aud"
   parameter).  If this parameter is specified as a URL, the
   Authorization Server will be able to know exactly where each access
   token it issues will be used.  It is thus recommended to use a value
   that contains no semantics and that changes for every access token
   request.

 

In addition, there are two typos:

 

8. On page 1 in the abstract, change :

 

authentication and confidentiallity property of the Authorization

 

into:

 

authentication and confidentiality property of the Authorization

 

9. On page 17, section 11.1 change:

 

   Provider.  Then, the Auhtorization Server issues HTTP GET request to

 

into:

 

   Provider.  Then, the Authorization Server issues HTTP GET request to

 

Denis

Hi, 

Comments inline: 

2017年1月4日(水) 1:52 Denis <denis.ietf@free.fr>:

Hello,

 

I have only recently subscribed to this mailing list and hence I was not present when the WGLC was launched on this document.


I have several concerns and comments about this draft :


 

1°. The draft will be unable to move to Draft Standard

The Intended status of draft-ietf-oauth-jwsreq is Standards Track.

RFC 5657 states: Advancing a protocol to Draft Standard requires documentation of the interoperation and implementation of the protocol.

The goal of RFC standard Track document is define interoperable protocols, hence not simply to define the syntax of a request leaving
dozens of possibilities about the treatment of the parameters that may be included in the request to the AS.

Generally speaking, the text is silent about the treatment of every parameter of the JAR. In particular, what kind of verification and processing

SHALL be done by the Authorization Server on "aud", since both "iss" and "aud" SHOULD be present (see page 6) in the Authorization Request.

The document currently fails to clearly indicate which parameters of the JAR are used by the Authorization Server to validate the JAR itself
and which parameters are used to build the requested access token.

For example, is the "aud" parameter supposed to identify the AS or the RS ?

This means that the text should be sufficiently clear so that two different implementations can interoperate. This will not be the case if the text stays like this.

The goal of Standard Tracks RFCs is not to define frameworks but interoperable protocols.


It is interoperabole, in so much as RFC6749 and RFC7515 is.  

 


In addition to this major concern, I have other concerns:

 

 

2°. Security consideration: the Alice and Bob Collaboration attack (ABC attack)

 

Since the time RFC 6819 was written, a new kind of attack has been mentioned on the WG mailing list:
the ABC attack (Alice and Bob Collaboration attack) where Bob accepts to collaborate with Alice to get an access token that Alice will then be able to use.

There is no external attacker, but only two users who agree to collaborate to cheat an application server.
It is a major problem typically when an access token only contains a claim like "older then 18".

This kind of attack is not mentioned in this draft, nor if it can be countered in the context of RFC 6749 (OAuth 2.0 Authorization Framework).

 

It would not be reasonable to consider the Alice and Bob Collaboration attack as being out of scope of the OAuth 2.0 Authorization Framework;
or ... if it is, this should be clearly stated in the abstract and in the security considerations section.


But in the later case, this would be as if a security hole would be left out of the scope of the OAuth 2.0 Authorization Framework.


OAuth was designed from a perspective that there is a trust relationship between the AS and RS so that things like AT token format were left unspecified.
This is a major design error. As long as the AT token format will be left unspecified, it will not be possible to counter the ABC attack.


I disagree. In OAuth, AS and RS has pre-defined relationship - they are tightly bound together and knows how to interpret/resolve the access token. 
Access token format is totally out of scope of OAuth. 
 


JAR is applicable to all kinds of OAuth authorization request. It is considered as just another kind of encoding instead of query parameters.


Indeed it is. 
 

In case query parameters are being transmitted within the URL, the ABC attack remains. So the ABC attack is not specific to this document only,
but to all this series of documents. :-(


ABC attack is out of socpe for OAuth. It is not a new attack. The resource owner handing a bearer token to another party willfully is not a threat in the bearer token model. 

 

Readers might think that the authentication of authorization requests solves one left opened security issue but in practice it does not.
Hence, this document can mislead many readers.


OAuth is not a federated authentication protocol. 
OAuth is not even a federated authorization protocol by itself. You need to build a profile upon it to do so. 
 

 

IMO, in order to counter the ABC attack it is first necessary to specify one or more token syntax and the trust relationships :

-          between the token requestor and the AS,

-          between the AS ands the RS, and

-          between the token requestor and the RS,


Sorry, but they are out of scope of this document as ABC attack is out of scope of RFC6749 and RFC6750. They can be dealt with in POP document but not this one.  

 

The global security picture is governed by:

-          the two ways protocol between the token requestor and the AS, as well as the format the access token request and the processing of each of its parameters by the AS,

-          the construction of each of parameter of the access token by the AS,

-          the two ways protocol between the token requestor and the RS, as well as the format of the access token itself and the validation of each of its parameters by the RS,

 


That depends on the security assumptions. You should challenge RFC6749 and not this document. This document merely provides another encoding for the authorization request so that the request can be integrity protected and source authenticated. 
 

 

3°. Privacy consideration: Authorization Servers may be able to act as Big Brother

 

Section 11 (Privacy Considerations) does not contain text to explain that an Authorization Server might be able to act as Big Brother
if it is able to know where each access token it issues will be used. The use of a audience parameter without any semantics in it should be recommended.

 

Other people have already pointed it out.

 

Basically, in this context, trust means that a user A trusts a server B for doing some actions C (and not for any kind of action).
Thus, a user A can trust a server B to provide him with a subset of his attributes in an access token but he does not necessarily trust


There is no notion of "his attributes" in OAuth. You seem to be conflating general OAuth framework with some kind of identity protocols. 
 

that same server B to keep private the list of the servers where he will use this access token (if B would be in a position to know
the identity of these resource servers).


Big Brother or "calling home problem" is very well known, but as I have pointed out earlier, in OAuth, the authorization server and resource servers are tightly bound together, so it is not a problem. In this kind of model, if you cannot trust your authorization server, you had better stop using it altogether instead of asking for "better privacy". The consequence of using an untrusted authorization server is much more grave.  

 

OpenID Connect is based on OAuth 2.0. OpenID Connect does either take into consideration this privacy issue.


OpenID Connect is a federated identity protocol built upon OAuth 2.0 and that's why it is considering these privacy issues. OAuth does not need to do the same. 
 

 

 

4°. Minors issues (when compared to the others):

 

1) The abstract states:

While it is easy to implement, it means that (a) the communication through the user agents are not integrity protected

and thus the parameters can be tainted, and (b) the source of the communication is not authenticated. 

(...)

This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows

the request to be JWS signed and/or JWE encrypted so that the integrity, source authentication and confidentiality

property of the Authorization Request is attained.

 

Since the main purpose is integrity protection and authentication, the JAR SHALL be signed and MAY be encrypted.

Replace with:

(...) which allows the request to be JAR to be signed and optionally encrypted (...)


As far as the integrity protection is concerned, JWE covers it. 
For the source authentication, if the JWE uses symmetric key, it is also covered. 
So, JWS is not always required.  

 

 

2) On page 9 the text states:

The authorization request object MUST be either

   (a)  JWS signed; or

   (b)  JWE encrypted; or

   (c)  JWS signed and JWE encrypted.

 

This should be replaced by:

The authorization request object MUST be either

   (a)  JWS signed;

   (b)  JWE encrypted (when secret keys are being used); or

   (c)  JWS signed and JWE encrypted.


That's acceptable. (Thanks for amending your proposal after several private exchanges.)  

 

4) On page 14, in section 6.3, the text states:

    the Authorization Server then validates the request as specified in OAuth 2.0 [RFC6749].


This is rather vague, since no specific section from RFC 6749 is being pointed at.
RFC 6749 is a framework with many options.
In the context of this draft, it would be beneficial to indicate which kind processing of the JAR parameters shall be done by the Authorization Server.
This issue clearly relates to the first major issue: interoperability.

Indeed it would be beneficial, but is also error prone. The implementer of this document needs to consult RFC6749 closely anyways as all the verificaiton requirements still holds, so as an editor, I would rather keep it as it is. It is not "reader friendly" but cannot go wrong with the approach to just referencing RFC6749. 

Nat  


Denis



_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--

Nat Sakimura

Chairman of the Board, OpenID Foundation


--------------83DC042B56BB47B767DCE129-- From nobody Fri Jan 6 13:25:53 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0501129F16 for ; Fri, 6 Jan 2017 13:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHAN9W7SAMyP for ; Fri, 6 Jan 2017 13:25:49 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 034B9129F15 for ; Fri, 6 Jan 2017 13:25:49 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id v23so90224312qtb.0 for ; Fri, 06 Jan 2017 13:25:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l+Ern7yHBFRELKNeBg61EhASs2oSd8BHR16xCZ2EMLg=; b=ag0pErTUIn4OGP9n6ZGlDuCYgJ1ZNwP3V+iZj0kqrmSdMgSUfCLpYVbarZcWgfhYMZ 1Ff2UsvGBHR+zP2PVUB0yDY9CdBSIBwmjUuWhrcN+2LryEhURPgLe9C/Rzhwhy+HAxU+ jge2FYtVaOD8bLGCn52Ej23iFP9wm4iZsHltjFLGNa2wrg72LVu/WtFIrdQHHVOp7GED l94i7ZtFWU4OaJyFzsArZQcfkEWDyxeL3lemCiLkIFQH4NsSxBetkvf4OfIJ/o73gtDS 1mtXBWI4uLZ6mwPZqOf24eFPdlQdyVp0f1nafSXMGwL7ATYCi5o5hIY7LD0+sZsBRqgB wVTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l+Ern7yHBFRELKNeBg61EhASs2oSd8BHR16xCZ2EMLg=; b=F2meyaEuColS3P/GU4YL7zCB63ms9SAoByfdmf2xyW5byaO0nWie0jH8mVXoHc1FoW PDL24BMeiMdttfbwcwVsHUIgiwqAzQv+H2M5ioMbO/6xt4SPllMaJvmsc4XQAbk+QKFQ CAoyFNX56t0pZqRBJUDv6tscAksWXpfYkNogS/De9CZnHZSBg32vgfwKq5F5v/TneRQ7 fyOh3UzoBnKfaOm7z3cGlK1lm8XrFynI2Dq2D2LjVsKEM2RfogKKUkoESXxdDXG9Fn4s n2Cc/1k2CbO5aCcKV0mIAt/ngjeFPZDVuOBhpduXa62nDUJgXhkryOK70zrtX8mfxYB0 lZqQ== X-Gm-Message-State: AIkVDXI69F1YHL88xswfdTLF09Jsq+CuXDej7oyRsDa08Az+1p/jSxAVqcQx1OjZjohz96HGvTyB9PP3cSNAdg== X-Received: by 10.200.42.106 with SMTP id l39mr71809877qtl.280.1483737948150; Fri, 06 Jan 2017 13:25:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.161.101 with HTTP; Fri, 6 Jan 2017 13:25:47 -0800 (PST) In-Reply-To: References: From: Kathleen Moriarty Date: Fri, 6 Jan 2017 16:25:47 -0500 Message-ID: To: Nat Sakimura Content-Type: multipart/alternative; boundary=001a114789c456df23054573a921 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] AD review of draft-ietf-oauth-jwsreq X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 21:25:51 -0000 --001a114789c456df23054573a921 Content-Type: text/plain; charset=UTF-8 Hello, I have added this document to the telechat on 2/2 and can bump it out further if needed. The comments that are outstanding should be addressed and a new draft published. Once there is agreement on the updates and the version has been published, I'll start IETF last call. Thank you & happy new year! Kathleen On Wed, Dec 28, 2016 at 11:27 AM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hi Nat, > > Thank you for the updates. Please let me know when you publish a new > version. I'll start last call after the new year. inline. > > On Tue, Dec 27, 2016 at 7:57 PM, Nat Sakimura wrote: > >> Hi >> >> Sorry to have taken so long to respond -- too much travel. >> > > I hope you are able to rest a bit! > > >> >> My responses inline. >> >> On Sat, Oct 29, 2016 at 12:39 AM Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> wrote: >> >>> Hello, >>> >>> I just reviewed draft-ietf-oauth-jwsreq, and it looks great and seems to >>> be a nice addition to help with security. Thanks for your work on it. >>> >>> I only have a few comments. >>> >>> The first is just about some wording that is awkward in the TLS section. >>> >>> What's there now: >>> >>> Client implementations supporting the Request Object URI method MUST >>> support TLS as recommended in Recommendations for Secure Use of >>> Transport Layer Security (TLS) and Datagram Transport Layer Security >>> (DTLS) [RFC7525]. >>> >>> How about: >>> >>> Client implementations supporting the Request Object URI method MUST >>> support TLS following Recommendations for Secure Use of >>> Transport Layer Security (TLS) and Datagram Transport Layer Security >>> (DTLS) [RFC7525]. >>> >>> Not a major change and just editorial, so take it or leave it. >>> >> >> Accepted as presented in my personal copy. >> See: https://bitbucket.org/Nat/oauth-jwsreq/commits/0de915b22f13 >> >> >>> >>> 2. In section 10, the introduction sentence leaves me wondering where >>> the additional attacks against OAuth 2.0 should also have a pointer in this >>> sentence: >>> >>> In addition to the all the security considerations discussed in OAuth >>> 2.0 [RFC6819], the following security considerations should be taken >>> into account. >>> >>> >>> >> An IETF document about them has not been adopted yet. Shall I just add a >> sentence or two describing the threats that each sub-sections are dealing >> with? Or shall I point to the research papers that I was reading? (Some of >> them are not freely available though.) >> > > Any document that describes them will likely be an 'updates' to the OAuth > spec, so we should be okay. Is the WG likely to adopt a draft soon? If > so, we could wait to start IETF last call. > > >> >>> 3. Nit: in first line of 10.4: >>> >>> Although this specification does not require them, researchs >>> >>> s/researchs/researchers/ >>> >> >> In fact, I meant either "research" or "researches" as I was not pointing >> to persons but rather the work done by them. >> I fixed it as "research" in my personal copy. >> See: https://bitbucket.org/Nat/oauth-jwsreq/commits/0ec83d0c0c36 >> >> >>> 4. I'm sure you'll be asked about the following: >>> >>> ISO/IEC 29100 >>> [ISO29100] is a freely accessible International Standard and its >>> Privacy Principles are good to follow. >>> >>> What about the IETF privacy considerations for protocols, RFC6973, were >>> they also considered? I think you are covering what's needed, but no >>> mention of it and favoring an ISO standard seems odd., using both is fine. >>> >> >> Good point. ISO/IEC 29100 is a high level document so the coverage is >> wider but does not get into concrete details where as RFC6973 gives more >> concrete guidance. They complement each other. I have added a paragraph >> about RFC6873 in my personal copy. >> >> See: https://bitbucket.org/Nat/oauth-jwsreq/commits/9030e1be5cac >> >> > I think you've covered the important privacy considerations from 6973, so > the statement added on it should make that clear so the reader knows you've > done the work for them already. > > Please let me know when the update has been posted. > > Thank you, > Kathleen > >> >>> Thank you. >>> -- >>> >>> Best regards, >>> Kathleen >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org >>> https://www.ietf.org/mailman/listinfo/oauth >>> >> -- >> >> Nat Sakimura >> >> Chairman of the Board, OpenID Foundation >> > > > > -- > > Best regards, > Kathleen > -- Best regards, Kathleen --001a114789c456df23054573a921 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I have added this document to th= e telechat on 2/2 and can bump it out further if needed.=C2=A0 The comments= that are outstanding should be addressed and a new draft published.=C2=A0 = Once there is agreement on the updates and the version has been published, = I'll start IETF last call.

Thank you & hap= py new year!
Kathleen

<= div class=3D"gmail_quote">On Wed, Dec 28, 2016 at 11:27 AM, Kathleen Moriar= ty <kathleen.moriarty.ietf@gmail.com> wrote:<= br>
Hi Nat,

Thank you for the updates.=C2=A0 Please let me know when you publish a n= ew version.=C2=A0 I'll start last call after the new year. =C2=A0inline= .

On Tue, Dec 27, 2016 at 7:57 PM, Nat Sakimura <= sakimura@gmail.com<= /a>> wrote:
Hi=

Sorry to have taken so long to respond -- too much trav= el.=C2=A0

=C2=A0

My responses inline.= =C2=A0

Hello,

I just reviewed draft-iet= f-oauth-jwsreq, and it looks great and seems to be a nice addition to help = with security.=C2=A0 Thanks for your work on it.

I only have a few comments.

The first is just about so= me wording that is awkward in the TLS section.

What's there now:
Client impl=
ementations supporting the Request Object URI method MUST
   support TLS as recommended in Recommendations for Secure Use of
   Transport Layer Security (TLS) and Datagram Transport Layer Security
   (DTLS) [RFC7525].
How about:
Client implementations supporting t=
he Request Object URI method MUST
   support TLS following Recommendations for Secure Use of
   Transport Layer Security (TLS) and Datagram Transport Layer Security
   (DTLS) [RFC7525].
Not a major change and just editorial, so take it o= r leave it.

Accept= ed as presented in my personal copy.=C2=A0
=C2=A0

2. In section 10, the introdu= ction sentence leaves me wondering where the additional attacks against OAu= th 2.0 should also have a pointer in this sentence:

   In addition to the all=
 the security considerations discussed in OAuth
   2.0 [RFC6819], the following security considerations should be taken
   into account.



=C2=A0
3. Nit: in first line of 10.4:
Although this specification does=
 not require them, researchs
s/researchs/researchers/
<= /blockquote>

In fact, I meant either "resear= ch" or "researches" as I was not pointing to persons but rat= her the work done by them.=C2=A0
I fixed it as "research&quo= t; in my personal copy.=C2=A0
=


4. I'm sure you'll be asked about the follow= ing:
   ISO/IEC 29100
   [ISO29100] is a freely accessible International Standard and its
   Privacy Principles are good to follow.
What about the IETF privacy co= nsiderations for protocols, RFC6973, were they also considered?=C2=A0 I thi= nk you are covering what's needed, but no mention of it and favoring an= ISO standard seems odd., using both is fine.=C2=A0

Good point. ISO/IEC 29100 is a high level= document so the coverage is wider but does not get into concrete details w= here as RFC6973 gives more concrete guidance.=C2=A0 They complement each ot= her. I have added a paragraph about RFC6873 in my personal copy.=C2=A0



I think you've covered the im= portant privacy considerations from 6973, so the statement added on it shou= ld make that clear so the reader knows you've done the work for them al= ready.

Please let me know when the update has been= posted.

Thank you,
Kathleen=C2=A0
=

Thank you.
--

Best regards,
Kathleen
 _______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--

Nat Sakimura

Chairman of the Board, OpenID Foundation




--

Best regards,
Kathleen



--
Best regards,
Kathleen
--001a114789c456df23054573a921-- From nobody Wed Jan 11 11:00:47 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2213E1296FD; Wed, 11 Jan 2017 11:00:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148416124213.8244.5842562779051799977.idtracker@ietfa.amsl.com> Date: Wed, 11 Jan 2017 11:00:42 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 19:00:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : OAuth 2.0 Token Exchange Authors : Michael B. Jones Anthony Nadalin Brian Campbell John Bradley Chuck Mortimore Filename : draft-ietf-oauth-token-exchange-07.txt Pages : 31 Date : 2017-01-11 Abstract: This specification defines a protocol for an HTTP- and JSON- based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 11 11:05:26 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A508E129D76 for ; Wed, 11 Jan 2017 11:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxQ7vlDTDgkS for ; Wed, 11 Jan 2017 11:05:23 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 342E712996C for ; Wed, 11 Jan 2017 11:05:23 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id v96so736739ioi.0 for ; Wed, 11 Jan 2017 11:05:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=VnfFEUtvm80dReh1uwpV7NM/vVHPtGomT1Pew0yDE0k=; b=IHqJ0k8fTw/cej5vNhgXTN3BMwoaU95Q2QiyK4NfMYCQktB+hYuZIV4pZg54AtPZ+m XQSdGWu2/4jLNeDQvwdYmDtuqp6Fqx7gqR8VWE5qy8+9xTdmMsx7M9S5NsVr8R/Yrtqb 3LOfcW4RIBVuu2bJdg7hnT+bm/p2sKR8xCN+0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=VnfFEUtvm80dReh1uwpV7NM/vVHPtGomT1Pew0yDE0k=; b=dg6zMmFWx7HLVqV8NWpgg6C0e+nPJPZjzH9I81IiNbhN5WBw17Cx5i8sbSL0oHauzW 6PztpxHDYJDn3MSgNLgs3q642ivZjgzPk+rwuWxifAS0z8OApm6igzCLmiHjb82uy58h q9c/wzMp1JIngTAZ4MrkKBDQ56PWlaoUDxCg7e54RUn9XG1xaskWkJzX1/tQFRRc4CtM VnWv1Tb77FuwWUA3KeoXR8FdctA9l5ueOTUtriVeVey7W8xcEZ8WwVwCobFhNBCSMgNu bTQhySepJOnUpsPlgHnn1nj7ECtN5ho8LGkuU2H8V6zQNnC7Zr1lUJ4CkyonN0TbeyDt z8iw== X-Gm-Message-State: AIkVDXJYhKtwZ0T93eu9gj2UtB8LN+oWuROE8EMeKKHKkYMW45pobarLdKA23nNUVBYy2Pej7UllY/74OGRICH9j X-Received: by 10.107.181.213 with SMTP id e204mr9715885iof.156.1484161522164; Wed, 11 Jan 2017 11:05:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.31.5 with HTTP; Wed, 11 Jan 2017 11:04:51 -0800 (PST) In-Reply-To: <148416124213.8244.5842562779051799977.idtracker@ietfa.amsl.com> References: <148416124213.8244.5842562779051799977.idtracker@ietfa.amsl.com> From: Brian Campbell Date: Wed, 11 Jan 2017 12:04:51 -0700 Message-ID: To: oauth Content-Type: multipart/alternative; boundary=001a11444e645181430545d648cc Archived-At: Subject: [OAUTH-WG] Fwd: I-D Action: draft-ietf-oauth-token-exchange-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 19:05:24 -0000 --001a11444e645181430545d648cc Content-Type: text/plain; charset=UTF-8 Draft -07 of "OAuth 2.0 Token Exchange" has been published. The primary change in -07 is the addition of a description of the relationship between audience/resource/scope, which was a request or comment that came up during the f2f meeting in Seoul. Excerpted from the Document History: -07 o Fixed typo (desecration -> discretion). o Added an explanation of the relationship between scope, audience and resource in the request and added an "invalid_target" error code enabling the AS to tell the client that the requested audiences/resources were too broad. ---------- Forwarded message ---------- From: Date: Wed, Jan 11, 2017 at 12:00 PM Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-token-exchange-07.txt To: i-d-announce@ietf.org Cc: oauth@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : OAuth 2.0 Token Exchange Authors : Michael B. Jones Anthony Nadalin Brian Campbell John Bradley Chuck Mortimore Filename : draft-ietf-oauth-token-exchange-07.txt Pages : 31 Date : 2017-01-11 Abstract: This specification defines a protocol for an HTTP- and JSON- based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-token-exchange/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-token-exchange-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-token-exchange-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --001a11444e645181430545d648cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Draft -07 of "OAuth 2.0 Token Exchange" has been published. The primary change in -07 is the addition of a=20 description of the relationship between audience/resource/scope, which=20 was a request or comment that came up during the f2f meeting in Seoul.
=
Excerpted from the Document History:

=C2=A0=C2=A0 -07

=C2= =A0=C2=A0 o=C2=A0 Fixed typo (desecration -> discretion).
=C2=A0=C2= =A0 o=C2=A0 Added an explanation of the relationship between scope, audienc= e
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and resource in the request and added a= n "invalid_target" error
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 code e= nabling the AS to tell the client that the requested
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 audiences/resources were too broad.


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Da= te: Wed, Jan 11, 2017 at 12:00 PM
Subject: [OAUTH-WG] I-D Action: draft-= ietf-oauth-token-exchange-07.txt
To: i-d-announce@ietf.org
Cc: oauth@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Web Authorization Protocol of the IETF.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= OAuth 2.0 Token Exchange
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Mich= ael B. Jones
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Anthony Nadalin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Brian Campbell
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 John Bradley
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Chuck Mortimore
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-oauth-token-exchange-07.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 31
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2017-01-11

Abstract:
=C2=A0 =C2=A0This specification defines a protocol for an HTTP- and JSON- b= ased
=C2=A0 =C2=A0Security Token Service (STS) by defining how to request and ob= tain
=C2=A0 =C2=A0security tokens from OAuth 2.0 authorization servers, includin= g
=C2=A0 =C2=A0security tokens employing impersonation and delegation.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/d= oc/draft-ietf-oauth-token-exchange/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft= -ietf-oauth-token-exchange-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?u= rl2=3Ddraft-ietf-oauth-token-exchange-07


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--001a11444e645181430545d648cc-- From nobody Tue Jan 17 13:31:20 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A7D1295BF; Tue, 17 Jan 2017 13:31:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148468867753.32039.3798518747167094319.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2017 13:31:17 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-native-apps-07.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 21:31:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : OAuth 2.0 for Native Apps Authors : William Denniss John Bradley Filename : draft-ietf-oauth-native-apps-07.txt Pages : 19 Date : 2017-01-17 Abstract: OAuth 2.0 authorization requests from native apps should only be made through external user-agents, primarily the user's browser. This specification details the security and usability reasons why this is the case, and how native apps and authorization servers can implement this best practice. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-native-apps/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-native-apps-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-native-apps-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 19 19:43:34 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95827127A90; Thu, 19 Jan 2017 19:43:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148488381360.10528.2802092608903679978.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2017 19:43:33 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-discovery-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 03:43:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : OAuth 2.0 Authorization Server Metadata Authors : Michael B. Jones Nat Sakimura John Bradley Filename : draft-ietf-oauth-discovery-05.txt Pages : 23 Date : 2017-01-19 Abstract: This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-discovery/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-discovery-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-discovery-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 19 19:49:42 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D16D41297AA for ; Thu, 19 Jan 2017 19:49:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKav1phfbuNJ for ; Thu, 19 Jan 2017 19:49:38 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0138.outbound.protection.outlook.com [104.47.34.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DAB71293F3 for ; Thu, 19 Jan 2017 19:49:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Dqj3WzMxAs40dZc1gJn7bitlrh41DSzdsLwjP93hFhE=; b=KyntSKWiKOwKhFlc8tH/PfW/kEqHoQ2OFKAF3MsFeEKvHH9QCw0+h0jhk7o+HgkM1MpxxE55b9BBPCUM192EDo+spR7yC7Ao4vToZRXFKP6z3d+VokuHxi8basE+ycHcZvoFTtCRC/r/vmclulCHYgWQyCP6lrs9dgqfomYVqtQ= Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by BN3PR03MB2356.namprd03.prod.outlook.com (10.166.74.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Fri, 20 Jan 2017 03:49:37 +0000 Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0860.012; Fri, 20 Jan 2017 03:49:36 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: OAuth Authorization Server Metadata decoupled from OAuth Protected Resource Metadata Thread-Index: AdJyya2Gn4+3XYXBT9CpRAxeTBHohg== Date: Fri, 20 Jan 2017 03:49:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [50.47.95.25] x-ms-office365-filtering-correlation-id: 8e1d73f9-3d2a-40e1-ed53-08d440e75ab4 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN3PR03MB2356; x-microsoft-exchange-diagnostics: 1; BN3PR03MB2356; 7:aYwJ/cKvYBwu59c035ep3iuVriop2WJ4wfKpl+GKKfiRDUIGde2tPBX7jbMYRWohoIKTvIxpAlr0M4mzAOVHQOqd4d1Hl/ajkKrzJ1oTrv0n3hzPWuWewLdME7amUiTXWXjs4SMXakJNk5IOtpGnuW8m3TMOZsbkB0R4CSLyrC/Y2mMFwYmPBMVPDQdkJeiyMeNJl3HrhTSapwLqxr/Vh2gEg7jZy0z7QoBO/nmCvdHXp7xrzAZMCni6MHmazm5ygM2cUA4CTVYUhGoY+3goKqek3lg4re3zXf1SlY2ol6tsJSFPMcQAeVzqxwleM7H/uShozHWAxIPNkoe8wnvyOoZm/3wStW721Px9+/ciUpbrCe7BxGXXiNAn/IABgXz7EbL+bnUxHkXx3UHRolHTmjhgK53QnbAoi0+hhybY2Xp9j9y9EvYnCcX35lHgbVjomb53uXnKCKOT/lD/UXYhAvPJPX/TWa+M8HNlWPzcQ9I= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(31418570063057)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123564025)(20161123558021)(20161123555025)(20161123562025)(6042181)(6047074)(6072148); SRVR:BN3PR03MB2356; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2356; x-forefront-prvs: 01930B2BA8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(209900001)(199003)(189002)(50986999)(450100001)(7696004)(2501003)(5640700003)(25786008)(606005)(6436002)(2900100001)(122556002)(3660700001)(92566002)(6916009)(66066001)(2906002)(101416001)(54356999)(236005)(110136003)(5630700001)(10090500001)(107886002)(8676002)(8936002)(189998001)(10290500002)(81156014)(3846002)(86612001)(102836003)(6116002)(5660300001)(790700001)(97736004)(1730700003)(105586002)(5005710100001)(3280700002)(81166006)(6306002)(38730400001)(53936002)(55016002)(99286003)(9686003)(54896002)(6506006)(77096006)(106356001)(2351001)(7736002)(86362001)(7906003)(8990500004)(74316002)(33656002)(68736007)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2356; H:BN3PR03MB2355.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB235566CEFD5DB4C882F3B4A3F5710BN3PR03MB2355namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2017 03:49:36.7139 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2356 Archived-At: Subject: [OAUTH-WG] OAuth Authorization Server Metadata decoupled from OAuth Protected Resource Metadata X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 03:49:41 -0000 --_000_BN3PR03MB235566CEFD5DB4C882F3B4A3F5710BN3PR03MB2355namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The IETF OAuth working group decided at IETF 97 to proceed with standardizi= ng the OAuth Authorization Server Metadata specification, which is already = in widespread use, and to stop work on the OAuth Protected Resource Metadat= a specification, which is more speculative. Accordingly, a new version of = the AS Metadata spec has been published that removes its dependencies upon = the Resource Metadata spec. In particular, the "protected_resources" AS Me= tadata element has been removed. Its definition has been moved to the Reso= urce Metadata spec for archival purposes. Note that the Resource Metadata = specification authors intend to let it expire unless the working group deci= des to resume work on it at some point in the future. The specifications are available at: * https://tools.ietf.org/html/draft-ietf-oauth-discovery-05 * https://tools.ietf.org/html/draft-jones-oauth-resource-metadata-01 HTML-formatted versions are also available at: * http://self-issued.info/docs/draft-ietf-oauth-discovery-05.html * http://self-issued.info/docs/draft-jones-oauth-resource-metadata-01.h= tml -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1629 and = as @selfissued. --_000_BN3PR03MB235566CEFD5DB4C882F3B4A3F5710BN3PR03MB2355namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The IETF OAuth working group decided at IETF 97 to p= roceed with standardizing the OAuth Authorization Server Metadata specifica= tion, which is already in widespread use, and to stop work on the OAuth Pro= tected Resource Metadata specification, which is more speculative.  Accordingly, a new version of the AS Meta= data spec has been published that removes its dependencies upon the Resourc= e Metadata spec.  In particular, the “protected_resources” AS Metadata element has been removed.  Its definition has been moved to the Resou= rce Metadata spec for archival purposes.  Note that the Resource Metad= ata specification authors intend to let it expire unless the working group = decides to resume work on it at some point in the future.

 

The specifications are available at:

 

HTML-formatted versions are also available at:<= /o:p>

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;        -- Mike

 

P.S.  This notice was also posted at http://self-issued.info/?p=3D1629 and as @selfissued.

 

--_000_BN3PR03MB235566CEFD5DB4C882F3B4A3F5710BN3PR03MB2355namp_-- From nobody Tue Jan 24 10:13:25 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFBE1295CE; Tue, 24 Jan 2017 10:13:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joel Halpern To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148528159990.12590.4203267942543391577.idtracker@ietfa.amsl.com> Date: Tue, 24 Jan 2017 10:13:19 -0800 Archived-At: Cc: ietf@ietf.org, draft-ietf-oauth-jwsreq.all@ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Review of draft-ietf-oauth-jwsreq-09 X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 18:13:20 -0000 Reviewer: Joel Halpern Review result: Not Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at . Document: draft-ietf-oauth-jwsreq-?? Reviewer: Joel Halpern Review Date: 2017-01-24 IETF LC End Date: None IESG Telechat date: 2017-02-02 Summary: This document is not ready for publication as a standards track RFC. [Reviewers note: It is quite possible that the problem listed below is my error. In that case, this should be considered as ready with minor issues.] Major issues: I can not find any record of an IETF last call for this document. I looked in the document history and the IETF discussion list. If I missed it, I apologize for being oblivious. Minor issues: Why is the example if section 4 (and others later on) described as "non-normative"? Is it incomplete? incorrect? An example is, by definition, not a full specification. The language seems designed to reduce the value of the example. I would recommend removing all the "non-normative" notes from the examples. They are clearly stated to be examples. Nits/editorial comments: From nobody Tue Jan 24 12:48:58 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B53B129795; Tue, 24 Jan 2017 12:48:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148529093310.12606.14313388365821793062.idtracker@ietfa.amsl.com> Date: Tue, 24 Jan 2017 12:48:53 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-amr-values-05.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 20:48:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : Authentication Method Reference Values Authors : Michael B. Jones Phil Hunt Anthony Nadalin Filename : draft-ietf-oauth-amr-values-05.txt Pages : 14 Date : 2017-01-24 Abstract: The "amr" (Authentication Methods References) claim is defined and registered in the IANA "JSON Web Token Claims" registry but no standard Authentication Method Reference values are currently defined. This specification establishes a registry for Authentication Method Reference values and defines an initial set of Authentication Method Reference values. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-amr-values-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-amr-values-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 24 12:54:16 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0F21297B8 for ; Tue, 24 Jan 2017 12:54:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.157 X-Spam-Level: X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tksXwHRO-LbT for ; Tue, 24 Jan 2017 12:54:13 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0139.outbound.protection.outlook.com [104.47.38.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2562A129762 for ; Tue, 24 Jan 2017 12:54:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pxhhYSAGZlYpAjxBrhFN5RPyy1EQyHPV6j1MqbbCTfs=; b=DPm9NL2xwQt73JfiNg8azJj0OoOY4qvgS+f4ljd2srmjvIStWTLdW427gwR9HCwOn0n9tUKEzuWu8kx1vD8UNz/gJsj+AmtJKnpQfPnco696Nz3CIsy9UjzfkfS8D51rk5xeGp278j9CG8ptEIiBg75+S5eCQcaZvoYSF5P4PZA= Received: from BN3PR03MB2355.namprd03.prod.outlook.com (10.166.74.150) by BN3PR03MB2356.namprd03.prod.outlook.com (10.166.74.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Tue, 24 Jan 2017 20:54:10 +0000 Received: from BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) by BN3PR03MB2355.namprd03.prod.outlook.com ([10.166.74.150]) with mapi id 15.01.0860.021; Tue, 24 Jan 2017 20:54:10 +0000 From: Mike Jones To: "oauth@ietf.org" Thread-Topic: =?Windows-1252?Q?=93amr=94_Values_specification_addressing_IETF_last_call?= =?Windows-1252?Q?_comments?= Thread-Index: AdJ2fYYBrnFRfLL+TaGIMzxadTS+Hw== Date: Tue, 24 Jan 2017 20:54:10 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-originating-ip: [64.114.255.114] x-ms-office365-filtering-correlation-id: fcd0c955-bc2f-49cb-cde6-08d4449b258d x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN3PR03MB2356; x-microsoft-exchange-diagnostics: 1; BN3PR03MB2356; 7:HVZXUxwI48DBOkMVbDt99DbyptfPx+WbqP9OcmnF4GVjoT6JgUlPUSGElQOgXhr84wtOicDMdQpgZ+l4sxqpj/lRUO4J6cwvY7r4bTiDZU9EPtJSeE+usHJ4cINM2OuqxMJTmN4AvHSyZYDueopHQ4qNW30xq4C9N7t3sN0wd17kL69hiQCE2etULCsLzZK8+NCIN4RWozSc5jOQKb5YbcddqR3sTFJ1ZPPpo/QXML2VEwrhwemBjxkdnZ7THEokP6XNKFzTCrYr2ifQssPYa/Pm05pr9MogBCsG9GOjt+CZ0cdAUFPxfGgRTtwCVkdDXlYb2t0D9/fT9lG1OcPQCJHCYyCr8tTbMwDUGBnIO8vCbN1Mx1j6vwYhAw0Qy6+xyT3DeJPZQYQGjRc/SKmWSDYt4rop+lkkJ7nTVaWGhiEpq1Vq8jHvtm8wFdnP23tqTRa+rn5R0bjOQoCisMcGsCNiXaJeKxzr+SSjDxH2M8w= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(31418570063057)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123558021)(20161123562025)(20161123555025)(20161123564025)(6042181)(6047074)(6072148); SRVR:BN3PR03MB2356; BCL:0; PCL:0; RULEID:; SRVR:BN3PR03MB2356; x-forefront-prvs: 0197AFBD92 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(209900001)(199003)(189002)(10290500002)(5005710100001)(99286003)(790700001)(236005)(189998001)(8990500004)(122556002)(10090500001)(55016002)(2900100001)(5660300001)(3280700002)(54906002)(53936002)(92566002)(6116002)(25786008)(5640700003)(102836003)(6436002)(606005)(97736004)(3846002)(39060400001)(77096006)(6506006)(2501003)(38730400001)(101416001)(86612001)(5630700001)(8936002)(33656002)(3660700001)(74316002)(9686003)(54896002)(6306002)(106356001)(7736002)(81156014)(2351001)(68736007)(86362001)(66066001)(2906002)(1730700003)(105586002)(4326007)(7696004)(110136003)(6916009)(50986999)(54356999)(7906003)(81166006)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR03MB2356; H:BN3PR03MB2355.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR03MB2355162E4B9F34A024B829EEF5750BN3PR03MB2355namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2017 20:54:10.4600 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR03MB2356 Archived-At: Cc: "Catherine Meadows \(catherine.meadows@nrl.navy.mil\)" , "Paul Kyzivat \(pkyzivat@alum.mit.edu\)" , Linda Dunbar Subject: [OAUTH-WG] =?windows-1252?q?=93amr=94_Values_specification_addres?= =?windows-1252?q?sing_IETF_last_call_comments?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 20:54:15 -0000 --_000_BN3PR03MB2355162E4B9F34A024B829EEF5750BN3PR03MB2355namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Draft -05 of the Authentication Method Reference Values specification addre= sses the IETF last call comments received. Changes were: * Specified characters allowed in =93amr=94 values, reusing the IANA Co= nsiderations language on this topic from RFC 7638. * Added several individuals to the acknowledgements. Thanks to Linda Dunbar, Catherine Meadows, and Paul Kyzivat for their revie= ws. The specification is available at: * http://tools.ietf.org/html/draft-ietf-oauth-amr-values-05 An HTML-formatted version is also available at: * http://self-issued.info/docs/draft-ietf-oauth-amr-values-05.html -- Mike P.S. This notice was also posted at http://self-issued.info/?p=3D1631 and = as @selfissued. --_000_BN3PR03MB2355162E4B9F34A024B829EEF5750BN3PR03MB2355namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Draft -05 of the Authentication Method Reference Val= ues specification addresses the IETF last call comments received.  Cha= nges were:

  • Specified characters allowed in =93amr=94 values, reusing the IANA Considerations lan= guage on this topic from RFC 7638.
  • Added several indiv= iduals to the acknowledgements.

 

Thanks to Linda Dunbar, Catherine Meadows, and Paul = Kyzivat for their reviews.

 

The specification is available at:

 

An HTML-formatted version is also available at:=

 

        &nbs= p;             =             &nb= sp;            =         -- Mike

 

P.S.  This notice was also posted at http://self-issued.info/?p=3D1631 and as @selfissued.

--_000_BN3PR03MB2355162E4B9F34A024B829EEF5750BN3PR03MB2355namp_-- From dario.teixeira@nleyten.com Wed Jan 25 06:22:38 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35E0512995D for ; Wed, 25 Jan 2017 06:22:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFUUBRR4QvE2 for ; Wed, 25 Jan 2017 06:22:37 -0800 (PST) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 099B712995C for ; Wed, 25 Jan 2017 06:22:37 -0800 (PST) Received: from mfilter1-d.gandi.net (mfilter1-d.gandi.net [217.70.178.130]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 151F2C5A4E for ; Wed, 25 Jan 2017 15:22:35 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter1-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter1-d.gandi.net (mfilter1-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id ODt-shBfLg1X for ; Wed, 25 Jan 2017 15:22:31 +0100 (CET) X-Originating-IP: 10.58.1.149 Received: from webmail.gandi.net (webmail9-d.mgt.gandi.net [10.58.1.149]) (Authenticated sender: dario.teixeira@nleyten.com) by relay2-d.mail.gandi.net (Postfix) with ESMTPA id AF212C5A55 for ; Wed, 25 Jan 2017 15:22:31 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 25 Jan 2017 14:22:31 +0000 From: Dario Teixeira To: oauth@ietf.org Message-ID: X-Sender: dario.teixeira@nleyten.com User-Agent: Roundcube Webmail/1.1.2 Archived-At: Subject: [OAUTH-WG] OAuth2/OIDC for client-server mobile app X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 15:59:24 -0000 Hi, I am building a mobile app and a server. The mobile app fetches user-specific data from the server, and therefore some sort of authentication is required. I would like to avoid the traditional username+password scheme, and instead allow users to login via Google or Facebook. It seems the OAuth2-based OpenID Connect (OIDC) is the recommended solution nowadays, so my question is about the usage of OAuth2/OIDC in this scenario. All OIDC docs and tutorials describe the interaction between three parties: a Relying Party (RP), a User Agent (UA), and an OIDC Provider (OIP). There are however four parties in my scenario: the mobile app, the server, the UA, and the OIP. Which should take the role of RP? I see two different ways to do this: 1) The mobile app is the RP. It even takes care of starting a small web server to receive the data from the OIP. At the end of the interaction, the mobile app has a JWT signed by the OIP, which it sends to the server, which must validate it using a built-in list of OIP public signatures. 2) The server is the RP. When the user wishes to login, the mobile app asks the server about the OIP's authorization endpoint. The server provide the client with an URI whose redirect_uri parameter points to the server. All subsequent steps are handled by the server. Anyway, this seems like a fairly common scenario, and I would rather follow some best-practices documentation instead of cooking up my own schemes, like points 1 and 2 above. Therefore, if there is indeed such documentation, could someone please point me towards it? And if not, which would be the recommended route, 1 or 2? Thanks in advance for your attention! Best regards, Dario Teixeira From nobody Wed Jan 25 10:26:49 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9A6B129AC8 for ; Wed, 25 Jan 2017 10:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhewJX__Y7AL for ; Wed, 25 Jan 2017 10:26:46 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28F82129AC9 for ; Wed, 25 Jan 2017 10:26:46 -0800 (PST) X-AuditID: 12074422-29fff70000005b19-3d-5888ede569c3 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 04.D9.23321.5EDE8885; Wed, 25 Jan 2017 13:26:45 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v0PIQihP026638; Wed, 25 Jan 2017 13:26:44 -0500 Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v0PIQgHX006704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 25 Jan 2017 13:26:44 -0500 To: Dario Teixeira , oauth@ietf.org References: From: Justin Richer Message-ID: <2fc78923-95a7-7def-3d59-65231f43ad0b@mit.edu> Date: Wed, 25 Jan 2017 13:26:36 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixG6nrvv0bUeEwd5vvBYtF3pYLE6+fcXm wOSxZMlPJo+u9tssAUxRXDYpqTmZZalF+nYJXBnrp/kWzBWqOHjoFksD43q+LkYODgkBE4k/ cyW7GLk4hATamCROXpjGCuFsZJT49HUlM4Rzh0niysZJjF2MnBzCAg4Sc3+8ZwPpFhGwl9i7 vQYkLCRgJdHS0cUKYrMJqEpMX9PCBGLzAsU3nvjEDmKzAMXPv3nODGKLCsRIvF2/nB2iRlDi 5MwnLCA2p4C1RNuR42A1zAK2Enfm7oay5SW2v53DPIGRfxaSlllIymYhKVvAyLyKUTYlt0o3 NzEzpzg1Wbc4OTEvL7VI11QvN7NELzWldBMjOBhdlHYwTvzndYhRgINRiYc3Y1tHhBBrYllx Ze4hRkkOJiVR3lOngEJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeH+8AsrxpiRWVqUW5cOkpDlY lMR5xTUaI4QE0hNLUrNTUwtSi2CyMhwcShK8IW+AGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGi4DU 8BYXJOYWZ6ZD5E8x6nJsuHXlJZMQS15+XqqUOK86MA0ICYAUZZTmwc0BJZGEt4dNXzGKA70l zLsEZBQPMAHBTXoFtIQJaMkF5naQJSWJCCmpBkYHQwdvFpslTJb6abmB0T/PaAhliS795ili JTqreK3evIqlxg1RFvt9At5yck5IXru1MOLcqZdZwbo/JghceHO6t7sh6La41IE1QsVVBTke Jdt2pwqVdESevWWyL/6jRVv6jSmXL0Y8787imlwx8WF3cPfeR+4x09TcugQXhObEt1gdjhNO UGIpzkg01GIuKk4EAEG0J2f9AgAA Archived-At: Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 18:26:48 -0000 I would recommend making the mobile app the RP, and having the server be an additional protected resource that accepts access tokens from the mobile app. This is how it's commonly handled, and there are libraries (such as Google's AppAuth) that handle most of these interactions. -- Justin On 1/25/2017 9:22 AM, Dario Teixeira wrote: > Hi, > > I am building a mobile app and a server. The mobile app fetches > user-specific data from the server, and therefore some sort of > authentication is required. I would like to avoid the traditional > username+password scheme, and instead allow users to login via > Google or Facebook. It seems the OAuth2-based OpenID Connect (OIDC) > is the recommended solution nowadays, so my question is about the > usage of OAuth2/OIDC in this scenario. > > All OIDC docs and tutorials describe the interaction between three > parties: a Relying Party (RP), a User Agent (UA), and an OIDC > Provider (OIP). There are however four parties in my scenario: > the mobile app, the server, the UA, and the OIP. Which should > take the role of RP? I see two different ways to do this: > > 1) The mobile app is the RP. It even takes care of starting a > small web server to receive the data from the OIP. At the end > of the interaction, the mobile app has a JWT signed by the OIP, > which it sends to the server, which must validate it using a > built-in list of OIP public signatures. > > 2) The server is the RP. When the user wishes to login, the mobile > app asks the server about the OIP's authorization endpoint. > The server provide the client with an URI whose redirect_uri > parameter points to the server. All subsequent steps are > handled by the server. > > Anyway, this seems like a fairly common scenario, and I would rather > follow some best-practices documentation instead of cooking up my > own schemes, like points 1 and 2 above. Therefore, if there is > indeed such documentation, could someone please point me towards it? > And if not, which would be the recommended route, 1 or 2? > > Thanks in advance for your attention! > Best regards, > Dario Teixeira > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From nobody Wed Jan 25 10:33:48 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D4F129AD4 for ; Wed, 25 Jan 2017 10:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.554 X-Spam-Level: X-Spam-Status: No, score=-8.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-1.156, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JE8I3zPWHb0j for ; Wed, 25 Jan 2017 10:33:45 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2F03129AD2 for ; Wed, 25 Jan 2017 10:33:45 -0800 (PST) Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v0PIXhSH002803 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 25 Jan 2017 18:33:44 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v0PIXhQ3003024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 25 Jan 2017 18:33:43 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v0PIXgLN027758; Wed, 25 Jan 2017 18:33:42 GMT Received: from dhcp-whq-twvpn-2-vpnpool-10-159-164-183.vpn.oracle.com (/10.159.164.183) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Jan 2017 10:33:42 -0800 Content-Type: multipart/alternative; boundary="Apple-Mail=_7DC075B2-EA34-49F5-8E14-97C5C7322065" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Phil Hunt In-Reply-To: <2fc78923-95a7-7def-3d59-65231f43ad0b@mit.edu> Date: Wed, 25 Jan 2017 10:33:41 -0800 Message-Id: References: <2fc78923-95a7-7def-3d59-65231f43ad0b@mit.edu> To: Justin Richer X-Mailer: Apple Mail (2.3124) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 18:33:47 -0000 --Apple-Mail=_7DC075B2-EA34-49F5-8E14-97C5C7322065 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii There is a problem here that the endpoint definitions for OpenID Connect = and OAuth are different depending on whether an app is a client to OIDC = OP or OAuth AS. Phil Oracle Corporation, Identity Cloud Services & Identity Standards @independentid www.independentid.com = phil.hunt@oracle.com = > On Jan 25, 2017, at 10:26 AM, Justin Richer wrote: >=20 > I would recommend making the mobile app the RP, and having the server = be an additional protected resource that accepts access tokens from the = mobile app. This is how it's commonly handled, and there are libraries = (such as Google's AppAuth) that handle most of these interactions. >=20 > -- Justin >=20 >=20 > On 1/25/2017 9:22 AM, Dario Teixeira wrote: >> Hi, >>=20 >> I am building a mobile app and a server. The mobile app fetches >> user-specific data from the server, and therefore some sort of >> authentication is required. I would like to avoid the traditional >> username+password scheme, and instead allow users to login via >> Google or Facebook. It seems the OAuth2-based OpenID Connect (OIDC) >> is the recommended solution nowadays, so my question is about the >> usage of OAuth2/OIDC in this scenario. >>=20 >> All OIDC docs and tutorials describe the interaction between three >> parties: a Relying Party (RP), a User Agent (UA), and an OIDC >> Provider (OIP). There are however four parties in my scenario: >> the mobile app, the server, the UA, and the OIP. Which should >> take the role of RP? I see two different ways to do this: >>=20 >> 1) The mobile app is the RP. It even takes care of starting a >> small web server to receive the data from the OIP. At the end >> of the interaction, the mobile app has a JWT signed by the OIP, >> which it sends to the server, which must validate it using a >> built-in list of OIP public signatures. >>=20 >> 2) The server is the RP. When the user wishes to login, the mobile >> app asks the server about the OIP's authorization endpoint. >> The server provide the client with an URI whose redirect_uri >> parameter points to the server. All subsequent steps are >> handled by the server. >>=20 >> Anyway, this seems like a fairly common scenario, and I would rather >> follow some best-practices documentation instead of cooking up my >> own schemes, like points 1 and 2 above. Therefore, if there is >> indeed such documentation, could someone please point me towards it? >> And if not, which would be the recommended route, 1 or 2? >>=20 >> Thanks in advance for your attention! >> Best regards, >> Dario Teixeira >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail=_7DC075B2-EA34-49F5-8E14-97C5C7322065 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii There is a problem here that the endpoint definitions for = OpenID Connect and OAuth are different depending on whether an app is a = client to OIDC OP or OAuth AS.

Phil

Oracle = Corporation, Identity Cloud Services & Identity Standards
@independentid
www.independentid.com
phil.hunt@oracle.com







On Jan 25, 2017, at 10:26 AM, Justin Richer <jricher@mit.edu> = wrote:

I would recommend making the mobile app the RP, and having = the server be an additional protected resource that accepts access = tokens from the mobile app. This is how it's commonly handled, and there = are libraries (such as Google's AppAuth) that handle most of these = interactions.

-- Justin


On 1/25/2017 9:22 AM, Dario Teixeira wrote:
Hi,

I am building a mobile app and a server.  The mobile app = fetches
user-specific data from the server, and therefore = some sort of
authentication is required.  I would = like to avoid the traditional
username+password scheme, = and instead allow users to login via
Google or Facebook. =  It seems the OAuth2-based OpenID Connect (OIDC)
is = the recommended solution nowadays, so my question is about the
usage of OAuth2/OIDC in this scenario.

All OIDC docs and tutorials describe the interaction between = three
parties: a Relying Party (RP), a User Agent (UA), = and an OIDC
Provider (OIP).  There are however four = parties in my scenario:
the mobile app, the server, the = UA, and the OIP.  Which should
take the role of RP? I = see two different ways to do this:

1) The = mobile app is the RP.  It even takes care of starting a
  small web server to receive the data from the = OIP.  At the end
  of the interaction, the = mobile app has a JWT signed by the OIP,
  which = it sends to the server, which must validate it using a
=   built-in list of OIP public signatures.

2) The server is the RP.  When the user wishes to login, = the mobile
  app asks the server about the = OIP's authorization endpoint.
  The server = provide the client with an URI whose redirect_uri
=   parameter points to the server.  All subsequent steps = are
  handled by the server.

Anyway, this seems like a fairly common scenario, and I would = rather
follow some best-practices documentation instead of = cooking up my
own schemes, like points 1 and 2 above. =  Therefore, if there is
indeed such documentation, = could someone please point me towards it?
And if not, = which would be the recommended route, 1 or 2?

Thanks in advance for your attention!
Best = regards,
Dario Teixeira

_______________________________________________
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

= --Apple-Mail=_7DC075B2-EA34-49F5-8E14-97C5C7322065-- From nobody Wed Jan 25 11:48:39 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8466129B67 for ; Wed, 25 Jan 2017 11:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K7fY0G7k3Rvl for ; Wed, 25 Jan 2017 11:48:30 -0800 (PST) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAB53129B3E for ; Wed, 25 Jan 2017 11:48:29 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id 14so66889983pgg.1 for ; Wed, 25 Jan 2017 11:48:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=message-id:mime-version:to:from:subject:date:importance:in-reply-to :references; bh=t4YXpnGQzjMgFzg23NKEEFz5RFNf/Jklo+48ZFy0D6A=; b=dz7XLZuFDckgREPAVl9m92k4vuLD4k2nLh+NTZj/GCKgdpuFu4VkljO6Aq+fzV0MOF 9ONssFNpByfawawZ954G5S1mxmA+OH2EHhpejTrsAnCBnKlM08jXCfKWCjCPoCvaAJey vXL6f1InzHkIIMMZbOohDE5xP8rMd85JEJlNJ+DH+XOu84SgswdwnNk04n//kjtkIeil 7jwl7REp5iWLZTPYeLYOcs5b0Vpobti5DQsYrHAYO7+xXV4129mbwYUwP4eixF5D8XBd qK6PfjcaEACn3FuO7pcCI0NyEKmrAMXDu3RMZ5t9pfV95WhSUGkSS3uHXClJVSON4Rst GLPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :importance:in-reply-to:references; bh=t4YXpnGQzjMgFzg23NKEEFz5RFNf/Jklo+48ZFy0D6A=; b=RLIEVRgr9BlPlV8kEPsw5CIEktO+fgvIlgRY8ZEEHM/BVPeFHpTZI8W0yypsGDGaTJ jEqSGiUF8EURzRAu1S3TJaV2SCu9dREVPp3NvAz94Pe7l+RDNaeRoS7OqMKRMtKSnmNU a7yfJUiS8z2aKS/zuNqEb8RDEGZBbYPYTUlzktJLu0aJCfh77zp1Gius4xjiip4GKs2d 2c3eEhoBi359kNmiNxwKW0bf3N7Lc6koJH9J+m/3Q0S0ZBe+WEDPuDlKQy7l5kP5a8rC hUj9+r0jOMSQevkdiuuRQAMXv7OG6lU2pGWt8iE1scttTyncYttBZAloNICJg6PgQZep Dd6Q== X-Gm-Message-State: AIkVDXIEhbEkCti3xI6FDLqF1b+Jv1eCt3LfGHDMZ9xVuFjD1ej75Lw+JctZbAw9nPiyND96 X-Received: by 10.84.238.1 with SMTP id u1mr6244486plk.174.1485373709331; Wed, 25 Jan 2017 11:48:29 -0800 (PST) Received: from ?IPv6:::ffff:10.181.87.102? ([64.114.255.114]) by smtp.gmail.com with ESMTPSA id p6sm3056092pfg.6.2017.01.25.11.48.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jan 2017 11:48:28 -0800 (PST) Message-ID: <5889010c.06d0620a.31d79.5dd8@mx.google.com> MIME-Version: 1.0 To: Dario Teixeira , "oauth@ietf.org" From: Date: Wed, 25 Jan 2017 11:48:28 -0800 Importance: normal X-Priority: 3 In-Reply-To: References: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c1ce78451f4fe0546f08403" Archived-At: Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 19:48:38 -0000 --94eb2c1ce78451f4fe0546f08403 Content-Type: multipart/alternative; boundary="_6598A2C0-932F-42DF-84A5-7BF8F9D4A393_" --_6598A2C0-932F-42DF-84A5-7BF8F9D4A393_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" There are a number of patterns that people use. I prefer the AppAuth pattern where the native app is a OAuth client to your= server and you are protecting your API with OAuth. Your AS becomes a Con= nect/SAML/Twitter auth/ Facebook etc relying party and uses federated or lo= cal authentication to issue tokens. (this gives your backend API access to= user info) The other pattern is for the native app to be a Connect client to Google or= other IdP and then passes a id_token (not access token) to your backend in= some secure manor and your backend validates the signature on the id_token= and that it was issued to your client (verification is essential) (the nat= ive app gets access to user info api) You still have the problem of how yo= u secure your API, as you need to exchange the validated id_token with some= thing. I thnk that doing this securely winds up being more complicated th= an the first option. There are other options that may not be allowed by the IdP where your backe= nd is the Connect client and has a client secret. The mobile app makes the= request and gets the code back. It then sends code and pkce verifier to = it=E2=80=99s backend and the server exchanges it with it=E2=80=99s secret t= o get a id_token and access token. You still need to add security for you= r API. (custom scheme redirects for confidential clients may not be allowe= d depending on the Connect IdP) I think the first option is the best design that gives the best long term d= esign as new IdP can be added without changing the deployed app. John B. Sent from Mail for Windows 10 From: Dario Teixeira Sent: January 25, 2017 7:59 AM To: oauth@ietf.org Subject: [OAUTH-WG] OAuth2/OIDC for client-server mobile app Hi, I am building a mobile app and a server. The mobile app fetches user-specific data from the server, and therefore some sort of authentication is required. I would like to avoid the traditional username+password scheme, and instead allow users to login via Google or Facebook. It seems the OAuth2-based OpenID Connect (OIDC) is the recommended solution nowadays, so my question is about the usage of OAuth2/OIDC in this scenario. All OIDC docs and tutorials describe the interaction between three parties: a Relying Party (RP), a User Agent (UA), and an OIDC Provider (OIP). There are however four parties in my scenario: the mobile app, the server, the UA, and the OIP. Which should take the role of RP? I see two different ways to do this: 1) The mobile app is the RP. It even takes care of starting a small web server to receive the data from the OIP. At the end of the interaction, the mobile app has a JWT signed by the OIP, which it sends to the server, which must validate it using a built-in list of OIP public signatures. 2) The server is the RP. When the user wishes to login, the mobile app asks the server about the OIP's authorization endpoint. The server provide the client with an URI whose redirect_uri parameter points to the server. All subsequent steps are handled by the server. Anyway, this seems like a fairly common scenario, and I would rather follow some best-practices documentation instead of cooking up my own schemes, like points 1 and 2 above. Therefore, if there is indeed such documentation, could someone please point me towards it? And if not, which would be the recommended route, 1 or 2? Thanks in advance for your attention! Best regards, Dario Teixeira _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth --_6598A2C0-932F-42DF-84A5-7BF8F9D4A393_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

There are a number of patterns that = people use.

 

I prefer the AppAuth pattern where the native app is a OAuth client to y= our server and you are protecting your API with OAuth.=C2=A0 =C2=A0Your AS = becomes a Connect/SAML/Twitter auth/ Facebook etc relying party and uses fe= derated or local authentication to issue tokens.=C2=A0 (this gives your bac= kend API access to user info)

 

=

The other pattern is for the native app to be a Connec= t client to Google or other IdP and then passes a id_token (not access toke= n) to your backend in some secure manor and your backend validates the sign= ature on the id_token and that it was issued to your client (verification i= s essential) (the native app gets access to user info api) =C2=A0You still = have the problem of how you secure your API, as you need to exchange the va= lidated id_token with something.=C2=A0=C2=A0 I thnk that doing this securel= y winds up being more complicated than the first option.

 

There are other options tha= t may not be allowed by the IdP where your backend is the Connect client an= d has a client secret.=C2=A0 The mobile app makes the request and gets the = code back.=C2=A0=C2=A0 It then sends code and pkce verifier to it=E2=80=99s= backend and the server exchanges it with it=E2=80=99s secret to get a id_t= oken and access token.=C2=A0=C2=A0 You still need to add security for your = API.=C2=A0 (custom scheme redirects for confidential clients may not be all= owed depending on the Connect IdP)

 

I think the first option is the best design that = gives the best long term design as new IdP can be added without changing th= e deployed app.

 

 

John B.

 

Sent from Mail for Windows 10

 

=

From: Dario Teixeira
Sent: J= anuary 25, 2017 7:59 AM
To: oau= th@ietf.org
Subject: [OAUTH-WG] OAuth2/OIDC for client-server= mobile app

 

Hi,

 

I am building a mobile app and a server.=C2=A0 The mobile app fetches

user-specific data from the server, and therefore so= me sort of

authentication is required.=C2=A0 I woul= d like to avoid the traditional

username+password s= cheme, and instead allow users to login via

Google = or Facebook.=C2=A0 It seems the OAuth2-based OpenID Connect (OIDC)

is the recommended solution nowadays, so my question is abo= ut the

usage of OAuth2/OIDC in this scenario.

 

All OIDC docs = and tutorials describe the interaction between three

parties: a Relying Party (RP), a User Agent (UA), and an OIDC

Provider (OIP).=C2=A0 There are however four parties in my sce= nario:

the mobile app, the server, the UA, and the = OIP.=C2=A0 Which should

take the role of RP? I see = two different ways to do this:

 

1) The mobile app is the RP.=C2=A0 It even takes care= of starting a

=C2=A0=C2=A0=C2=A0 small web server = to receive the data from the OIP.=C2=A0 At the end

= =C2=A0=C2=A0=C2=A0 of the interaction, the mobile app has a JWT signed by t= he OIP,

=C2=A0=C2=A0=C2=A0 which it sends to the se= rver, which must validate it using a

=C2=A0=C2=A0= =C2=A0 built-in list of OIP public signatures.

 

2) The server is the RP.=C2=A0 When t= he user wishes to login, the mobile

=C2=A0=C2=A0=C2= =A0 app asks the server about the OIP's authorization endpoint.

=C2=A0=C2=A0=C2=A0 The server provide the client with an URI w= hose redirect_uri

=C2=A0=C2=A0=C2=A0 parameter poin= ts to the server.=C2=A0 All subsequent steps are

= =C2=A0=C2=A0=C2=A0 handled by the server.

&nbs= p;

Anyway, this seems like a fairly common sc= enario, and I would rather

follow some best-practic= es documentation instead of cooking up my

own schem= es, like points 1 and 2 above.=C2=A0 Therefore, if there is

indeed such documentation, could someone please point me towards i= t?

And if not, which would be the recommended route= , 1 or 2?

 

Thanks in advance for your attention!

Best regards= ,

Dario Teixeira

 = ;

___________________________________________= ____

OAuth mailing list

OAu= th@ietf.org

https://www.ietf.org/mailman/listinfo/o= auth

 

= --_6598A2C0-932F-42DF-84A5-7BF8F9D4A393_-- --94eb2c1ce78451f4fe0546f08403 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIFrHMfdtcQpoAsvBLwy4a3Owz9+a 86PR2bK9FkwFq0n7MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDEyNTE5NDgyOVowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQB91Yf9zEu8x8EEw0hC7ynb267djOAWS5zkY7p2nU77F4xo 86Gp2DZou6MTDijJmCNSAG4oM03wSx6LYOlEhCcpZdxIzezgyqgLAgC0PjgtmkT4jTQeb/XMtI1B C1jGrXh9RdXMMIagqq8pNb7QS+YE8i2fndL7UFADrDmo1uXIndZBFKF4+zv3p+yKoowopSx1YFyG MDfkGTSqnxxJBtaqUOysKPnE7UzLbkLCDqXIj1es+FaPjHd654MLpYTbietZBm+9z1Aa16lXPab2 yN5vd8toZNhoTvdftS/wMvmRykiq4SmlEU1ohwYdXy3QiiHB/z5KY/LmvEEqV7N7fvQv --94eb2c1ce78451f4fe0546f08403-- From nobody Wed Jan 25 12:25:17 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A03BE129BC4 for ; Wed, 25 Jan 2017 12:25:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDGTFS4c7TUH for ; Wed, 25 Jan 2017 12:25:04 -0800 (PST) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37505129BB9 for ; Wed, 25 Jan 2017 12:25:03 -0800 (PST) Received: by mail-yb0-x22d.google.com with SMTP id 123so22807249ybe.3 for ; Wed, 25 Jan 2017 12:25:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=e9m43hEPe5eBF6FztCSv5FKmTD3WJZ97rap5w1cHjCA=; b=kdtSFLcaZrceHGwp+ObbnHU3Bi+HYkoSIv6pUVXW4Ne6ZxHWtuUIFi9hjJSjTpFmLn vYNPTDbhPESArw9JyahfM7nxqMKHapi16rd5ZDfCT4VwOo6yuvEnagvvkKE6x5Y6ZUls p3nVcJfKwh7dEboSI9P5xROoYnNqZe/0D2gCg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=e9m43hEPe5eBF6FztCSv5FKmTD3WJZ97rap5w1cHjCA=; b=bKkujuOlIQV+o7iN/esVJ6eUu16g2icyaac2gIDnc6676MalgdzI940NHsemOGSZ+U CUJK7NwaD9rv1xJeX3c0hF5lkyDCPNy3oZkmHqP+beGCnSYdy3qL36Qj/VR3lt5wr9bD 1x9QTYOYeXwgiFyD6JCSUbkZh/9qU54pr1N9mibHY7B7geUG5PD8puP0lt3u4IvCY/E5 aEwINt7nmCj6eB7PY8HkaMRkO/J5vGz8m1EzMiMs9cSjIDH/tNlyrkh0i7w2zeTDpQle kBOL3GeJfckkZM2aLnJevrfKkPbzcOurxYJ+vPo2KymWoD7pV7rI8LJjdIgrNDhE3ZDj Fz7Q== X-Gm-Message-State: AIkVDXJ0WAMgmQFEchwxIxOeXl7jkJwHMVNCHedaS8RtBaVtfeZ5PSoJRXoQr3JFsPJhytNkbK0xnAbSf1LA8+mU X-Received: by 10.129.174.90 with SMTP id g26mr37048415ywk.25.1485375902464; Wed, 25 Jan 2017 12:25:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.90.133 with HTTP; Wed, 25 Jan 2017 12:24:32 -0800 (PST) In-Reply-To: <5889010c.06d0620a.31d79.5dd8@mx.google.com> References: <5889010c.06d0620a.31d79.5dd8@mx.google.com> From: Brian Campbell Date: Wed, 25 Jan 2017 13:24:32 -0700 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=f403045f719a067ac00546f107f6 Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 20:25:12 -0000 --f403045f719a067ac00546f107f6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 to the AppAuth pattern On Wed, Jan 25, 2017 at 12:48 PM, wrote: > There are a number of patterns that people use. > > > > I prefer the AppAuth pattern where the native app is a OAuth client to > your server and you are protecting your API with OAuth. Your AS becomes= a > Connect/SAML/Twitter auth/ Facebook etc relying party and uses federated = or > local authentication to issue tokens. (this gives your backend API acces= s > to user info) > > > > The other pattern is for the native app to be a Connect client to Google > or other IdP and then passes a id_token (not access token) to your backen= d > in some secure manor and your backend validates the signature on the > id_token and that it was issued to your client (verification is essential= ) > (the native app gets access to user info api) You still have the problem > of how you secure your API, as you need to exchange the validated id_toke= n > with something. I thnk that doing this securely winds up being more > complicated than the first option. > > > > There are other options that may not be allowed by the IdP where your > backend is the Connect client and has a client secret. The mobile app > makes the request and gets the code back. It then sends code and pkce > verifier to it=E2=80=99s backend and the server exchanges it with it=E2= =80=99s secret to > get a id_token and access token. You still need to add security for you= r > API. (custom scheme redirects for confidential clients may not be allowe= d > depending on the Connect IdP) > > > > I think the first option is the best design that gives the best long term > design as new IdP can be added without changing the deployed app. > > > > > > John B. > > > > Sent from Mail for > Windows 10 > > > > *From: *Dario Teixeira > *Sent: *January 25, 2017 7:59 AM > *To: *oauth@ietf.org > *Subject: *[OAUTH-WG] OAuth2/OIDC for client-server mobile app > > > > Hi, > > > > I am building a mobile app and a server. The mobile app fetches > > user-specific data from the server, and therefore some sort of > > authentication is required. I would like to avoid the traditional > > username+password scheme, and instead allow users to login via > > Google or Facebook. It seems the OAuth2-based OpenID Connect (OIDC) > > is the recommended solution nowadays, so my question is about the > > usage of OAuth2/OIDC in this scenario. > > > > All OIDC docs and tutorials describe the interaction between three > > parties: a Relying Party (RP), a User Agent (UA), and an OIDC > > Provider (OIP). There are however four parties in my scenario: > > the mobile app, the server, the UA, and the OIP. Which should > > take the role of RP? I see two different ways to do this: > > > > 1) The mobile app is the RP. It even takes care of starting a > > small web server to receive the data from the OIP. At the end > > of the interaction, the mobile app has a JWT signed by the OIP, > > which it sends to the server, which must validate it using a > > built-in list of OIP public signatures. > > > > 2) The server is the RP. When the user wishes to login, the mobile > > app asks the server about the OIP's authorization endpoint. > > The server provide the client with an URI whose redirect_uri > > parameter points to the server. All subsequent steps are > > handled by the server. > > > > Anyway, this seems like a fairly common scenario, and I would rather > > follow some best-practices documentation instead of cooking up my > > own schemes, like points 1 and 2 above. Therefore, if there is > > indeed such documentation, could someone please point me towards it? > > And if not, which would be the recommended route, 1 or 2? > > > > Thanks in advance for your attention! > > Best regards, > > Dario Teixeira > > > > _______________________________________________ > > 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 > > --f403045f719a067ac00546f107f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 to the AppAuth pattern
=
On Wed, Jan 25, 2017 at 12:48 PM, <ve7jtb@= ve7jtb.com> wrote:

There are a number of patterns th= at people use.

=C2=A0

I prefer the AppAuth pattern where the native app is a OAuth= client to your server and you are protecting your API with OAuth.=C2=A0 = =C2=A0Your AS becomes a Connect/SAML/Twitter auth/ Facebook etc relying par= ty and uses federated or local authentication to issue tokens.=C2=A0 (this = gives your backend API access to user info)

=C2=A0

The other pattern is for the nati= ve app to be a Connect client to Google or other IdP and then passes a id_t= oken (not access token) to your backend in some secure manor and your backe= nd validates the signature on the id_token and that it was issued to your c= lient (verification is essential) (the native app gets access to user info = api) =C2=A0You still have the problem of how you secure your API, as you ne= ed to exchange the validated id_token with something.=C2=A0=C2=A0 I thnk th= at doing this securely winds up being more complicated than the first optio= n.

=C2=A0

There are other options that may not be allowed by the IdP where your back= end is the Connect client and has a client secret.=C2=A0 The mobile app mak= es the request and gets the code back.=C2=A0=C2=A0 It then sends code and p= kce verifier to it=E2=80=99s backend and the server exchanges it with it=E2= =80=99s secret to get a id_token and access token.=C2=A0=C2=A0 You still ne= ed to add security for your API.=C2=A0 (custom scheme redirects for confide= ntial clients may not be allowed depending on the Connect IdP)

=C2=A0

I think the f= irst option is the best design that gives the best long term design as new = IdP can be added without changing the deployed app.

=C2=A0

=C2=A0

<= p class=3D"MsoNormal">John B.

=C2=A0

Sent from Mail for Windows 10

=C2=A0

From: Dario Teixeira
Sent: Januar= y 25, 2017 7:59 AM
To: oauth@ietf.org
Subject: [OAUTH-WG] OAuth2/OIDC fo= r client-server mobile app

=C2=A0

Hi,

=C2=A0

I am building a mob= ile app and a server.=C2=A0 The mobile app fetches

user-specific data from the server, and therefore some sort of

authentication is required.=C2=A0 I would like to avoid the= traditional

username+password scheme, and instea= d allow users to login via

Google or Facebook.=C2= =A0 It seems the OAuth2-based OpenID Connect (OIDC)

is the recommended solution nowadays, so my question is about the

usage of OAuth2/OIDC in this scenario.

=C2=A0

All OIDC docs and = tutorials describe the interaction between three

= parties: a Relying Party (RP), a User Agent (UA), and an OIDC

Provider (OIP).=C2=A0 There are however four parties in my s= cenario:

the mobile app, the server, the UA, and = the OIP.=C2=A0 Which should

take the role of RP? = I see two different ways to do this:

=C2= =A0

1) The mobile app is the RP.=C2=A0 It = even takes care of starting a

=C2=A0=C2=A0=C2=A0 = small web server to receive the data from the OIP.=C2=A0 At the end

=C2=A0=C2=A0=C2=A0 of the interaction, the mobile app ha= s a JWT signed by the OIP,

=C2=A0=C2=A0=C2=A0 whi= ch it sends to the server, which must validate it using a

=C2=A0=C2=A0=C2=A0 built-in list of OIP public signatures.

=C2=A0

2) The se= rver is the RP.=C2=A0 When the user wishes to login, the mobile

=C2=A0=C2=A0=C2=A0 app asks the server about the OIP's a= uthorization endpoint.

=C2=A0=C2=A0=C2=A0 The ser= ver provide the client with an URI whose redirect_uri

=C2=A0=C2=A0=C2=A0 parameter points to the server.=C2=A0 All subsequen= t steps are

=C2=A0=C2=A0=C2=A0 handled by the ser= ver.

=C2=A0

Anyway, this seems like a fairly common scenario, and I would rather

=

follow some best-practices documentation instead of = cooking up my

own schemes, like points 1 and 2 ab= ove.=C2=A0 Therefore, if there is

indeed such doc= umentation, could someone please point me towards it?

And if not, which would be the recommended route, 1 or 2?

=C2=A0

Thanks in adv= ance for your attention!

Best regards,

Dario Teixeira

=C2=A0

_________________________________________= ______

OAuth mailing list

OAuth@ietf.org

https://www.ietf.org/mailman/listinfo/oauth

=C2=A0


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


--f403045f719a067ac00546f107f6-- From nobody Wed Jan 25 12:33:11 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C6BE129BC6 for ; Wed, 25 Jan 2017 12:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.418 X-Spam-Level: X-Spam-Status: No, score=-7.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pZTacZ6JbSH for ; Wed, 25 Jan 2017 12:33:00 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2281129BC1 for ; Wed, 25 Jan 2017 12:33:00 -0800 (PST) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v0PKWx8H009382 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 25 Jan 2017 20:32:59 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v0PKWvEJ002818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 25 Jan 2017 20:32:57 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v0PKWuYZ031258; Wed, 25 Jan 2017 20:32:57 GMT Received: from [10.0.8.164] (/66.183.175.166) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 25 Jan 2017 12:32:56 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-526F2A97-7ED3-414E-B555-48467EFC4AD7 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14C92) In-Reply-To: Date: Wed, 25 Jan 2017 12:32:55 -0800 Content-Transfer-Encoding: 7bit Message-Id: <823CE48E-D778-4704-B13D-B6C302ED14D6@oracle.com> References: <5889010c.06d0620a.31d79.5dd8@mx.google.com> To: Brian Campbell X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 20:33:05 -0000 --Apple-Mail-526F2A97-7ED3-414E-B555-48467EFC4AD7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 to AppAuth One disturbing pattern I see for mobile apps relaying the idtoken is that th= e aud isn't checked by the AS in the Oauth exchange. This in part caused by t= he fact that the mobile app has two client-id identifiers. If the aud only h= as the clientid for the OIDC call this can be a problem if the AS doesn't kn= ow what that id is (since it didnt issue the id). If the issued id token doe= s not have an aud value the AS can recognize it should be rejected. Phil > On Jan 25, 2017, at 12:24 PM, Brian Campbell w= rote: >=20 > +1 to the AppAuth pattern >=20 >> On Wed, Jan 25, 2017 at 12:48 PM, wrote: >> There are a number of patterns that people use. >>=20 >> =20 >>=20 >> I prefer the AppAuth pattern where the native app is a OAuth client to yo= ur server and you are protecting your API with OAuth. Your AS becomes a Co= nnect/SAML/Twitter auth/ Facebook etc relying party and uses federated or lo= cal authentication to issue tokens. (this gives your backend API access to u= ser info) >>=20 >> =20 >>=20 >> The other pattern is for the native app to be a Connect client to Google o= r other IdP and then passes a id_token (not access token) to your backend in= some secure manor and your backend validates the signature on the id_token a= nd that it was issued to your client (verification is essential) (the native= app gets access to user info api) You still have the problem of how you se= cure your API, as you need to exchange the validated id_token with something= . I thnk that doing this securely winds up being more complicated than the= first option. >>=20 >> =20 >>=20 >> There are other options that may not be allowed by the IdP where your bac= kend is the Connect client and has a client secret. The mobile app makes th= e request and gets the code back. It then sends code and pkce verifier to i= t=E2=80=99s backend and the server exchanges it with it=E2=80=99s secret to g= et a id_token and access token. You still need to add security for your AP= I. (custom scheme redirects for confidential clients may not be allowed dep= ending on the Connect IdP) >>=20 >> =20 >>=20 >> I think the first option is the best design that gives the best long term= design as new IdP can be added without changing the deployed app. >>=20 >> =20 >>=20 >> =20 >>=20 >> John B. >>=20 >> =20 >>=20 >> Sent from Mail for Windows 10 >>=20 >> =20 >>=20 >> From: Dario Teixeira >> Sent: January 25, 2017 7:59 AM >> To: oauth@ietf.org >> Subject: [OAUTH-WG] OAuth2/OIDC for client-server mobile app >>=20 >> =20 >>=20 >> Hi, >>=20 >> =20 >>=20 >> I am building a mobile app and a server. The mobile app fetches >>=20 >> user-specific data from the server, and therefore some sort of >>=20 >> authentication is required. I would like to avoid the traditional >>=20 >> username+password scheme, and instead allow users to login via >>=20 >> Google or Facebook. It seems the OAuth2-based OpenID Connect (OIDC) >>=20 >> is the recommended solution nowadays, so my question is about the >>=20 >> usage of OAuth2/OIDC in this scenario. >>=20 >> =20 >>=20 >> All OIDC docs and tutorials describe the interaction between three >>=20 >> parties: a Relying Party (RP), a User Agent (UA), and an OIDC >>=20 >> Provider (OIP). There are however four parties in my scenario: >>=20 >> the mobile app, the server, the UA, and the OIP. Which should >>=20 >> take the role of RP? I see two different ways to do this: >>=20 >> =20 >>=20 >> 1) The mobile app is the RP. It even takes care of starting a >>=20 >> small web server to receive the data from the OIP. At the end >>=20 >> of the interaction, the mobile app has a JWT signed by the OIP, >>=20 >> which it sends to the server, which must validate it using a >>=20 >> built-in list of OIP public signatures. >>=20 >> =20 >>=20 >> 2) The server is the RP. When the user wishes to login, the mobile >>=20 >> app asks the server about the OIP's authorization endpoint. >>=20 >> The server provide the client with an URI whose redirect_uri >>=20 >> parameter points to the server. All subsequent steps are >>=20 >> handled by the server. >>=20 >> =20 >>=20 >> Anyway, this seems like a fairly common scenario, and I would rather >>=20 >> follow some best-practices documentation instead of cooking up my >>=20 >> own schemes, like points 1 and 2 above. Therefore, if there is >>=20 >> indeed such documentation, could someone please point me towards it? >>=20 >> And if not, which would be the recommended route, 1 or 2? >>=20 >> =20 >>=20 >> Thanks in advance for your attention! >>=20 >> Best regards, >>=20 >> Dario Teixeira >>=20 >> =20 >>=20 >> _______________________________________________ >>=20 >> OAuth mailing list >>=20 >> OAuth@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >> =20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >>=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth --Apple-Mail-526F2A97-7ED3-414E-B555-48467EFC4AD7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
+1 to AppAuth

One disturbing pattern I= see for mobile apps relaying the idtoken is that the aud isn't checked by t= he AS in the Oauth exchange. This in part caused by the fact that the mobile= app has two client-id identifiers. If the aud only has the clientid for the= OIDC call this can be a problem if the AS doesn't know what that id is (sin= ce it didnt issue the id). If the issued id token does not have an aud value the AS can r= ecognize it should be rejected.

Phil

On Jan 25, 2= 017, at 12:24 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

+1 to the AppAuth pattern

On Wed, Jan 25, 2017 at 12:48 P= M, <ve7jtb@ve7jtb.com> wrote:

There are a number of pat= terns that people use.

 

I prefer the AppAuth pattern where the native app is a OA= uth client to your server and you are protecting your API with OAuth.  &= nbsp;Your AS becomes a Connect/SAML/Twitter auth/ Facebook etc relying party= and uses federated or local authentication to issue tokens.  (this giv= es your backend API access to user info)

&n= bsp;

The other pattern is for the native ap= p to be a Connect client to Google or other IdP and then passes a id_token (= not access token) to your backend in some secure manor and your backend vali= dates the signature on the id_token and that it was issued to your client (v= erification is essential) (the native app gets access to user info api) &nbs= p;You still have the problem of how you secure your API, as you need to exch= ange the validated id_token with something.   I thnk that doing th= is securely winds up being more complicated than the first option.

 

There are ot= her options that may not be allowed by the IdP where your backend is the Con= nect client and has a client secret.  The mobile app makes the request a= nd gets the code back.   It then sends code and pkce verifier to i= t=E2=80=99s backend and the server exchanges it with it=E2=80=99s secret to g= et a id_token and access token.   You still need to add security f= or your API.  (custom scheme redirects for confidential clients may not= be allowed depending on the Connect IdP)

&= nbsp;

I think the first option is the best d= esign that gives the best long term design as new IdP can be added without c= hanging the deployed app.

 

=

 

John B= .

 

S= ent from Mail for Windows 10

 <= u>

<= b>From: = Dario Teixeira
Sent: January 25, 2017 7:59 AM
To: oauth@ietf.org
S= ubject: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

 

Hi,

 

I am building a mobile app and a server.  The mobile app fe= tches

user-specific data from the server, and ther= efore some sort of

authentication is required.&nbs= p; I would like to avoid the traditional

username+= password scheme, and instead allow users to login via

Google or Facebook.  It seems the OAuth2-based OpenID Connect (OIDC= )

is the recommended solution nowadays, so my ques= tion is about the

usage of OAuth2/OIDC in this sce= nario.

 

All OIDC docs and tutorials describe the interaction between three

parties: a Relying Party (RP), a User Agent (UA), and a= n OIDC

Provider (OIP).  There are however fou= r parties in my scenario:

the mobile app, the serv= er, the UA, and the OIP.  Which should

take t= he role of RP? I see two different ways to do this:

 

1) The mobile app is the RP= .  It even takes care of starting a

 &nb= sp;  small web server to receive the data from the OIP.  At the en= d

    of the interaction, the mobil= e app has a JWT signed by the OIP,

  &nb= sp; which it sends to the server, which must validate it using a

    built-in list of OIP public signatures.

 

2) Th= e server is the RP.  When the user wishes to login, the mobile

    app asks the server about the OIP's aut= horization endpoint.

    The server= provide the client with an URI whose redirect_uri

    parameter points to the server.  All subsequent ste= ps are

    handled by the server.

 

Anyw= ay, this seems like a fairly common scenario, and I would rather

follow some best-practices documentation instead of cooking u= p my

own schemes, like points 1 and 2 above. = Therefore, if there is

indeed such documentation,= could someone please point me towards it?

And if n= ot, which would be the recommended route, 1 or 2?

=  

Thanks in advance for your at= tention!

Best regards,

D= ario Teixeira

 

_______________________________________________

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


____________________= ___________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mai= lman/listinfo/oauth
= --Apple-Mail-526F2A97-7ED3-414E-B555-48467EFC4AD7-- From nobody Wed Jan 25 13:07:36 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 109E3129BFA for ; Wed, 25 Jan 2017 13:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.757 X-Spam-Level: X-Spam-Status: No, score=-3.757 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvZcpwehqyrc for ; Wed, 25 Jan 2017 13:07:23 -0800 (PST) Received: from smtprelay06.ispgateway.de (smtprelay06.ispgateway.de [80.67.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AE82129BF8 for ; Wed, 25 Jan 2017 13:07:22 -0800 (PST) Received: from [87.143.172.172] (helo=[192.168.71.161]) by smtprelay06.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84) (envelope-from ) id 1cWUmj-0000rj-TI; Wed, 25 Jan 2017 22:07:17 +0100 From: Torsten Lodderstedt Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2EEBDF87-E555-49A2-B698-719826912EF6" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 25 Jan 2017 22:07:15 +0100 In-Reply-To: <823CE48E-D778-4704-B13D-B6C302ED14D6@oracle.com> To: Phil Hunt References: <5889010c.06d0620a.31d79.5dd8@mx.google.com> <823CE48E-D778-4704-B13D-B6C302ED14D6@oracle.com> X-Mailer: Apple Mail (2.3259) X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ= Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 21:07:28 -0000 --Apple-Mail=_2EEBDF87-E555-49A2-B698-719826912EF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 > Am 25.01.2017 um 21:32 schrieb Phil Hunt (IDM) : >=20 > +1 to AppAuth >=20 > One disturbing pattern I see for mobile apps relaying the idtoken is = that the aud isn't checked by the AS in the Oauth exchange. This in part = caused by the fact that the mobile app has two client-id identifiers. If = the aud only has the clientid for the OIDC call this can be a problem if = the AS doesn't know what that id is (since it didnt issue the id). If = the issued id token does not have an aud value the AS can recognize it = should be rejected. >=20 > Phil >=20 > On Jan 25, 2017, at 12:24 PM, Brian Campbell = > wrote: >=20 >> +1 to the AppAuth pattern >>=20 >> On Wed, Jan 25, 2017 at 12:48 PM, > wrote: >> There are a number of patterns that people use. >>=20 >> =20 >>=20 >> I prefer the AppAuth pattern where the native app is a OAuth client = to your server and you are protecting your API with OAuth. Your AS = becomes a Connect/SAML/Twitter auth/ Facebook etc relying party and uses = federated or local authentication to issue tokens. (this gives your = backend API access to user info) >>=20 >> =20 >>=20 >> The other pattern is for the native app to be a Connect client to = Google or other IdP and then passes a id_token (not access token) to = your backend in some secure manor and your backend validates the = signature on the id_token and that it was issued to your client = (verification is essential) (the native app gets access to user info = api) You still have the problem of how you secure your API, as you need = to exchange the validated id_token with something. I thnk that doing = this securely winds up being more complicated than the first option. >>=20 >> =20 >>=20 >> There are other options that may not be allowed by the IdP where your = backend is the Connect client and has a client secret. The mobile app = makes the request and gets the code back. It then sends code and pkce = verifier to it=E2=80=99s backend and the server exchanges it with it=E2=80= =99s secret to get a id_token and access token. You still need to add = security for your API. (custom scheme redirects for confidential = clients may not be allowed depending on the Connect IdP) >>=20 >> =20 >>=20 >> I think the first option is the best design that gives the best long = term design as new IdP can be added without changing the deployed app. >>=20 >> =20 >>=20 >> =20 >>=20 >> John B. >>=20 >> =20 >>=20 >> Sent from Mail for = Windows 10 >>=20 >> =20 >>=20 >> From: Dario Teixeira >> Sent: January 25, 2017 7:59 AM >> To: oauth@ietf.org >> Subject: [OAUTH-WG] OAuth2/OIDC for client-server mobile app >>=20 >> =20 >>=20 >> Hi, >>=20 >> =20 >>=20 >> I am building a mobile app and a server. The mobile app fetches >>=20 >> user-specific data from the server, and therefore some sort of >>=20 >> authentication is required. I would like to avoid the traditional >>=20 >> username+password scheme, and instead allow users to login via >>=20 >> Google or Facebook. It seems the OAuth2-based OpenID Connect (OIDC) >>=20 >> is the recommended solution nowadays, so my question is about the >>=20 >> usage of OAuth2/OIDC in this scenario. >>=20 >> =20 >>=20 >> All OIDC docs and tutorials describe the interaction between three >>=20 >> parties: a Relying Party (RP), a User Agent (UA), and an OIDC >>=20 >> Provider (OIP). There are however four parties in my scenario: >>=20 >> the mobile app, the server, the UA, and the OIP. Which should >>=20 >> take the role of RP? I see two different ways to do this: >>=20 >> =20 >>=20 >> 1) The mobile app is the RP. It even takes care of starting a >>=20 >> small web server to receive the data from the OIP. At the end >>=20 >> of the interaction, the mobile app has a JWT signed by the OIP, >>=20 >> which it sends to the server, which must validate it using a >>=20 >> built-in list of OIP public signatures. >>=20 >> =20 >>=20 >> 2) The server is the RP. When the user wishes to login, the mobile >>=20 >> app asks the server about the OIP's authorization endpoint. >>=20 >> The server provide the client with an URI whose redirect_uri >>=20 >> parameter points to the server. All subsequent steps are >>=20 >> handled by the server. >>=20 >> =20 >>=20 >> Anyway, this seems like a fairly common scenario, and I would rather >>=20 >> follow some best-practices documentation instead of cooking up my >>=20 >> own schemes, like points 1 and 2 above. Therefore, if there is >>=20 >> indeed such documentation, could someone please point me towards it? >>=20 >> And if not, which would be the recommended route, 1 or 2? >>=20 >> =20 >>=20 >> Thanks in advance for your attention! >>=20 >> Best regards, >>=20 >> Dario Teixeira >>=20 >> =20 >>=20 >> _______________________________________________ >>=20 >> OAuth mailing list >>=20 >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >> =20 >>=20 >>=20 >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth = >>=20 >>=20 >> _______________________________________________ >> 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 --Apple-Mail=_2EEBDF87-E555-49A2-B698-719826912EF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1

Am 25.01.2017 um 21:32 schrieb Phil Hunt = (IDM) <phil.hunt@oracle.com>:

+1 to = AppAuth

One = disturbing pattern I see for mobile apps relaying the idtoken is that = the aud isn't checked by the AS in the Oauth exchange. This in part = caused by the fact that the mobile app has two client-id identifiers. If = the aud only has the clientid for the OIDC call this can be a problem if = the AS doesn't know what that id is (since it didnt issue the = id). If the issued id token does not have an aud value the AS can = recognize it should be rejected.

Phil

On Jan 25, 2017, at = 12:24 PM, Brian Campbell <bcampbell@pingidentity.com> wrote:

+1 to the AppAuth pattern

On Wed, = Jan 25, 2017 at 12:48 PM, <ve7jtb@ve7jtb.com> wrote:

There = are a number of patterns that people use.

 

I = prefer the AppAuth pattern where the native app is a OAuth client to = your server and you are protecting your API with OAuth.   Your = AS becomes a Connect/SAML/Twitter auth/ Facebook etc relying party and = uses federated or local authentication to issue tokens.  (this = gives your backend API access to user info)

 

The = other pattern is for the native app to be a Connect client to Google or = other IdP and then passes a id_token (not access token) to your backend = in some secure manor and your backend validates the signature on the = id_token and that it was issued to your client (verification is = essential) (the native app gets access to user info api)  You still = have the problem of how you secure your API, as you need to exchange the = validated id_token with something.   I thnk that doing this = securely winds up being more complicated than the first option.

 

There are other options that may not be allowed by = the IdP where your backend is the Connect client and has a client = secret.  The mobile app makes the request and gets the code = back.   It then sends code and pkce verifier to it=E2=80=99s = backend and the server exchanges it with it=E2=80=99s secret to get a = id_token and access token.   You still need to add security = for your API.  (custom scheme redirects for confidential clients = may not be allowed depending on the Connect IdP)

 

I think the first option is the best design that = gives the best long term design as new IdP can be added without changing = the deployed app.

 

 

John B.

 

Sent from Mail for Windows 10

 

From: Dario Teixeira
Sent: = January 25, 2017 7:59 AM
To: oauth@ietf.org
Subject: = [OAUTH-WG] OAuth2/OIDC for client-server mobile app

 

Hi,

 

I am = building a mobile app and a server.  The mobile app fetches

user-specific data from the server, and therefore = some sort of

authentication is required.  = I would like to avoid the traditional

username+password scheme, and instead allow users to = login via

Google or Facebook.  It seems = the OAuth2-based OpenID Connect (OIDC)

is the = recommended solution nowadays, so my question is about the

usage of OAuth2/OIDC in this scenario.

 

All OIDC docs and tutorials describe the interaction = between three

parties: a Relying Party (RP), a = User Agent (UA), and an OIDC

Provider = (OIP).  There are however four parties in my scenario:

the mobile app, the server, the UA, and the = OIP.  Which should

take the role of RP? I = see two different ways to do this:

 

1) The = mobile app is the RP.  It even takes care of starting a

    small web server to receive the = data from the OIP.  At the end

    of the interaction, the mobile = app has a JWT signed by the OIP,

    which it sends to the server, = which must validate it using a

    built-in list of OIP public = signatures.

 

2) The server is the RP.  = When the user wishes to login, the mobile

    app asks the server about the = OIP's authorization endpoint.

   = The server provide the client with an URI whose redirect_uri

    parameter points to the = server.  All subsequent steps are

    handled by the server.

 

Anyway, this seems like a fairly common scenario, = and I would rather

follow some best-practices = documentation instead of cooking up my

own = schemes, like points 1 and 2 above.  Therefore, if there is

indeed such documentation, could someone please = point me towards it?

And if not, which would = be the recommended route, 1 or 2?

 

Thanks = in advance for your attention!

Best = regards,

Dario Teixeira

 

_______________________________________________

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


_______________________________________________
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

= --Apple-Mail=_2EEBDF87-E555-49A2-B698-719826912EF6-- From nobody Wed Jan 25 15:12:44 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B591293F9 for ; Wed, 25 Jan 2017 15:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAfKyHT7DiJz for ; Wed, 25 Jan 2017 15:12:42 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D27A2120727 for ; Wed, 25 Jan 2017 15:12:41 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id i68so170486974uad.0 for ; Wed, 25 Jan 2017 15:12:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=3iCY2EJumwh5idoP4KSj3YKp4ULiatAoWeSJNSNepPs=; b=Sey/dXLCAeQlfX/uTcPa2jZc7oNx0vWK9PIOIcdxX/L/gfniNP5l0mYzZrMsdLDYMP P6T549QOCqJNcSBDMUzDSuF/pCTI9ArTqMcAI6Si85Z7jyho+mHL6Som1vr694ThxVxi vBMuVnGFlqQpZR4ax9u65Q+sFN5jfbtou3lTZ12LWHvSVQnuJ0XIe9M78cP+1vjok2Mh Wu4F5iWipLEPmRWVvz8jVkCvLxgK5rAMHNARgjLe4DYnPOaTW7LmkoXWowX8LSCoKDC9 P9Opxl5Aedqdk9gU2zAz4CRU+4BNdt4XKNMn3W8LOFaqT3BBQMFh86t/yi4BmoTy3TJ+ d2qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=3iCY2EJumwh5idoP4KSj3YKp4ULiatAoWeSJNSNepPs=; b=IeRGCEKUwfeI2uFf8WnpFnTV0BkJDF6DVgTRb+MpxnJpt7vvP3GtnyGoIiU7vo32Ms NmVndayZxq3roNBQlxoSya+wKDsnJ3AlZ3uuMGbDn1dz9ke383fka0VdcwWGJQiw72X2 Ftf2DJgcjCJaGfDfuuAfjsS9yWkkIS2d3YH6cVVAC4l54nm4iQbs73x6+AFjY0nbVj5t 9xDbrPdesdYLtj/VL2bNXbIUGPkPv3u29iFQjSzOZ9Cdr41A9MAZenYDAGVRMEx7tqMi dQ0VpV1EgkP0lKMuWHZDTQnOwvfGyw0KbkODWeNjE6Ca32hcRbPopD1728BAmixfONVw qZTg== X-Gm-Message-State: AIkVDXJPe+MWHjkkQfp8MskUf/TBAd33Ttk4GUeoU9kwIMk4PEnDD054HKXCJb6FzJhbEQ== X-Received: by 10.159.56.146 with SMTP id t18mr22648705uaf.137.1485385960746; Wed, 25 Jan 2017 15:12:40 -0800 (PST) Received: from mail-ua0-f182.google.com (mail-ua0-f182.google.com. [209.85.217.182]) by smtp.gmail.com with ESMTPSA id 64sm819053vkp.16.2017.01.25.15.12.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jan 2017 15:12:40 -0800 (PST) Received: by mail-ua0-f182.google.com with SMTP id 35so170879983uak.1 for ; Wed, 25 Jan 2017 15:12:39 -0800 (PST) X-Received: by 10.159.34.105 with SMTP id 96mr21834119uad.84.1485385959734; Wed, 25 Jan 2017 15:12:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.36.132 with HTTP; Wed, 25 Jan 2017 15:12:39 -0800 (PST) From: Aaron Parecki Date: Wed, 25 Jan 2017 15:12:39 -0800 X-Gmail-Original-Message-ID: Message-ID: To: OAuth WG Content-Type: multipart/alternative; boundary=001a113fa0927c0c0e0546f35e73 Archived-At: Subject: [OAUTH-WG] Recommendations for browser-based apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 23:12:43 -0000 --001a113fa0927c0c0e0546f35e73 Content-Type: text/plain; charset=UTF-8 Thanks to the new "OAuth 2.0 for Native Apps" and PKCE documents, we have a solid recommendation for how to do OAuth 2.0 for native apps. Given that PKCE is intended for "public clients" and not specifically native apps, I'm wondering where that leaves browser-based apps. The core spec still says that the implicit grant is recommended for browser-based apps, but it's looking like the recommendation is to use the authorization code flow + PKCE with no secret for browser-based apps. Am I correct in thinking that the general recommendation would be to use the authorization code flow with no secret, and even better to use PKCE for browser-based apps? ---- Aaron Parecki aaronparecki.com --001a113fa0927c0c0e0546f35e73 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks to the new "OAuth 2.0 for Native Apps&quo= t; and PKCE documents, we have a solid recommendation for how to do OAuth 2= .0 for native apps.=C2=A0

Given that PKCE is inten= ded for "public clients" and not specifically native apps, I'= m wondering where that leaves browser-based apps. The core spec still says = that the implicit grant is recommended for browser-based apps, but it's= looking like the recommendation is to use the authorization code flow + PK= CE with no secret for browser-based apps.

Am I cor= rect in thinking that the general recommendation would be to use the author= ization code flow with no secret, and even better to use PKCE for browser-b= ased apps?

----
Aaron Parecki
<= a href=3D"http://aaronparecki.com" target=3D"_blank">aaronparecki.com

--001a113fa0927c0c0e0546f35e73-- From nobody Wed Jan 25 16:24:07 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB9D3129421 for ; Wed, 25 Jan 2017 16:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kafTbxBeMFgk for ; Wed, 25 Jan 2017 16:24:03 -0800 (PST) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF73D126D74 for ; Wed, 25 Jan 2017 16:24:03 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id 194so68416016pgd.2 for ; Wed, 25 Jan 2017 16:24:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=message-id:mime-version:to:from:subject:date:importance:in-reply-to :references; bh=MCtXH4Z2MKhohqCNLhviMn4X6TY4yzXsCbRCy+qW6B8=; b=UdT4H7nS/QGx71PdzBG3aYX+eJggTwRU08JfgpjrwfjgFs7MTZRZBET8jVO7Mng2jt ofsjH/Z3TsE968b0t+Fg6oj5cjqzLWVP8kGSOXd1BcBV53uxlxsw2tSI7oKpQyE8XO90 DggXYTkp39QzmN6YS+2ACvrr1LghL62XLNM4YLEiXDXJwxQwEFcCfqnOxIW3U1i57rzb 3OBDoq7qYEUd7KNmE4fmvchO4unxi01gGtn+Hsxis4L79Z5khEkf6CAZ8+zjRBDpyn01 tXwjkdmgucyi5wEMscH7tVREMzrndFcUMGYglgbGLCBLEseLKh6GMxM/11o4MAxMDxZa ho7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:from:subject:date :importance:in-reply-to:references; bh=MCtXH4Z2MKhohqCNLhviMn4X6TY4yzXsCbRCy+qW6B8=; b=GIv6rvoj2mSUenher8x1YDN5TjcRsnqqBzw/FFJZ021yhApv7V3DCc6jEeSVqMXz0v 33iLkz/qQEWCCI17suOp2FhcoyQ45irxUHE0bKBwb+OEOFDsLry8JqrEO+wmNemExSsf 1J4jxEqI8a1KpdxeC4p1Fo2fLapwxAAcVDnJOD/1zyIUdZfetBLfbQTT6Gg5LC+6aal0 COL83AAx9P49Z/UGJh8t4cxrrsbHs0oZ+/ltv0ioIxn+JRD3t9ctBe71+hnzdYUVZCH0 Jh9KWJE3EJsNteZc6cRoJcBQziWZjKtvg6relam2IlhvIOm17KYPSvwdx37RTHsZQoOR PSGw== X-Gm-Message-State: AIkVDXJIVKiOKkuV2xKIRArPNVb+ZLuj5KI6vw/dHp3QHEb5HQdUAGxTrT6QyqvPiItW8LAA X-Received: by 10.98.62.153 with SMTP id y25mr122094pfj.162.1485390243035; Wed, 25 Jan 2017 16:24:03 -0800 (PST) Received: from ?IPv6:::ffff:10.181.87.102? ([64.114.255.114]) by smtp.gmail.com with ESMTPSA id h17sm3632973pfh.62.2017.01.25.16.24.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jan 2017 16:24:01 -0800 (PST) Message-ID: <588941a1.1121620a.1d24d.86e2@mx.google.com> MIME-Version: 1.0 To: Aaron Parecki , OAuth WG From: Date: Wed, 25 Jan 2017 16:24:01 -0800 Importance: normal X-Priority: 3 In-Reply-To: References: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c1168accdbc740546f45db9" Archived-At: Subject: Re: [OAUTH-WG] Recommendations for browser-based apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 00:24:05 -0000 --94eb2c1168accdbc740546f45db9 Content-Type: multipart/alternative; boundary="_D29378EF-09F4-45F1-9F87-32CC3D71E85F_" --_D29378EF-09F4-45F1-9F87-32CC3D71E85F_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" It depends on what you mean by browser based apps. In general for single page apps that are java script executing in the brows= er dom, the recommendation would be implicit flow.=20 These apps don=E2=80=99t by definition need offline access as they go away = when the user is not present. We have talked about developing guidance for single page apps, but don=E2= =80=99t have anything yet. I think it needs to be thought through again now that new things like servi= ce workers are available, and we will eventually get token binding in the b= rowser (hint it is on in IE and Edge on windows 10 preview and in Chrome be= hind a feature flag now)=20 You could use the PKCE appAuth type flow in a SPA app if you have the corre= ct CORS setup. I however cant at this point say that you are getting improved security for= the extra work in that environment. John B. Sent from Mail for Windows 10 From: Aaron Parecki Sent: January 25, 2017 3:12 PM To: OAuth WG Subject: [OAUTH-WG] Recommendations for browser-based apps Thanks to the new "OAuth 2.0 for Native Apps" and PKCE documents, we have a= solid recommendation for how to do OAuth 2.0 for native apps.=C2=A0 Given that PKCE is intended for "public clients" and not specifically nativ= e apps, I'm wondering where that leaves browser-based apps. The core spec s= till says that the implicit grant is recommended for browser-based apps, bu= t it's looking like the recommendation is to use the authorization code flo= w + PKCE with no secret for browser-based apps. Am I correct in thinking that the general recommendation would be to use th= e authorization code flow with no secret, and even better to use PKCE for b= rowser-based apps? ---- Aaron Parecki aaronparecki.com --_D29378EF-09F4-45F1-9F87-32CC3D71E85F_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

It depends on what you mean by brows= er based apps.

 

In general for single page apps that are java script executing in the= browser dom, the recommendation would be implicit flow.

 

These apps don=E2=80=99t b= y definition need offline access as they go away when the user is not prese= nt.

 

We ha= ve talked about developing guidance for single page apps, but don=E2=80=99t= have anything yet.

 

I think it needs to be thought through again now that new thin= gs like service workers are available, and we will eventually get token bin= ding in the browser (hint it is on in IE and Edge on windows 10 preview and= in Chrome behind a feature flag now)

 <= /o:p>

You could use the PKCE appAuth type flow in a= SPA app if you have the correct CORS setup.

I howe= ver cant at this point say that you are getting improved security for the e= xtra work in that environment.

 

John B.

Sent from Mail for Windows 10

 

From: <= a href=3D"mailto:aaron@parecki.com">Aaron Parecki
Sent: Janua= ry 25, 2017 3:12 PM
To: OAuth W= G
Subject: [OAUTH-WG] Recommendations for browser-based apps<= /p>

 

Thanks to the new "OAuth 2.0 for Native Apps" and PKCE doc= uments, we have a solid recommendation for how to do OAuth 2.0 for native a= pps. 

 

Given that PKCE is intended for "public client= s" and not specifically native apps, I'm wondering where that leaves b= rowser-based apps. The core spec still says that the implicit grant is reco= mmended for browser-based apps, but it's looking like the recommendation is= to use the authorization code flow + PKCE with no secret for browser-based= apps.

 

<= p class=3DMsoNormal>Am I correct in thinking that the general recommendatio= n would be to use the authorization code flow with no secret, and even bett= er to use PKCE for browser-based apps?


----

Aaron Parecki

 

 

= --_D29378EF-09F4-45F1-9F87-32CC3D71E85F_-- --94eb2c1168accdbc740546f45db9 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIKG9QlpfnNcq3edGxky77jGAFLeV fFwq2wXGHaOKjifcMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDEyNjAwMjQwM1owaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQB180lugkqwlOoqdL2TJv9bSSIJie5G5dPclkenSLcodkeB tyJQR6moR8fr/S6DgcUqXeL4jJ5BE7Vqu/U+yyuHTFIk5Ib6XIS7NIlD7t29PQK+EqwyWxkXhgNf CADUhsJQ1fRDfVOzmiaw5dVQ1Ys574ia9TgyxJJUk8FTPqMsEkc4MudFEPiqL0ZMeVMq01Cu5vFr BNfJQIYez3FTLF9lbC4BpIwVdozNE8Zp7SM5Vm33/pglsZOiRDlPasGdHG9tkgWUGJGo553ciOdo /RXgSTHVBoyJXDpb5nRIZlz8FCUqT+iF8huv00AtlqOdWhgFBNOi0lfPP/EUEHZh53Bl --94eb2c1168accdbc740546f45db9-- From nobody Wed Jan 25 16:43:31 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C6112943F for ; Wed, 25 Jan 2017 16:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=parecki-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVBY7pAi8mFj for ; Wed, 25 Jan 2017 16:43:28 -0800 (PST) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB0CF12943D for ; Wed, 25 Jan 2017 16:43:27 -0800 (PST) Received: by mail-ua0-x229.google.com with SMTP id 35so172104093uak.1 for ; Wed, 25 Jan 2017 16:43:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parecki-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=02Z8rH6/K82BfbjiBwPlBZnSnMzTgMY4MFkGLzxuHRU=; b=xvaKankpIdNGmejuFSyNf947Yj60m+lg+j2V7MrlGzKLbnrMxViiHN0U/WSZeRiCY0 JjzIJa4pyW5wGQMqYoQuvYBQP+fLu3UFKJjODuuz1ve2bcejHJvs2Li0EZU4r8Xm6wGL /JDqt53yosuG4947smkVeYBR9suFjWoKjAKVjnYLcpA2sMa/yUoSu6lJOkdxKTfBSULD Sr+K85x0SMtpTED9Z7Z9lrXbiCBNnZKjkn2qEoHQftsqe4WB+5HqNHnmG/YZRwLhQpx4 ksPTLNIrWUvjKEW9f5Bc68k9k8TkL7m7Qn3fGiSftly7JSzi0tmspwzR2+Nqoc8TO+oN fE0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=02Z8rH6/K82BfbjiBwPlBZnSnMzTgMY4MFkGLzxuHRU=; b=XTrTmq41FukamrykMxdvmTdg48CmOX+Dfc4HmgCQwgjpU6jqEt6FBoQbMofXMOf0/9 turGxq1uA2XoX5meE4379jZhmDgqA4PoZeQC/FZId35SrnDYQ30nhUDKUqTwCNQq2Yyx ILQ8dcMRjje4aCnxOtXJLkSMKyeqSCjaR3+aXfbgmbkgiO+6LXtc0Ij2Cib3aMmk6ba/ vU5NHVRvxhDQEtsVEGbcC9QKljgYiGT7IeotdfsLEzzWehy8y4F+OdX37qyTrYFSyNUb r/ScS5ALPDHYoGqwRAjGKVteTn1tnOJJwNdeqlU/I+CGObAqHQ/u+CoxDPcL/z4kXJpw PVAg== X-Gm-Message-State: AIkVDXKSCOALFjcdmWbD2bY6JCEernGOkzkZL0xfez4dXOPLIQZd3OTUOsacuwEbiFXq7g== X-Received: by 10.176.16.73 with SMTP id g9mr90611uab.92.1485391406569; Wed, 25 Jan 2017 16:43:26 -0800 (PST) Received: from mail-vk0-f46.google.com (mail-vk0-f46.google.com. [209.85.213.46]) by smtp.gmail.com with ESMTPSA id i8sm9790525uad.3.2017.01.25.16.43.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Jan 2017 16:43:26 -0800 (PST) Received: by mail-vk0-f46.google.com with SMTP id x75so145446528vke.2 for ; Wed, 25 Jan 2017 16:43:25 -0800 (PST) X-Received: by 10.31.63.88 with SMTP id m85mr58169vka.158.1485391405736; Wed, 25 Jan 2017 16:43:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.36.132 with HTTP; Wed, 25 Jan 2017 16:43:25 -0800 (PST) In-Reply-To: <588941a1.1121620a.1d24d.86e2@mx.google.com> References: <588941a1.1121620a.1d24d.86e2@mx.google.com> From: Aaron Parecki Date: Wed, 25 Jan 2017 16:43:25 -0800 X-Gmail-Original-Message-ID: Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=001a114dccfe176f700546f4a3a4 Archived-At: Cc: OAuth WG Subject: Re: [OAUTH-WG] Recommendations for browser-based apps X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 00:43:29 -0000 --001a114dccfe176f700546f4a3a4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yeah, I guess the terminology now is "single-page apps." These apps don=E2=80=99t by definition need offline access as they go away = when the > user is not present. I'm sure there are plenty of cases of people creating SPAs that store the access token in a cookie or Local Storage and resume that session when the user loads the browser again. Not that it's necessarily a good idea, but I'm sure it's been done. It seems like avoiding the concerns of the Implicit flow described in the threat model by using the authorization code flow is a good idea anyway, especially as these single-page apps start to look more and more like native apps. Basically I'm struggling to think of a reason to recommend using the Implicit flow when it's not much harder to use the authorization code flow in the first place. ---- Aaron Parecki aaronparecki.com @aaronpk On Wed, Jan 25, 2017 at 4:24 PM, wrote: > It depends on what you mean by browser based apps. > > > > In general for single page apps that are java script executing in the > browser dom, the recommendation would be implicit flow. > > > > These apps don=E2=80=99t by definition need offline access as they go awa= y when > the user is not present. > > > > We have talked about developing guidance for single page apps, but don=E2= =80=99t > have anything yet. > > > > I think it needs to be thought through again now that new things like > service workers are available, and we will eventually get token binding i= n > the browser (hint it is on in IE and Edge on windows 10 preview and in > Chrome behind a feature flag now) > > > > You could use the PKCE appAuth type flow in a SPA app if you have the > correct CORS setup. > > I however cant at this point say that you are getting improved security > for the extra work in that environment. > > > > John B. > > Sent from Mail for > Windows 10 > > > > *From: *Aaron Parecki > *Sent: *January 25, 2017 3:12 PM > *To: *OAuth WG > *Subject: *[OAUTH-WG] Recommendations for browser-based apps > > > > Thanks to the new "OAuth 2.0 for Native Apps" and PKCE documents, we have > a solid recommendation for how to do OAuth 2.0 for native apps. > > > > Given that PKCE is intended for "public clients" and not specifically > native apps, I'm wondering where that leaves browser-based apps. The core > spec still says that the implicit grant is recommended for browser-based > apps, but it's looking like the recommendation is to use the authorizatio= n > code flow + PKCE with no secret for browser-based apps. > > > > Am I correct in thinking that the general recommendation would be to use > the authorization code flow with no secret, and even better to use PKCE f= or > browser-based apps? > > > ---- > > Aaron Parecki > > aaronparecki.com > > > > > --001a114dccfe176f700546f4a3a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yeah, I guess the terminology now is "single-page app= s."

These apps don=E2=80=99t by definit= ion need offline access as they go away when the user is not present.

I'm sure there are plenty of cases of people= creating SPAs that store the access token in a cookie or Local Storage and= resume that session when the user loads the browser again. Not that it'= ;s necessarily a good idea, but I'm sure it's been done.
<= div>
It seems like avoiding the concerns of the Implicit flow= described in the threat model=C2=A0by using the authorization code flow is a good i= dea anyway, especially as these single-page apps start to look more and mor= e like native apps.

Basically I'm struggling t= o think of a reason to recommend using the Implicit flow when it's not = much harder to use the authorization code flow in the first place.

----
Aaron Parec= ki


On Wed, Jan 25, 2017 at 4:24 PM, <ve7jtb@= ve7jtb.com> wrote:

It depends on what you mean by bro= wser based apps.

=C2=A0

In general for single page apps that are java script executi= ng in the browser dom, the recommendation would be implicit flow.

=C2=A0

These apps= don=E2=80=99t by definition need offline access as they go away when the u= ser is not present.

=C2=A0

We have talked about developing guidance for single page = apps, but don=E2=80=99t have anything yet.

=C2=A0

I think it needs to be thought thr= ough again now that new things like service workers are available, and we w= ill eventually get token binding in the browser (hint it is on in IE and Ed= ge on windows 10 preview and in Chrome behind a feature flag now)

=C2=A0

You could = use the PKCE appAuth type flow in a SPA app if you have the correct CORS se= tup.

I however cant at this point say that you ar= e getting improved security for the extra work in that environment.

=C2=A0

John B.

Sent from Mail for Windows 10

=C2=A0

From: Aaron Parecki
Sent: January 25, 2017 3= :12 PM
To: OA= uth WG
Subject: [OAUTH-WG] Recommendations for browser-based = apps

=C2=A0

Thanks to the new "OAuth 2.0= for Native Apps" and PKCE documents, we have a solid recommendation f= or how to do OAuth 2.0 for native apps.=C2=A0

=C2=A0

Given tha= t PKCE is intended for "public clients" and not specifically nati= ve apps, I'm wondering where that leaves browser-based apps. The core s= pec still says that the implicit grant is recommended for browser-based app= s, but it's looking like the recommendation is to use the authorization= code flow + PKCE with no secret for browser-based apps.

=C2=A0

Am I correct in thinking that the general recommendation would be to use = the authorization code flow with no secret, and even better to use PKCE for= browser-based apps?


=

----

Aaron Parecki

=C2=A0

=C2=A0


<= /div> --001a114dccfe176f700546f4a3a4-- From nobody Thu Jan 26 07:04:00 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A94212965F for ; Thu, 26 Jan 2017 07:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVcGp7TEZqKU for ; Thu, 26 Jan 2017 07:03:56 -0800 (PST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1E812965A for ; Thu, 26 Jan 2017 07:03:56 -0800 (PST) Received: from mfilter38-d.gandi.net (mfilter38-d.gandi.net [217.70.178.169]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 8C47CA8113; Thu, 26 Jan 2017 16:03:54 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter38-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter38-d.gandi.net (mfilter38-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id m4ZsKynTWipz; Thu, 26 Jan 2017 16:03:52 +0100 (CET) X-Originating-IP: 10.58.1.149 Received: from webmail.gandi.net (webmail9-d.mgt.gandi.net [10.58.1.149]) (Authenticated sender: dario.teixeira@nleyten.com) by relay3-d.mail.gandi.net (Postfix) with ESMTPA id 03E36A80E5; Thu, 26 Jan 2017 16:03:51 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 26 Jan 2017 15:03:51 +0000 From: Dario Teixeira To: ve7jtb@ve7jtb.com In-Reply-To: <5889010c.06d0620a.31d79.5dd8@mx.google.com> References: <5889010c.06d0620a.31d79.5dd8@mx.google.com> Message-ID: <71dcfb6cdbaa14f8d70db92ac7843d84@nleyten.com> X-Sender: dario.teixeira@nleyten.com User-Agent: Roundcube Webmail/1.1.2 Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 15:03:58 -0000 Hi, And thanks for the prompt reply! > I prefer the AppAuth pattern where the native app is a OAuth client to > your server and you are protecting your API with OAuth. Your AS > becomes a Connect/SAML/Twitter auth/ Facebook etc relying party and > uses federated or local authentication to issue tokens. (this gives > your backend API access to user info) I'm not sure I followed due to the use of non-standard terminology... What do you mean by "OAuth client" - the Relying Party? And what about AS? Is that the Authorization Server, Application Server, or what? (One of the frustrating aspects of learning about OAuth2 and OIDC is that not everyone uses the standard terminology.) > The other pattern is for the native app to be a Connect client to > Google or other IdP and then passes a id_token (not access token) to > your backend in some secure manor and your backend validates the > signature on the id_token and that it was issued to your client > (verification is essential) (the native app gets access to user info > api) You still have the problem of how you secure your API, as you > need to exchange the validated id_token with something. I thnk that > doing this securely winds up being more complicated than the first > option. The same problem as above. I cannot find "Connect client" anywhere on the OIDC terminology. And is IdP what the standard calls OP? I don't mean to sound ungrateful, but when a newcomer asks a basic question is usually a bad idea to throw a lot of jargon or non standard terminology at them... Best regards, Dario Teixeira From nobody Thu Jan 26 07:11:21 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0BDB12966F for ; Thu, 26 Jan 2017 07:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTKlkTcfgMhI for ; Thu, 26 Jan 2017 07:11:19 -0800 (PST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7699E129669 for ; Thu, 26 Jan 2017 07:11:19 -0800 (PST) Received: from mfilter32-d.gandi.net (mfilter32-d.gandi.net [217.70.178.163]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 80511172287; Thu, 26 Jan 2017 16:11:17 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter32-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter32-d.gandi.net (mfilter32-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id onr4v13dpQxz; Thu, 26 Jan 2017 16:11:16 +0100 (CET) X-Originating-IP: 10.58.1.149 Received: from webmail.gandi.net (webmail9-d.mgt.gandi.net [10.58.1.149]) (Authenticated sender: dario.teixeira@nleyten.com) by relay4-d.mail.gandi.net (Postfix) with ESMTPA id 165321722D0; Thu, 26 Jan 2017 16:11:15 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 26 Jan 2017 15:11:15 +0000 From: Dario Teixeira To: Justin Richer In-Reply-To: <2fc78923-95a7-7def-3d59-65231f43ad0b@mit.edu> References: <2fc78923-95a7-7def-3d59-65231f43ad0b@mit.edu> Message-ID: <5cdb51be0bcd39826c1f8dd4c472f843@nleyten.com> X-Sender: dario.teixeira@nleyten.com User-Agent: Roundcube Webmail/1.1.2 Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 15:11:20 -0000 Hi, And thanks for the prompt reply! > I would recommend making the mobile app the RP, and having the server > be an additional protected resource that accepts access tokens from > the mobile app. This is how it's commonly handled, and there are > libraries (such as Google's AppAuth) that handle most of these > interactions. So basically the mobile app performs all the steps until it gets the ID token from the OIDC Provider, and then sends this token to my server, who must check the signature of the token to make sure it really came from the OIDC Provider. I'm just wondering how durable this solution is. Suppose the OIDC Provider would change their signing key; my server would then falsely reject valid tokens unless it periodically checked for public key updates (or does this never/seldom happen?). Best regards, Dario Teixeira From nobody Thu Jan 26 07:13:47 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F34F129686 for ; Thu, 26 Jan 2017 07:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAFHmTOrAtLT for ; Thu, 26 Jan 2017 07:13:45 -0800 (PST) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49644129672 for ; Thu, 26 Jan 2017 07:13:45 -0800 (PST) Received: from mfilter17-d.gandi.net (mfilter17-d.gandi.net [217.70.178.145]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id D1199C5A76; Thu, 26 Jan 2017 16:13:43 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter17-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter17-d.gandi.net (mfilter17-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id FO6W7HpSymdV; Thu, 26 Jan 2017 16:13:42 +0100 (CET) X-Originating-IP: 10.58.1.149 Received: from webmail.gandi.net (webmail9-d.mgt.gandi.net [10.58.1.149]) (Authenticated sender: dario.teixeira@nleyten.com) by relay2-d.mail.gandi.net (Postfix) with ESMTPA id 1BC8CC5A74; Thu, 26 Jan 2017 16:13:41 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 26 Jan 2017 15:13:41 +0000 From: Dario Teixeira To: "Phil Hunt (IDM)" In-Reply-To: <823CE48E-D778-4704-B13D-B6C302ED14D6@oracle.com> References: <5889010c.06d0620a.31d79.5dd8@mx.google.com> <823CE48E-D778-4704-B13D-B6C302ED14D6@oracle.com> Message-ID: <093116990b28d9837f42a7477fc09d80@nleyten.com> X-Sender: dario.teixeira@nleyten.com User-Agent: Roundcube Webmail/1.1.2 Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 15:13:46 -0000 Hi, > +1 to AppAuth > > One disturbing pattern I see for mobile apps relaying the idtoken is > that the aud isn't checked by the AS in the Oauth exchange. This in > part caused by the fact that the mobile app has two client-id > identifiers. If the aud only has the clientid for the OIDC call this > can be a problem if the AS doesn't know what that id is (since it > didnt issue the id). If the issued id token does not have an aud value > the AS can recognize it should be rejected. Is the AppAuth pattern documented somewhere? There's a chance I may not be able to use Google's libraries... Best regards, Dario Teixeira From nobody Thu Jan 26 07:18:44 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE1E1295A5 for ; Thu, 26 Jan 2017 07:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SogAyhmdBotb for ; Thu, 26 Jan 2017 07:18:42 -0800 (PST) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB8CC129670 for ; Thu, 26 Jan 2017 07:18:41 -0800 (PST) Received: from mfilter48-d.gandi.net (mfilter48-d.gandi.net [217.70.178.179]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id A7C3BC5A87; Thu, 26 Jan 2017 16:18:40 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter48-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter48-d.gandi.net (mfilter48-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id sQ3PtdGCFVpQ; Thu, 26 Jan 2017 16:17:55 +0100 (CET) X-Originating-IP: 10.58.1.149 Received: from webmail.gandi.net (webmail9-d.mgt.gandi.net [10.58.1.149]) (Authenticated sender: dario.teixeira@nleyten.com) by relay2-d.mail.gandi.net (Postfix) with ESMTPA id A72A3C5A43; Thu, 26 Jan 2017 16:17:54 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 26 Jan 2017 15:17:54 +0000 From: Dario Teixeira To: ve7jtb@ve7jtb.com In-Reply-To: <71dcfb6cdbaa14f8d70db92ac7843d84@nleyten.com> References: <5889010c.06d0620a.31d79.5dd8@mx.google.com> <71dcfb6cdbaa14f8d70db92ac7843d84@nleyten.com> Message-ID: <96e6de7b359a34970401e677bfccb6a4@nleyten.com> X-Sender: dario.teixeira@nleyten.com User-Agent: Roundcube Webmail/1.1.2 Archived-At: Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 15:18:43 -0000 Hi, > I'm not sure I followed due to the use of non-standard terminology... > What do you mean by "OAuth client" - the Relying Party? And what > about AS? Is that the Authorization Server, Application Server, > or what? (One of the frustrating aspects of learning about OAuth2 > and OIDC is that not everyone uses the standard terminology.) Btw, I strongly suspect that AS stands for OAuth2's "Authorization Server". Is that correct? Best regards, Dario Teixeira From nobody Thu Jan 26 07:38:29 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E383D1296D2 for ; Thu, 26 Jan 2017 07:38:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bp1FPMTH6lZQ for ; Thu, 26 Jan 2017 07:38:25 -0800 (PST) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36DBC1296D1 for ; Thu, 26 Jan 2017 07:38:25 -0800 (PST) Received: by mail-pf0-x235.google.com with SMTP id e4so65939688pfg.1 for ; Thu, 26 Jan 2017 07:38:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=message-id:mime-version:to:cc:from:subject:date:importance :in-reply-to:references; bh=UExVGCnDKcDCX37yqVPi9xbza6VD8fEswAYqjDUIVHI=; b=L7/O//ptsyQdKHhstoqt6i0kv0xXdkrXWvzw4VQCJ7kXv7OBv8N62nYVEbjAc+MtD3 51JrFypAdJXlW0Zvk+qKNdcQABTZSYFySY+XkcQl40+SXMWfIpGkB2DD3DPQYfaTiruo MXI/3qy7o69UOiDAuyhkzuoNC7pqgF7GEElcauLKVUZcyqCOJIfpEoD/weUx4A9TfpKR KsPxhsQwRVzA4aM2KSioUvT3JWaF5tJLICQVzJmhJqhXLxeo6J3uYcA66vgezYZdTtS/ 49sxGO46wESRWp4cJkU9OqIfMJ41pjT9JDog/aSxFLZLL717IDT9Op3q/VKDHTzuWGmj 3mqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:cc:from:subject:date :importance:in-reply-to:references; bh=UExVGCnDKcDCX37yqVPi9xbza6VD8fEswAYqjDUIVHI=; b=PJHJCJBv7VCrJX/ygBq+plFM1jLR1bs0sZijeXxHIPIJrPLVUfEoRJRzbn29igYBe1 axPw7WtOxoZh7PFML+u1CUia/mRpodsyD0ogBsHXIV3ePIj8Jz3uTCHNtmN7+/uS3xgV gLIubg6wf/Ua1piYEkfJtRi2UnceiO8hnnlEU7QTKjH2f+jFpA+fCHATYd0enk9oSXnl Edo45+yqs4PoPJcR4EywHhs5c03zL7Lk2NHlWkMjnoJs2fZx4iBzrjep8Tve9zIaozbA gecJp+CxVp7jpZTzX0mlVmhfvkB8b41rCkYAC7R3pv/oxb4oaDAMqX0zSnvxhXfoXBev p4nQ== X-Gm-Message-State: AIkVDXJGXYQ7KuWh8gqt3f6ViQl0n73CX50/1yj2/rms9X9AAxqneWOpCGMtQwfaCSfeXGzZ X-Received: by 10.99.60.76 with SMTP id i12mr3727878pgn.170.1485445104590; Thu, 26 Jan 2017 07:38:24 -0800 (PST) Received: from ?IPv6:2001:569:7128:2400:7d1e:7c4e:5cfd:28bc? (node-1w7jr9qhemndc5lwqk1n37ovw.ipv6.telus.net. [2001:569:7128:2400:7d1e:7c4e:5cfd:28bc]) by smtp.gmail.com with ESMTPSA id a24sm4412941pfh.33.2017.01.26.07.38.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jan 2017 07:38:23 -0800 (PST) Message-ID: <588a17ef.18d4620a.cd88d.c109@mx.google.com> MIME-Version: 1.0 To: Dario Teixeira From: Date: Thu, 26 Jan 2017 07:38:23 -0800 Importance: normal X-Priority: 3 In-Reply-To: <71dcfb6cdbaa14f8d70db92ac7843d84@nleyten.com> References: <5889010c.06d0620a.31d79.5dd8@mx.google.com> <71dcfb6cdbaa14f8d70db92ac7843d84@nleyten.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403045c562ace883805470123d1" Archived-At: Cc: "oauth@ietf.org" Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 15:38:28 -0000 --f403045c562ace883805470123d1 Content-Type: multipart/alternative; boundary="_8697CBC1-F30D-492B-8F2C-B4FE8ABE47AC_" --_8697CBC1-F30D-492B-8F2C-B4FE8ABE47AC_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Unfortunately RFC 6749 lacks a terminology section. >From Connect we have http://openid.net/specs/openid-connect-core-1_0.html#T= erminology (AS) is a common abbreviation for Authorization server. In sec 1.1 of OAuth https://tools.ietf.org/html/rfc6749#section-1.1 Roles are defined Client and authorization server. Given that we have two sorts of clients one as defined by OAuth that is doi= ng authorization only and one using the Connect extensions that is addition= ally doing Authentication I refer to them as OAuth client and Connect clien= t. A connect client being a OAuth client using the Connect extensions for= authentication (id_token etc). The connect spec calls it a client and as it is the connect spec the connec= t part is implied. OpenID Provider (OP) is a term going back to OpenID 1. Generic identity s= tandards like SP-800-63-3 https://pages.nist.gov/800-63-3/sp800-63-3.html#s= ec3 Use the term Identity Providers (IdP) to refer to servers providing fe= derated identity using any protocol. (Note to NIST the term Identity provider is used but not defined in terms. = Probably obvious to the authors, but not neccicarily to the reader=F0=9F= =98=8A My point being that twitter, facebook and some others do not do OpenID Conn= ect so are not technically OP. I could use relying while in the middle of a Fido meeting as a excuse but e= veryone knows that even if I had taken the time it would have come out abou= t the same. Hope that helps. John B. Sent from Mail for Windows 10 From: Dario Teixeira Sent: January 26, 2017 7:03 AM To: ve7jtb@ve7jtb.com Cc: oauth@ietf.org Subject: RE: [OAUTH-WG] OAuth2/OIDC for client-server mobile app Hi, And thanks for the prompt reply! > I prefer the AppAuth pattern where the native app is a OAuth client to > your server and you are protecting your API with OAuth. Your AS > becomes a Connect/SAML/Twitter auth/ Facebook etc relying party and > uses federated or local authentication to issue tokens. (this gives > your backend API access to user info) I'm not sure I followed due to the use of non-standard terminology... What do you mean by "OAuth client" - the Relying Party? And what about AS? Is that the Authorization Server, Application Server, or what? (One of the frustrating aspects of learning about OAuth2 and OIDC is that not everyone uses the standard terminology.) > The other pattern is for the native app to be a Connect client to > Google or other IdP and then passes a id_token (not access token) to > your backend in some secure manor and your backend validates the > signature on the id_token and that it was issued to your client > (verification is essential) (the native app gets access to user info > api) You still have the problem of how you secure your API, as you > need to exchange the validated id_token with something. I thnk that > doing this securely winds up being more complicated than the first > option. The same problem as above. I cannot find "Connect client" anywhere on the OIDC terminology. And is IdP what the standard calls OP? I don't mean to sound ungrateful, but when a newcomer asks a basic question is usually a bad idea to throw a lot of jargon or non standard terminology at them... Best regards, Dario Teixeira --_8697CBC1-F30D-492B-8F2C-B4FE8ABE47AC_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

Unfortunately RFC 6749 =C2=A0lacks a= terminology section.

 

From Connect we have http://openid.net/specs/openid-connect-= core-1_0.html#Terminology

 

=

(AS) is a common abbreviation for Authorization server= .

 

In sec = 1.1 of OAuth ht= tps://tools.ietf.org/html/rfc6749#section-1.1

<= o:p> 

Roles are defined Client and autho= rization server.

 

Given that we have two sorts of clients one as defined by OAuth tha= t is doing authorization only and one using the Connect extensions that is = additionally doing Authentication I refer to them as OAuth client and Conne= ct client.=C2=A0=C2=A0 A connect client being a OAuth client using the Conn= ect extensions for authentication (id_token etc).

<= o:p> 

The connect spec calls it a client= and as it is the connect spec the connect part is implied.

 

OpenID Provider (OP) is = a term going back to OpenID 1.=C2=A0=C2=A0 Generic identity standards like = SP-800-63-3 https://pages.nist.gov/800-63-3/sp800-6= 3-3.html#sec3=C2=A0 Use the term Identity Providers (IdP) to ref= er to servers providing federated identity using any protocol.

(Note to NIST the term Identity provider is used but not defin= ed in terms.=C2=A0 Probably obvious to the authors, but not neccicarily to = the reader😊=

 

M= y point being that twitter, facebook and some others do not do OpenID Conne= ct so are not technically OP.

 

=

I could use relying while in the middle of a Fido meet= ing as a excuse but everyone knows that even if I had taken the time it wou= ld have come out about the same.

 <= /p>

 

Hope that= helps.

 

J= ohn B.

 

 

 

Sent from Mail for Windows 10

 

From: Da= rio Teixeira
Sent: January 26, 2017 7:03 AM
To: ve7jtb@ve7jtb.com
Cc: oauth@ietf.org
Subject: RE: [OAU= TH-WG] OAuth2/OIDC for client-server mobile app

 

Hi,

 

And thanks for the prompt reply!

 

> I pref= er the AppAuth pattern where the native app is a OAuth client to

> your server and you are protecting your API with OAuth.= =C2=A0=C2=A0 Your AS

> becomes a Connect/SAML/Tw= itter auth/ Facebook etc relying party and

> use= s federated or local authentication to issue tokens.=C2=A0 (this gives

<= p class=3DMsoNormal>> your backend API access to user info)

 

I'm not sure I follo= wed due to the use of non-standard terminology...

W= hat do you mean by "OAuth client" - the Relying Party?=C2=A0 And = what

about AS? Is that the Authorization Server, Ap= plication Server,

or what?=C2=A0 (One of the frustr= ating aspects of learning about OAuth2

and OIDC is = that not everyone uses the standard terminology.)

<= o:p> 

 

> The other pattern is for the native app to be a Connect client= to

> Google or other IdP and then passes a id_t= oken (not access token) to

> your backend in som= e secure manor and your backend validates the

> = signature on the id_token and that it was issued to your client

> (verification is essential) (the native app gets access t= o user info

> api)=C2=A0 You still have the prob= lem of how you secure your API, as you

> need to= exchange the validated id_token with something.=C2=A0=C2=A0 I thnk that

> doing this securely winds up being more complica= ted than the first

> option.

 

The same problem as above. I= cannot find "Connect client" anywhere

on= the OIDC terminology. And is IdP what the standard calls OP?

 

I don't mean to soun= d ungrateful, but when a newcomer asks a basic

ques= tion is usually a bad idea to throw a lot of jargon or non

standard terminology at them...

 =

Best regards,

Dario = Teixeira

 

=  

= --_8697CBC1-F30D-492B-8F2C-B4FE8ABE47AC_-- --f403045c562ace883805470123d1 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEICJpu1v6N5vCKgXcZimo+4qSB0X7 BLcId20b2EnxUqyFMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDEyNjE1MzgyNFowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQCbvIMrGI4tDeesUmjuk86SLxyHCnvcKsEwW144WUSgpG49 KzGQRTUsulgO4+6XuCIXHMRK/y7KRtYdjPdKMyTuGq5DONaeRTDRL+vecKjkgpXOWbsyvYYtuP8+ tH2uLCVDrfvUowwSdTwWUuKCj4A0OM+H9tEGZhwywRlTq0kMVE8FB9XARtq+T7wKpTACFY4ovHG6 MnnygBZku3olhUjdYRF1sGWBD1AqaHbAS133oRdSnhWgOHyqlG6FV+QSzEnbHkS+KUVSAEiHal8a uQ+QQXQwacRHRPiYp1tEhGQJ7Ij9ooDVdIwGev3imTsehWJUk/d8KAqFW0SwiZnI+6kJ --f403045c562ace883805470123d1-- From nobody Thu Jan 26 08:24:24 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2CB129881 for ; Thu, 26 Jan 2017 08:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQkQuZihGJYz for ; Thu, 26 Jan 2017 08:24:22 -0800 (PST) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D980F1297F1 for ; Thu, 26 Jan 2017 08:24:21 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id c7so36842653itd.1 for ; Thu, 26 Jan 2017 08:24:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zsn61a+VBAqmOK23TThiO8txLhJNiToTGj1UtXZ+itY=; b=hA8e7Fkr1cyPAT9Hd05+e43tHkdn29O0na5ynO/R1A6QxpP7AePbeEgW2VoDKkDomI 0Fu6af6dek/G9SvVcUnW1U0zNItUpTtWhkopSbYvKcNYb6Eev4rKS3D3Cq9M3DBN866K TE9hcE7hxHON/zYHjNUakf0bpijSkyW1PwzqUftlS2vGR3eiggliFQ1KAhYnw1viqHjG qNDSwT1d+xD6KsMQygQCfY6LzjHh155lZdL7zW89QUw7hIxgt+ihVzVVqMz2V6ksG3Aq 48SEwS0s56xc1y9v/4FLap89aOveX6/icbu23Zp2lfWM+fUO2fBH7Nj7hevrrxO1vMdF z/Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zsn61a+VBAqmOK23TThiO8txLhJNiToTGj1UtXZ+itY=; b=KiKLBaLO/+F3uvWz7lCaaeWPYy5iUwdVy0hF8UjaXJqFZSQt09J72aCUAcmORLgpKI 1QiO3hVPRhxbikzN2xXyrK5WNRzswCrxCvvaBISEkfMkDAa/vkgokD4ybDPXF8C45egO 4l8TwdhTY8JoKFQBZ3Vmqj6bRJ+aiCcM+JFoBpQEPqBNLWq2qiMTkDKut0EgWOzwqs65 D1qTByEwQ7HWlC+LHkIO2jjnNebYv4j2QOEBIMUR/vi9XNlHHAfGgCB/NHNSXwawgaW8 DuBIgGyK4X5HhW2DyIWQAR2b+lG7U4d6Usg9gawed1VehHI3CGKPM2s1gsISWS6hEf10 CaHQ== X-Gm-Message-State: AIkVDXIT2mRCFLMzC5vKhdrbyBlzUGPDZu1gYI74IuDPsrGwwPUqLVBZFzAZxxKl+zoklu+O8eec6jr02uR4Bje1 X-Received: by 10.36.101.211 with SMTP id u202mr16754766itb.47.1485447860944; Thu, 26 Jan 2017 08:24:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.150.207 with HTTP; Thu, 26 Jan 2017 08:24:20 -0800 (PST) X-Originating-IP: [172.56.7.214] Received: by 10.79.150.207 with HTTP; Thu, 26 Jan 2017 08:24:20 -0800 (PST) In-Reply-To: <093116990b28d9837f42a7477fc09d80@nleyten.com> References: <5889010c.06d0620a.31d79.5dd8@mx.google.com> <823CE48E-D778-4704-B13D-B6C302ED14D6@oracle.com> <093116990b28d9837f42a7477fc09d80@nleyten.com> From: John Bradley Date: Thu, 26 Jan 2017 13:24:20 -0300 Message-ID: To: Dario Teixeira Content-Type: multipart/alternative; boundary=001a1145a216159eaa054701c840 Archived-At: Cc: IETF oauth WG Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 16:24:23 -0000 --001a1145a216159eaa054701c840 Content-Type: text/plain; charset=UTF-8 https://tools.ietf.org/html/draft-ietf-oauth-native-apps They are OpenID foundation library's not Google's. Google, Ping and a number of others are active contributors if you look at the git repositories. John B. On Jan 26, 2017 7:13 AM, "Dario Teixeira" wrote: > Hi, > > +1 to AppAuth >> >> One disturbing pattern I see for mobile apps relaying the idtoken is >> that the aud isn't checked by the AS in the Oauth exchange. This in >> part caused by the fact that the mobile app has two client-id >> identifiers. If the aud only has the clientid for the OIDC call this >> can be a problem if the AS doesn't know what that id is (since it >> didnt issue the id). If the issued id token does not have an aud value >> the AS can recognize it should be rejected. >> > > Is the AppAuth pattern documented somewhere? There's a chance I may not > be able to use Google's libraries... > > Best regards, > Dario Teixeira > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --001a1145a216159eaa054701c840 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
They are OpenID foundation libra= ry's not Google's. =C2=A0 Google, Ping and a number of others are a= ctive contributors if you look at the git repositories.=C2=A0

John B. =C2=A0

On Jan 26, 2017 7:13 AM, &q= uot;Dario Teixeira" <= dario.teixeira@nleyten.com> wrote:
Hi,

+1 to AppAuth

One disturbing pattern I see for mobile apps relaying the idtoken is
that the aud isn't checked by the AS in the Oauth exchange. This in
part caused by the fact that the mobile app has two client-id
identifiers. If the aud only has the clientid for the OIDC call this
can be a problem if the AS doesn't know what that id is (since it
didnt issue the id). If the issued id token does not have an aud value
the AS can recognize it should be rejected.

Is the AppAuth pattern documented somewhere? There's a chance I may not=
be able to use Google's libraries...

Best regards,
Dario Teixeira

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
--001a1145a216159eaa054701c840-- From nobody Thu Jan 26 08:51:53 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA505129881 for ; Thu, 26 Jan 2017 08:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tni1WIH_hubY for ; Thu, 26 Jan 2017 08:51:50 -0800 (PST) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 522E01297F1 for ; Thu, 26 Jan 2017 08:51:50 -0800 (PST) Received: from mfilter49-d.gandi.net (unknown [217.70.178.180]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 0B574C5A56; Thu, 26 Jan 2017 17:51:49 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter49-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter49-d.gandi.net (mfilter49-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id lVb38NAJjtWJ; Thu, 26 Jan 2017 17:51:47 +0100 (CET) X-Originating-IP: 10.58.1.149 Received: from webmail.gandi.net (webmail9-d.mgt.gandi.net [10.58.1.149]) (Authenticated sender: dario.teixeira@nleyten.com) by relay2-d.mail.gandi.net (Postfix) with ESMTPA id CD8CEC5A91; Thu, 26 Jan 2017 17:51:46 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 26 Jan 2017 16:51:46 +0000 From: Dario Teixeira To: John Bradley In-Reply-To: References: <5889010c.06d0620a.31d79.5dd8@mx.google.com> <823CE48E-D778-4704-B13D-B6C302ED14D6@oracle.com> <093116990b28d9837f42a7477fc09d80@nleyten.com> Message-ID: X-Sender: dario.teixeira@nleyten.com User-Agent: Roundcube Webmail/1.1.2 Archived-At: Cc: IETF oauth WG Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 16:51:52 -0000 Hi, > https://tools.ietf.org/html/draft-ietf-oauth-native-apps [2] > > They are OpenID foundation library's not Google's. Google, Ping and > a number of others are active contributors if you look at the git > repositories. Thanks for the link. Perhaps I'm missing something, but the AppAuth pattern as described by this document represents only half the picture: at the end of the interaction, the native app is in possession of a token that authenticates the user. However, my server cannot accept that token blindly! Now, the way I would solve this is by keeping a hard-coded list of OpenID Provider public keys on my server, which I would use to verify that the token was indeed signed by the OIP. Correct me if I'm wrong, but this also seems to be the recommended approach, right? Thanks again for your time! Best regards, Dario Teixeira From nobody Thu Jan 26 09:50:34 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB841298BA for ; Thu, 26 Jan 2017 09:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.555 X-Spam-Level: X-Spam-Status: No, score=-8.555 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-1.156, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x86mqKvv8qj9 for ; Thu, 26 Jan 2017 09:50:31 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BA2E12989E for ; Thu, 26 Jan 2017 09:50:31 -0800 (PST) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v0QHoTaR017151 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jan 2017 17:50:30 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.13.8/8.14.4) with ESMTP id v0QHoTt5001276 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jan 2017 17:50:29 GMT Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v0QHoReH029488; Thu, 26 Jan 2017 17:50:27 GMT Received: from [10.0.53.148] (/209.53.70.79) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 26 Jan 2017 09:50:27 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14C92) In-Reply-To: Date: Thu, 26 Jan 2017 09:50:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5889010c.06d0620a.31d79.5dd8@mx.google.com> <823CE48E-D778-4704-B13D-B6C302ED14D6@oracle.com> <093116990b28d9837f42a7477fc09d80@nleyten.com> To: Dario Teixeira X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Cc: IETF oauth WG Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 17:50:33 -0000 Afaik, the client app ends up with an access token (at). It never has to dea= l with id tokens. That all happens by way of the oauth AS server calling oid= c itself. Iow the oauth as is the oidc client. =20 The code in the mobile client is trivial by comparison and does not need to d= o id token validation. Phil > On Jan 26, 2017, at 8:51 AM, Dario Teixeira w= rote: >=20 > Hi, >=20 >> https://tools.ietf.org/html/draft-ietf-oauth-native-apps [2] >> They are OpenID foundation library's not Google's. Google, Ping and >> a number of others are active contributors if you look at the git >> repositories. >=20 > Thanks for the link. Perhaps I'm missing something, but the AppAuth > pattern as described by this document represents only half the picture: > at the end of the interaction, the native app is in possession of a > token that authenticates the user. However, my server cannot accept > that token blindly! >=20 > Now, the way I would solve this is by keeping a hard-coded list of > OpenID Provider public keys on my server, which I would use to > verify that the token was indeed signed by the OIP. Correct me > if I'm wrong, but this also seems to be the recommended approach, > right? >=20 > Thanks again for your time! > Best regards, > Dario Teixeira >=20 From nobody Thu Jan 26 10:00:26 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D7F1298D3 for ; Thu, 26 Jan 2017 10:00:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rech8ERnHZN1 for ; Thu, 26 Jan 2017 10:00:23 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7E9B1298BA for ; Thu, 26 Jan 2017 10:00:22 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id v96so42815557ioi.0 for ; Thu, 26 Jan 2017 10:00:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eqG9/hYBOdpcty8HMZBD+8Rq0823GB7kqigKereyJu0=; b=Z1ydT9AUM+IykL7DDQU3Zslyb/9eIcU+vCX8Hd6YTWcSxr3XVHDuHuXZDtjpsJFFS1 XB9wNnY2/b10gHErfNgKoBKK83My57jPxKyCO0r3fCFmd41+tdc25Uf3qWKwNNBpYqgg MrdFwXuLkk2q5YEbyD48W0TntMJAamsmc3/WE3fxrhRrxxeYjyuxqCNoiCzxm7ESaj7g DzXEH6YI+o69ZvtgOhX9xbzL1wdJKQR6FC4v55ABLRX/bTnn4V5/PsGGNANv/ljOlzBM vPGWiikNfNANX2iSXlDe/9oJoTEEMuBhgP/DbwHCqAAesct8KRLQCg0iEli0H+tTVByZ 6GYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eqG9/hYBOdpcty8HMZBD+8Rq0823GB7kqigKereyJu0=; b=d9nAlL6niuVVS25+fTrgVI++T2x4C3X/qOc4+acxP4fDn8xxlXMq3gwi8qiLE86V4r BqIQaVOniXvaWIFOo29sz06g+IMPkX8g51a57napoUhbIyOgEcxjJ91jbrrCxNmVQB/R Jp1X1wMDAbRn32EHFyAtuhUzZayoXnS2+1gCnus3+RK360PKzLjC9A6qWRGXt//AAHuM WVRdHzsNSAlx/xB2iQeQmfEO1kSJb3Gab6xej0HcQ+hDAemk7Vo5NCoSyKrqp4JNFoC5 egTuhIWg0+n8WLE3pbZZuzQ9/7df8yEv1q6SNNdjzsq4wHiqls2khjrw1Yy2WFzBzqU7 Rk1A== X-Gm-Message-State: AIkVDXI0q3uywvqvf6QnqRAlU3+kfT7XT0gOTebewijPB0IfgLV/dRGDd0UKVObEnusM0O5GS2afU8aeCIHwgRUe X-Received: by 10.107.140.193 with SMTP id o184mr4052427iod.17.1485453621904; Thu, 26 Jan 2017 10:00:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.150.207 with HTTP; Thu, 26 Jan 2017 10:00:21 -0800 (PST) X-Originating-IP: [64.114.255.114] Received: by 10.79.150.207 with HTTP; Thu, 26 Jan 2017 10:00:21 -0800 (PST) In-Reply-To: References: <5889010c.06d0620a.31d79.5dd8@mx.google.com> <823CE48E-D778-4704-B13D-B6C302ED14D6@oracle.com> <093116990b28d9837f42a7477fc09d80@nleyten.com> From: John Bradley Date: Thu, 26 Jan 2017 15:00:21 -0300 Message-ID: To: Dario Teixeira Content-Type: multipart/alternative; boundary=94eb2c0635b876e5b50547031fc7 Archived-At: Cc: IETF oauth WG Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 18:00:25 -0000 --94eb2c0635b876e5b50547031fc7 Content-Type: text/plain; charset=UTF-8 Justin and I are recommending different approaches. My recommendation is that your app do appAuth to your server to get a access token for your API. Your server performs openid connect to google, SAML to salesForce or Facebook Connect to Facebook and manages verification keys. If the user is authenticated by the IdP it then authorizes your app on the device to access your API. Justin is recommending that you build a client/relying party for each IdP into your native app and pass the results of authentication ID_token, Facebook signed request etc to your back end server for it to verify and issue some cookie or webkey (probably not OAuth token) to your App for accessing your API. My recommendation allowed you to protect your API using OAuth and to add or modify IdP for your users without redeploying your native app. Justin's approach avoids you needing to run a OAuth authorization server. ( He has a great open source one you could use). I think it is a style diffrence. I think separating authorization and authentication into two steps is cleaner and easier to maintain over the long term. John B. On Jan 26, 2017 8:51 AM, "Dario Teixeira" wrote: > Hi, > > https://tools.ietf.org/html/draft-ietf-oauth-native-apps [2] >> >> They are OpenID foundation library's not Google's. Google, Ping and >> a number of others are active contributors if you look at the git >> repositories. >> > > Thanks for the link. Perhaps I'm missing something, but the AppAuth > pattern as described by this document represents only half the picture: > at the end of the interaction, the native app is in possession of a > token that authenticates the user. However, my server cannot accept > that token blindly! > > Now, the way I would solve this is by keeping a hard-coded list of > OpenID Provider public keys on my server, which I would use to > verify that the token was indeed signed by the OIP. Correct me > if I'm wrong, but this also seems to be the recommended approach, > right? > > Thanks again for your time! > Best regards, > Dario Teixeira > > --94eb2c0635b876e5b50547031fc7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Justin and I are recommending different approaches. =C2= =A0

My recommendation is that = your app do appAuth to your server to get a access token for your API. =C2= =A0 Your server performs openid connect to google, SAML to salesForce or Fa= cebook Connect to Facebook and manages verification keys. =C2=A0 If the use= r is authenticated by the IdP it then authorizes your app on the device to = access your API. =C2=A0

= Justin is recommending that you build a client/relying party for each IdP i= nto your native app and pass the results of authentication ID_token, Facebo= ok signed request etc to your back end server for it to verify and issue so= me cookie or webkey (probably not OAuth token) to your App for accessing yo= ur API. =C2=A0

My recomm= endation allowed you to protect your API using OAuth and to add or modify I= dP for your users without redeploying your native app.

Justin's approach avoids you needing to = run a OAuth authorization server. =C2=A0 ( He has a great open source one y= ou could use). =C2=A0

I = think it is a style diffrence.=C2=A0 I think separating authorization and a= uthentication into two steps is cleaner and easier to maintain over the lon= g term. =C2=A0

John B. = =C2=A0

On Jan 26, 2017 8:51 AM, "Dario Teixeira" <dario.teixeira@nleyten.com> wrote:
Hi,

https://tools.ietf.org/html/draft-ietf-= oauth-native-apps [2]

They are OpenID foundation library's not Google's.=C2=A0 =C2=A0Goog= le, Ping and
a number of others are active contributors if you look at the git
repositories.

Thanks for the link.=C2=A0 Perhaps I'm missing something, but the AppAu= th
pattern as described by this document represents only half the picture:
at the end of the interaction, the native app is in possession of a
token that authenticates the user.=C2=A0 However, my server cannot accept that token blindly!

Now, the way I would solve this is by keeping a hard-coded list of
OpenID Provider public keys on my server, which I would use to
verify that the token was indeed signed by the OIP.=C2=A0 Correct me
if I'm wrong, but this also seems to be the recommended approach,
right?

Thanks again for your time!
Best regards,
Dario Teixeira

--94eb2c0635b876e5b50547031fc7-- From nobody Thu Jan 26 10:24:18 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF0A12996E for ; Thu, 26 Jan 2017 10:24:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.417 X-Spam-Level: X-Spam-Status: No, score=-7.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfHlCRzb8mY0 for ; Thu, 26 Jan 2017 10:24:14 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30FD312996D for ; Thu, 26 Jan 2017 10:24:14 -0800 (PST) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v0QIOBGm011652 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 26 Jan 2017 18:24:12 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v0QIOAAG030579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jan 2017 18:24:11 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v0QIO840004065; Thu, 26 Jan 2017 18:24:09 GMT Received: from [25.248.230.255] (/24.114.40.83) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 26 Jan 2017 10:24:08 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-DEA8BFE6-5808-4077-9AEA-108ADC754E69 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14C92) In-Reply-To: Date: Thu, 26 Jan 2017 10:24:04 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <5889010c.06d0620a.31d79.5dd8@mx.google.com> <823CE48E-D778-4704-B13D-B6C302ED14D6@oracle.com> <093116990b28d9837f42a7477fc09d80@nleyten.com> To: John Bradley X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: IETF oauth WG Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 18:24:16 -0000 --Apple-Mail-DEA8BFE6-5808-4077-9AEA-108ADC754E69 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable An seeing bad impls with justins pattern. In particular aud is not checked.=20= The idp has to know the rsrc aud or the as has to know the client id the mob= ile app is using with OP provider. It ends up being complex with room for mi= stakes.=20 Phil > On Jan 26, 2017, at 10:00 AM, John Bradley wrote: >=20 > Justin and I are recommending different approaches. =20 >=20 > My recommendation is that your app do appAuth to your server to get a acce= ss token for your API. Your server performs openid connect to google, SAML= to salesForce or Facebook Connect to Facebook and manages verification keys= . If the user is authenticated by the IdP it then authorizes your app on t= he device to access your API. =20 >=20 > Justin is recommending that you build a client/relying party for each IdP i= nto your native app and pass the results of authentication ID_token, Faceboo= k signed request etc to your back end server for it to verify and issue some= cookie or webkey (probably not OAuth token) to your App for accessing your A= PI. =20 >=20 > My recommendation allowed you to protect your API using OAuth and to add o= r modify IdP for your users without redeploying your native app. >=20 > Justin's approach avoids you needing to run a OAuth authorization server. = ( He has a great open source one you could use). =20 >=20 > I think it is a style diffrence. I think separating authorization and aut= hentication into two steps is cleaner and easier to maintain over the long t= erm. =20 >=20 > John B. =20 >=20 >> On Jan 26, 2017 8:51 AM, "Dario Teixeira" wr= ote: >> Hi, >>=20 >>> https://tools.ietf.org/html/draft-ietf-oauth-native-apps [2] >>>=20 >>> They are OpenID foundation library's not Google's. Google, Ping and >>> a number of others are active contributors if you look at the git >>> repositories. >>=20 >> Thanks for the link. Perhaps I'm missing something, but the AppAuth >> pattern as described by this document represents only half the picture: >> at the end of the interaction, the native app is in possession of a >> token that authenticates the user. However, my server cannot accept >> that token blindly! >>=20 >> Now, the way I would solve this is by keeping a hard-coded list of >> OpenID Provider public keys on my server, which I would use to >> verify that the token was indeed signed by the OIP. Correct me >> if I'm wrong, but this also seems to be the recommended approach, >> right? >>=20 >> Thanks again for your time! >> Best regards, >> Dario Teixeira >>=20 --Apple-Mail-DEA8BFE6-5808-4077-9AEA-108ADC754E69 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
An seeing bad impls with justins patte= rn. In particular aud is not checked. 

The idp has to know the rsrc au= d or the as has to know the client id the mobile app is using with OP provid= er. It ends up being complex with room for mistakes. 

Phil

On Jan 26, 2017, at 10:00 AM, John= Bradley <ve7jtb@ve7jtb.com> w= rote:

Justin a= nd I are recommending different approaches.  

My recommendation is that your app do appAuth to your se= rver to get a access token for your API.   Your server performs openid c= onnect to google, SAML to salesForce or Facebook Connect to Facebook and man= ages verification keys.   If the user is authenticated by the IdP it th= en authorizes your app on the device to access your API.  

Justin is recommending that you build= a client/relying party for each IdP into your native app and pass the resul= ts of authentication ID_token, Facebook signed request etc to your back end s= erver for it to verify and issue some cookie or webkey (probably not OAuth t= oken) to your App for accessing your API.  

=
My recommendation allowed you to protect your API us= ing OAuth and to add or modify IdP for your users without redeploying your n= ative app.

Justin's appro= ach avoids you needing to run a OAuth authorization server.   ( He has a= great open source one you could use).  

I think it is a style diffrence.  I think separati= ng authorization and authentication into two steps is cleaner and easier to m= aintain over the long term.  

John B.  

On Jan 26, 2017 8:51 AM, "Dario Teixeira" <dario.teixeira@nleyten.com> wrote:<= br type=3D"attribution">
Hi,

https://tools.ietf.org/html/draft-ietf-oa= uth-native-apps [2]

They are OpenID foundation library's not Google's.   Google, Ping a= nd
a number of others are active contributors if you look at the git
repositories.

Thanks for the link.  Perhaps I'm missing something, but the AppAuth pattern as described by this document represents only half the picture:
at the end of the interaction, the native app is in possession of a
token that authenticates the user.  However, my server cannot accept that token blindly!

Now, the way I would solve this is by keeping a hard-coded list of
OpenID Provider public keys on my server, which I would use to
verify that the token was indeed signed by the OIP.  Correct me
if I'm wrong, but this also seems to be the recommended approach,
right?

Thanks again for your time!
Best regards,
Dario Teixeira

= --Apple-Mail-DEA8BFE6-5808-4077-9AEA-108ADC754E69-- From nobody Fri Jan 27 03:25:39 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8413B1294AD for ; Fri, 27 Jan 2017 03:25:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6vDqpImdUqA for ; Fri, 27 Jan 2017 03:25:36 -0800 (PST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 928E51294AA for ; Fri, 27 Jan 2017 03:25:36 -0800 (PST) Received: from mfilter22-d.gandi.net (mfilter22-d.gandi.net [217.70.178.150]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 1248A172125; Fri, 27 Jan 2017 12:25:35 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter22-d.gandi.net Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter22-d.gandi.net (mfilter22-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id S6I0a9QcinCf; Fri, 27 Jan 2017 12:25:33 +0100 (CET) X-Originating-IP: 10.58.1.149 Received: from webmail.gandi.net (webmail9-d.mgt.gandi.net [10.58.1.149]) (Authenticated sender: dario.teixeira@nleyten.com) by relay4-d.mail.gandi.net (Postfix) with ESMTPA id 29F75172134; Fri, 27 Jan 2017 12:25:32 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 27 Jan 2017 11:25:32 +0000 From: Dario Teixeira To: John Bradley In-Reply-To: References: <5889010c.06d0620a.31d79.5dd8@mx.google.com> <823CE48E-D778-4704-B13D-B6C302ED14D6@oracle.com> <093116990b28d9837f42a7477fc09d80@nleyten.com> Message-ID: X-Sender: dario.teixeira@nleyten.com User-Agent: Roundcube Webmail/1.1.2 Archived-At: Cc: IETF oauth WG Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2017 11:25:38 -0000 Hi, > Justin and I are recommending different approaches. Thanks for the clarification. To make sure there's no further confusion, allow me to define the various parties involved in the exchange: * Native App (NA): the native application running on the user's phone. This application is written by me. * Resource Server (RS): the server application that the NA wishes to communicate with. This application is also written by me, and offers a RESTful API to the NA. * OpenID Provider (OP): a 3rd party organization like Google that is able to authenticate users. * Authorization Endpoint (AE): a server run by the OP. * Token Endpoint (TE): another server run by the OP. * User Agent (UA): a browser running on the user's phone. > Justin is recommending that you build a client/relying party for > each IdP into your native app and pass the results of authentication > ID_token, Facebook signed request etc to your back end server for > it to verify and issue some cookie or webkey (probably not OAuth > token) to your App for accessing your API. To make sure I understood it correctly, here are the steps involved in Justin's scheme: 1. The NA asks the UA to show a webpage with links such as "Login with Google" or "Login with Facebook". Clicking on those links executes a request to the AE of the corresponding OP. The 'redirect_uri' parameter of the request points to the NA. 2. The user clicks on one of the links shown in the UA. 3. The AE sends the NA an Authorization Code. 4. The NA executes a request to the TE of the OP, sending it the Authorization Code obtained in step 3. The 'redirect_uri' parameter of the request points to the NA. 5. The TE sends the NA an ID token. 6. The NA sends the RS this ID token. 7. The RS validates the ID token by checking its signature against a hardcoded list of OP public keys. If valid, it sends back to the NA a cookie that can be used in future requests. It's pretty straightforward, but there's a bunch of corner cases surrounding expiration of tokens and making sure the list of OP public keys are synchronised. > My recommendation is that your app do appAuth to your server to get > a access token for your API. Your server performs openid connect > to google, SAML to salesForce or Facebook Connect to Facebook and > manages verification keys. If the user is authenticated by the > IdP it then authorizes your app on the device to access your API. Again, please allow me to describe the various steps involved in the AppAuth scheme, to make sure we're on the same page: 1. The NA executes a request to the RS, telling it the user wishes to login. It also sends the RS a secret S to be used later. 2. The RS replies with a webpage with links such as "Login with Google" or "Login with Facebook". The 'redirect_uri' present on those links points towards the RS. 3. The NA asks the UA to show the webpage it received in step 2. 4. The user clicks on one of the links shown in the UA. 5. The AE sends the RS an Authorization Code. 6. The RS executes a request to the TE of the OP, sending it the Authorization Code obtained in step 5. The 'redirect_uri' parameter of the request points to the RS. 7. The TE sends the RS an ID token. 8. The RS validates the ID token by checking its signature against a hardcoded list of OP public keys. It now knows that any future requests from the NA with secret S are authentic. There's an obvious problem with this scheme: there's no way for the NA to know when and if the authentication was successful. Did I miss something, or is this a know problem with the AppAuth scheme? Thanks again for your attention! Best regards, Dario Teixeira From nobody Fri Jan 27 08:24:40 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED24129686 for ; Fri, 27 Jan 2017 08:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1VY6ghVdz0h for ; Fri, 27 Jan 2017 08:24:35 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06B4129683 for ; Fri, 27 Jan 2017 08:24:35 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id j18so64202697ioe.2 for ; Fri, 27 Jan 2017 08:24:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KZvXu5YlpGjiZxlvb6rHBeFiHLScx7IkjXzooDDIGqQ=; b=PiShZeXbkCAJ0WtJS+1HUsf3Zi/89Fk6bNXfSkgEyTosguKGiJZik3w63J6jkV8Tp6 NO9fMBmW06kPwCS/d2d1+/08dDGemrnNJ+nWCPAFn88fwoOYjkq8f0UgpXOcBL1yPRPb YKB9u351uK015DX3KXBvPCAVOwTvK/LNZP/gUW/u2kyjOuzjESxC6QDLY159UM/Kfbi2 0flXsN6A1QpSPYmQoquQ/mnNKQmupxRePAfU3mZX+lCdAUitCioh3PsZJgnGv5awgaDO s1nmWsmxz4TUiXtm6wmKVxQDpZaMBQYXmHgbo8HHu/bV4S8XhPzB4ph0clvwleScQyTV 8M3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KZvXu5YlpGjiZxlvb6rHBeFiHLScx7IkjXzooDDIGqQ=; b=QK3kbMaPOXi6/LMvHGuDXtyUFv5NmbNcz9GdfN+RDHq8PKJ5syoGnmfHT+OPt5rnW7 1nKK2dUb9TX6oduwCXzO3BOXUjGaUu+4vNNVBiQiruAecJvZxBbVcBFSZERSp+2Puun6 chVlkZwnerpdqb3OY4Uif3tfe4/wuLB2BVZ0lu3Sybh3NFVCAmlCFjWUoj+c3A8MsgNj DTA5uxNej7O4T4TRU+jYFAx7Yisi6mFyreAJQMRHKvHngwYFTxfiew62HKzWcElTrPan 4VGEdcIzfnQwjldFT4OCLMdXXRBw57jnLGGlLT3yCPu0ttoC1RgZM3IIrND1ifiBTb8N lJ5A== X-Gm-Message-State: AIkVDXKuWKoBrf4qP7tNVRQnQRKL+zeui0uoM++sZqagjDw0cu0t3Q6yecBsmTfYrOjV4iSFcd6DaqyTvBu5/m7o X-Received: by 10.107.21.196 with SMTP id 187mr7581309iov.105.1485534274769; Fri, 27 Jan 2017 08:24:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.150.207 with HTTP; Fri, 27 Jan 2017 08:24:34 -0800 (PST) X-Originating-IP: [2001:569:7128:2400:f1f4:1af4:75b6:921a] Received: by 10.79.150.207 with HTTP; Fri, 27 Jan 2017 08:24:34 -0800 (PST) In-Reply-To: References: <5889010c.06d0620a.31d79.5dd8@mx.google.com> <823CE48E-D778-4704-B13D-B6C302ED14D6@oracle.com> <093116990b28d9837f42a7477fc09d80@nleyten.com> From: John Bradley Date: Fri, 27 Jan 2017 13:24:34 -0300 Message-ID: To: Dario Teixeira Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1148d54ac546ae054715e6e3" Archived-At: Cc: IETF oauth WG Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2017 16:24:38 -0000 --001a1148d54ac546ae054715e6e3 Content-Type: multipart/alternative; boundary=001a1148d54ac000a6054715e6b9 --001a1148d54ac000a6054715e6b9 Content-Type: text/plain; charset=UTF-8 If you are protecting your API with OAuth in my recommendation there are two Authorization and token endpoints. One set run by Google (as an example) for authentication and issuing a access token for the Google User_info endpoint, and one set run by you to issue a access token for your resource server to your native app. I don't think Justin is recommending using the id_token directly as an access token for your resource server. I think he is recommending a internists step where it is exchanged for an access token. Our recommendations are based on the assumption that the end state is your app having an access token for your rest API. If that is not what you are trying to do then we may be talking at cross purposes. I don't think you understand app Auth by your description. The NA makes a request to the authorization endpoint of your OAuth server via a view controller or custom tab, that contains a PKCE code_challange. Your Authorization server then performs whatever authentication it wants to in that tab. It could do openid connect to Google, collect a password via Web form or authenticate via SAML to Azure or a enterprise IDP the choice is yours because we are logicly decoupling the two steps. After authentication your Authorization endpoint returns the user to the app via a claimed URI or custom scheme redirect with a code. Your native app exchanges that code and the PKCE verifier for a access and refresh token from your token endpoint so it can access your rest API on your Resource Server. Your native app only needs to know about your Authorization server and it's endpoints. The native app doesn't know how your Authorization server is authenticating the user(resource owner) as that happens transparently in the chrome custom tab/Safari view controller. In my recommendation your native app has one and only one client_id for your Authorization server and your Authorization server has the client ID for google, Facebook and others. In Justin's recommendation your native app would have a client ID for each IDP that it is using. How your back end would validate a id_token passed by your native app that it received from a IDP is currently not part of any specification. That is why you have not found it. It can be done but is in my opinion a shortcut that leads to implimentation issues down the road. The Google developer documentation has information on how to validate id_tokens that they issue when used in Justin's pattern, but it is a bit Google specific. John B. On Jan 27, 2017 3:25 AM, "Dario Teixeira" wrote: Hi, Justin and I are recommending different approaches. > Thanks for the clarification. To make sure there's no further confusion, allow me to define the various parties involved in the exchange: * Native App (NA): the native application running on the user's phone. This application is written by me. * Resource Server (RS): the server application that the NA wishes to communicate with. This application is also written by me, and offers a RESTful API to the NA. * OpenID Provider (OP): a 3rd party organization like Google that is able to authenticate users. * Authorization Endpoint (AE): a server run by the OP. * Token Endpoint (TE): another server run by the OP. * User Agent (UA): a browser running on the user's phone. Justin is recommending that you build a client/relying party for > each IdP into your native app and pass the results of authentication > ID_token, Facebook signed request etc to your back end server for > it to verify and issue some cookie or webkey (probably not OAuth > token) to your App for accessing your API. > To make sure I understood it correctly, here are the steps involved in Justin's scheme: 1. The NA asks the UA to show a webpage with links such as "Login with Google" or "Login with Facebook". Clicking on those links executes a request to the AE of the corresponding OP. The 'redirect_uri' parameter of the request points to the NA. 2. The user clicks on one of the links shown in the UA. 3. The AE sends the NA an Authorization Code. 4. The NA executes a request to the TE of the OP, sending it the Authorization Code obtained in step 3. The 'redirect_uri' parameter of the request points to the NA. 5. The TE sends the NA an ID token. 6. The NA sends the RS this ID token. 7. The RS validates the ID token by checking its signature against a hardcoded list of OP public keys. If valid, it sends back to the NA a cookie that can be used in future requests. It's pretty straightforward, but there's a bunch of corner cases surrounding expiration of tokens and making sure the list of OP public keys are synchronised. My recommendation is that your app do appAuth to your server to get > a access token for your API. Your server performs openid connect > to google, SAML to salesForce or Facebook Connect to Facebook and > manages verification keys. If the user is authenticated by the > IdP it then authorizes your app on the device to access your API. > Again, please allow me to describe the various steps involved in the AppAuth scheme, to make sure we're on the same page: 1. The NA executes a request to the RS, telling it the user wishes to login. It also sends the RS a secret S to be used later. 2. The RS replies with a webpage with links such as "Login with Google" or "Login with Facebook". The 'redirect_uri' present on those links points towards the RS. 3. The NA asks the UA to show the webpage it received in step 2. 4. The user clicks on one of the links shown in the UA. 5. The AE sends the RS an Authorization Code. 6. The RS executes a request to the TE of the OP, sending it the Authorization Code obtained in step 5. The 'redirect_uri' parameter of the request points to the RS. 7. The TE sends the RS an ID token. 8. The RS validates the ID token by checking its signature against a hardcoded list of OP public keys. It now knows that any future requests from the NA with secret S are authentic. There's an obvious problem with this scheme: there's no way for the NA to know when and if the authentication was successful. Did I miss something, or is this a know problem with the AppAuth scheme? Thanks again for your attention! Best regards, Dario Teixeira --001a1148d54ac000a6054715e6b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If you are protecting your API with OAuth in my reco= mmendation there are two Authorization and token endpoints.=C2=A0 One set r= un by Google (as an example) for authentication and issuing a access token = for the Google User_info endpoint, and one set run by you to issue a access= token for your resource server to your native app.
=
I don't think Justin is recommending using = the id_token directly as an access token for your resource server.=C2=A0 I = think he is recommending a internists step where it is exchanged for an acc= ess token.=C2=A0

Our rec= ommendations are based on the assumption that the end state is your app hav= ing an access token for your rest API. =C2=A0

If that is not what you are trying to do then we may = be talking at cross purposes. =C2=A0

I don't think you understand app Auth by your description.= =C2=A0

The NA makes a re= quest to the authorization endpoint of your OAuth server via a view control= ler or custom tab, that contains a PKCE code_challange.=C2=A0

Your Authorization server then perfor= ms whatever authentication it wants to in that tab.=C2=A0 It could do openi= d connect to Google, collect a password via Web form or authenticate via SA= ML to Azure or a enterprise IDP the choice is yours because we are logicly = decoupling the two steps. =C2=A0

After authentication your Authorization endpoint returns the user= to the app via a claimed URI or custom scheme redirect with a code. =C2=A0=
Your native app exchanges that code and the PKCE ve= rifier for a access and refresh token from your token endpoint so it can ac= cess your rest API on your Resource Server. =C2=A0
<= br>
Your native app only needs to know about your Au= thorization server and it's endpoints. =C2=A0 The native app doesn'= t know how your Authorization server is authenticating the user(resource ow= ner) as that happens transparently in the chrome custom tab/Safari view con= troller. =C2=A0

In my re= commendation your native app has one and only one client_id for your Author= ization server and your Authorization server has the client ID for google, = Facebook and others. =C2=A0

In Justin's recommendation your native app would have a client ID f= or each IDP that it is using. =C2=A0 How your back end would validate a id_= token passed by your native app that it received from a IDP is currently no= t part of any specification.=C2=A0 That is why you have not found it. =C2= =A0 It can be done but is in my opinion a shortcut that leads to implimenta= tion issues down the road. =C2=A0

The Google developer documentation has information on how to vali= date id_tokens that they issue when used in Justin's pattern, but it is= a bit Google specific. =C2=A0

John B.=C2=A0


On Jan 27, 2017 3:25 AM, "= Dario Teixeira" <dari= o.teixeira@nleyten.com> wrote:
Hi,


Justin and I are recommending different approaches.

Thanks for the clarification.=C2=A0 To make sure there's no further
confusion, allow me to define the various parties involved in
the exchange:

=C2=A0* Native App (NA): the native application running on the user's =C2=A0 =C2=A0phone. This application is written by me.

=C2=A0* Resource Server (RS): the server application that the NA wishes
=C2=A0 =C2=A0to communicate with. This application is also written by me, =C2=A0 =C2=A0and offers a RESTful API to the NA.

=C2=A0* OpenID Provider (OP): a 3rd party organization like Google that
=C2=A0 =C2=A0is able to authenticate users.

=C2=A0* Authorization Endpoint (AE): a server run by the OP.

=C2=A0* Token Endpoint (TE): another server run by the OP.

=C2=A0* User Agent (UA): a browser running on the user's phone.



Justin is recommending that you build a client/relying party for
each IdP into your native app and pass the results of authentication
ID_token, Facebook signed request etc to your back end server for
it to verify and issue some cookie or webkey (probably not OAuth
token) to your App for accessing your API.

To make sure I understood it correctly, here are the steps involved
in Justin's scheme:

=C2=A01. The NA asks the UA to show a webpage with links such as "Logi= n
=C2=A0 =C2=A0 with Google" or "Login with Facebook".=C2=A0 C= licking on those links
=C2=A0 =C2=A0 executes a request to the AE of the corresponding OP.
=C2=A0 =C2=A0 The 'redirect_uri' parameter of the request points to= the NA.

=C2=A02. The user clicks on one of the links shown in the UA.

=C2=A03. The AE sends the NA an Authorization Code.

=C2=A04. The NA executes a request to the TE of the OP, sending it the
=C2=A0 =C2=A0 Authorization Code obtained in step 3. The 'redirect_uri&= #39;
=C2=A0 =C2=A0 parameter of the request points to the NA.

=C2=A05. The TE sends the NA an ID token.

=C2=A06. The NA sends the RS this ID token.

=C2=A07. The RS validates the ID token by checking its signature against =C2=A0 =C2=A0 a hardcoded list of OP public keys. If valid, it sends back t= o
=C2=A0 =C2=A0 the NA a cookie that can be used in future requests.

It's pretty straightforward, but there's a bunch of corner cases surrounding expiration of tokens and making sure the list of OP
public keys are synchronised.



My recommendation is that your app do appAuth to your server to get
a access token for your API.=C2=A0 =C2=A0Your server performs openid connec= t
to google, SAML to salesForce or Facebook Connect to Facebook and
manages verification keys.=C2=A0 =C2=A0If the user is authenticated by the<= br> IdP it then authorizes your app on the device to access your API.

Again, please allow me to describe the various steps involved in
the AppAuth scheme, to make sure we're on the same page:

=C2=A01. The NA executes a request to the RS, telling it the user wishes =C2=A0 =C2=A0 to login.=C2=A0 It also sends the RS a secret S to be used la= ter.

=C2=A02. The RS replies with a webpage with links such as "Login with<= br> =C2=A0 =C2=A0 Google" or "Login with Facebook".=C2=A0 The &#= 39;redirect_uri' present
=C2=A0 =C2=A0 on those links points towards the RS.

=C2=A03. The NA asks the UA to show the webpage it received in step 2.

=C2=A04. The user clicks on one of the links shown in the UA.

=C2=A05. The AE sends the RS an Authorization Code.

=C2=A06. The RS executes a request to the TE of the OP, sending it the
=C2=A0 =C2=A0 Authorization Code obtained in step 5. The 'redirect_uri&= #39;
=C2=A0 =C2=A0 parameter of the request points to the RS.

=C2=A07. The TE sends the RS an ID token.

=C2=A08. The RS validates the ID token by checking its signature against =C2=A0 =C2=A0 a hardcoded list of OP public keys. It now knows that any
=C2=A0 =C2=A0 future requests from the NA with secret S are authentic.

There's an obvious problem with this scheme: there's no way for the=
NA to know when and if the authentication was successful.=C2=A0 Did I
miss something, or is this a know problem with the AppAuth scheme?

Thanks again for your attention!
Best regards,
Dario Teixeira


--001a1148d54ac000a6054715e6b9-- --001a1148d54ac546ae054715e6e3 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEINQNtncgms+go6dgmt82Hoyf+Pae w40Y5fzt5hNFg5siMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDEyNzE2MjQzNVowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQAQ3JU+XvCBAVtQZaZPAtg2PQJPGwDGSLUA91J5EelqG1IH uviqj+PIG2ANc+uqWd9oZ9yzf1dqj+BEd3/1JvtXGwUrYr2XTYe4KtTKAZNmxMuejLpXS5kVnHga xSmTI1EXlVzeAR0+feBJq0RcvX2ptEAkkq+4UzUmLUJLXn/6M0AACVCAWiEwJA/mMSNMnPekQ6YW 0zjosHPXF8DdlbbcQC4Ss9BQZLFlDbkVx35CxJaEVIpzkMlmpEl0ytq0hza3Taf7/n2aCytISqAQ aOl/v8YFIT9Q81qeIun7Dtz8OnQgGZ+MuGaKJ2TpFShvln+SbzikEoEqIbQW7lg9bJqb --001a1148d54ac546ae054715e6e3-- From nobody Fri Jan 27 09:16:32 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD13512944D for ; Fri, 27 Jan 2017 09:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.756 X-Spam-Level: X-Spam-Status: No, score=-3.756 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXLklfdlDnYA for ; Fri, 27 Jan 2017 09:16:28 -0800 (PST) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CF9E129411 for ; Fri, 27 Jan 2017 09:16:28 -0800 (PST) Received: from mfilter5-d.gandi.net (mfilter5-d.gandi.net [217.70.178.132]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 9F18E41C091; Fri, 27 Jan 2017 18:16:26 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter5-d.gandi.net Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter5-d.gandi.net (mfilter5-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id LFM89nLIo5fp; Fri, 27 Jan 2017 18:16:25 +0100 (CET) X-Originating-IP: 10.58.1.149 Received: from webmail.gandi.net (webmail9-d.mgt.gandi.net [10.58.1.149]) (Authenticated sender: dario.teixeira@nleyten.com) by relay5-d.mail.gandi.net (Postfix) with ESMTPA id 1A3EA41C080; Fri, 27 Jan 2017 18:16:24 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 27 Jan 2017 17:16:24 +0000 From: Dario Teixeira To: John Bradley In-Reply-To: References: <5889010c.06d0620a.31d79.5dd8@mx.google.com> <823CE48E-D778-4704-B13D-B6C302ED14D6@oracle.com> <093116990b28d9837f42a7477fc09d80@nleyten.com> Message-ID: X-Sender: dario.teixeira@nleyten.com User-Agent: Roundcube Webmail/1.1.2 Archived-At: Cc: IETF oauth WG Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2017 17:16:31 -0000 Hi, Thanks for your reply and your patience! > Our recommendations are based on the assumption that the end state > is your app having an access token for your rest API. > If that is not what you are trying to do then we may be talking at > cross purposes. Yes, that is exactly the end state I'm looking for, though there is a chance there is some misunderstanding about the whole picture. Allow me to summarise the current situation: Users interact with a Native App (NA) running on a mobile phone. This app talks with a Resource Server (RS) via a RESTful API. Because there is private user data on the RS, the very first interaction between the NA and the RS is a login where the NA asks the user for an email+password combination, which it then sends to the RS. If the email+password combination is valid, the RS replies with an access token that must be used by the NA in all its future requests. This works fine, but has the disadvantage of requiring users to manually enter their email and password. The user experience would be much improved if users had the option to login using their Google, Facebook, or Github account. Now, it is my understanding that OpenID Connect is the technology used nowadays to provide this sort of Single Sign-On. All I'm looking for is documentation on how OIDC is actually implemented in this scenario. Best regards, Dario Teixeira From nobody Fri Jan 27 17:23:15 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87322129B5E for ; Fri, 27 Jan 2017 17:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CX0JSG4BZ6M for ; Fri, 27 Jan 2017 17:23:13 -0800 (PST) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27C3129B5D for ; Fri, 27 Jan 2017 17:23:12 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id 194so85331859pgd.2 for ; Fri, 27 Jan 2017 17:23:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=message-id:mime-version:to:cc:from:subject:date:importance :in-reply-to:references; bh=0LKSNQtuWwtgQvrPbRS5zk7SiFKvEy4/cJb3mf4+CbA=; b=oV30UTrWq35lwrGJiXFfjMh54m8myG7cXRetltcCEEgxz3uE1g9xOCLTzycjoBHaB+ E9c04STS4BBoKblM/KsUzz6XfTd0m6QgYENUOW/8MjaSO5Ij2RgzWAJ4ncpBzPQjj4DM PChYlm6N+PVkI/Uoa5az9Vj1W1iVLCthEHI/VOP9nb06Yd72ZMNgQSHA9AlMgdZVY7by zZOXsXTUxvMYTy9fWRRa4YW5eVZ2yawTLsrjq1ajEqq8J+WJ4lwopasT4pEONCt+znvg 9iYZka/esklCr88zTfFf9nU4jc8Bgn8G7Bjslek5EKmQJ/O8lVvVpWHoIhv2xnIS3bcK xCRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:cc:from:subject:date :importance:in-reply-to:references; bh=0LKSNQtuWwtgQvrPbRS5zk7SiFKvEy4/cJb3mf4+CbA=; b=uGqZPN6K0wUyk7718rRVK9CK5OB7bCUWDqDxBzPjfwm9C6z6IJhpm+Qm+1RcKVXP6n n744gnySINnGznntINUtRIH4qUN+TWQtcOQatgVo1cg7FCGWi0CEEl7TluDtLFATIogK wKzFIBau1KHjY2O+uV3NYXBJnrxZDaq0yErF+bXXtleTBekjR0vlOn2c+kd2P8rSlR6D rw7j00kgNdhcwIfQQqySOtffRjbAVZhRW88YYbBrtcxjFRFh2Vg/7emFuGO329wqgNs5 QyehtyATMvirOlW5DoG6oozZYmwtrFmXbZYyMOmy39LJzaPvqSUqpcqObRDEssSxnWl5 IhJA== X-Gm-Message-State: AIkVDXItn32dL9nZgTUx24ZTYPX5X9TdmVASRuHvqlm+I/sb8MzYr1mo6VmTbiBUPYiGiQ6X X-Received: by 10.99.248.17 with SMTP id n17mr12431721pgh.17.1485566592347; Fri, 27 Jan 2017 17:23:12 -0800 (PST) Received: from ?IPv6:2001:569:7128:2400:dd34:490f:5338:686d? (node-1w7jr9qhemnddm7lx0d20ehkd.ipv6.telus.net. [2001:569:7128:2400:dd34:490f:5338:686d]) by smtp.gmail.com with ESMTPSA id k184sm14096480pgc.23.2017.01.27.17.23.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Jan 2017 17:23:10 -0800 (PST) Message-ID: <588bf27e.c16f630a.5cac3.9bb1@mx.google.com> MIME-Version: 1.0 To: Dario Teixeira From: Date: Fri, 27 Jan 2017 17:23:02 -0800 Importance: normal X-Priority: 3 In-Reply-To: References: <5889010c.06d0620a.31d79.5dd8@mx.google.com> <823CE48E-D778-4704-B13D-B6C302ED14D6@oracle.com> <093116990b28d9837f42a7477fc09d80@nleyten.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114c68700ad02d05471d6d8d" Archived-At: Cc: IETF oauth WG Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2017 01:23:14 -0000 --001a114c68700ad02d05471d6d8d Content-Type: multipart/alternative; boundary="_6BEA0696-3C6B-4677-925F-00426E0BB69C_" --_6BEA0696-3C6B-4677-925F-00426E0BB69C_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" It sounds like you are currently doing something like the OAuth resource ow= ner flow. Is there a Authorization server currently associated with your resource ser= ver? If so you can change the OAuth flow you are using to the code one as descri= bed in App Auth. You still need to authenticate the users at your server using the current = username and password or via OpenID Connect to Google. This is a two step process. If you try to combine them by trying to make y= our NA the connect client you may save a step in the short term but will re= gret it in the long term when you decide to add another identity provider l= ike Microsoft etc. OAuth from the NA to your server to authorize the native app, and your serv= er to Google via Connect to Authenticate the user. Regards John B. Sent from Mail for Windows 10 From: Dario Teixeira Sent: January 27, 2017 9:16 AM To: John Bradley Cc: Phil Hunt; IETF oauth WG Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app Hi, Thanks for your reply and your patience! > Our recommendations are based on the assumption that the end state > is your app having an access token for your rest API. > If that is not what you are trying to do then we may be talking at > cross purposes. Yes, that is exactly the end state I'm looking for, though there is a chance there is some misunderstanding about the whole picture. Allow me to summarise the current situation: Users interact with a Native App (NA) running on a mobile phone. This app talks with a Resource Server (RS) via a RESTful API. Because there is private user data on the RS, the very first interaction between the NA and the RS is a login where the NA asks the user for an email+password combination, which it then sends to the RS. If the email+password combination is valid, the RS replies with an access token that must be used by the NA in all its future requests. This works fine, but has the disadvantage of requiring users to manually enter their email and password. The user experience would be much improved if users had the option to login using their Google, Facebook, or Github account. Now, it is my understanding that OpenID Connect is the technology used nowadays to provide this sort of Single Sign-On. All I'm looking for is documentation on how OIDC is actually implemented in this scenario. Best regards, Dario Teixeira --_6BEA0696-3C6B-4677-925F-00426E0BB69C_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

It sounds like you are currently doi= ng something like the OAuth resource owner flow.

 

Is there a Authorization server cur= rently associated with your resource server?

&= nbsp;

If so you can change the OAuth flow you= are using to the code one as described in App Auth.

 

You still need to authenticate = the users at your server using the current =C2=A0username and password or v= ia OpenID Connect to Google.

 

<= p class=3DMsoNormal>This is a two step process.=C2=A0 If you try to combine= them by trying to make your NA the connect client you may save a step in t= he short term but will regret it in the long term when you decide to add an= other identity provider like Microsoft etc.

&n= bsp;

 

OAuth from the NA to your server to authorize the native app, and your se= rver to Google via Connect to Authenticate the user.

 

Regards

John B.

 

=  

 

 

Sent from Mail for Windows 10

<= p class=3DMsoNormal> 

From: Dario Teixeira
Sent: January 27, 2017 9:16 AM
To: John Bradley
Cc: P= hil Hunt; IETF oauth WG
Sub= ject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app

=

 

Hi,

 

Thanks for your r= eply and your patience!

 

> Our recommendations are based on the assumption that th= e end state

> is your app having an access token= for your rest API.

> If that is not what you ar= e trying to do then we may be talking at

> cross= purposes.

 

Yes, that is exactly the end state I'm looking for, though there

is a chance there is some misunderstanding about the whole = picture.

Allow me to summarise the current situatio= n:

 

Users = interact with a Native App (NA) running on a mobile phone.

This app talks with a Resource Server (RS) via a RESTful API.

Because there is private user data on the RS, the very f= irst

interaction between the NA and the RS is a log= in where the NA asks

the user for an email+password= combination, which it then sends

to the RS.=C2=A0 = If the email+password combination is valid, the RS

= replies with an access token that must be used by the NA in all

its future requests.

 =

This works fine, but has the disadvantage of requi= ring users to

manually enter their email and passwo= rd. The user experience would

be much improved if u= sers had the option to login using their Google,

Fa= cebook, or Github account.

 

Now, it is my understanding that OpenID Connect is the te= chnology

used nowadays to provide this sort of Sing= le Sign-On.=C2=A0 All I'm

looking for is documentat= ion on how OIDC is actually implemented

in this sce= nario.

 

Be= st regards,

Dario Teixeira

=  

 

= --_6BEA0696-3C6B-4677-925F-00426E0BB69C_-- --001a114c68700ad02d05471d6d8d Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIM7uGKWCCqHKvG90v9k2NCl2rBmg awfCCN/X33sjJk7kMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDEyODAxMjMxMlowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQBaF0yTeBWnTyOSjKSP/XWFbwrbeAISmg7B+iJrES+SiLb6 /1OAIMOHgUaoF4THP8Ibaurx+X3W711i/cnPyHZERiy+Ad95vQ2YTZtxys/IqQoPsDo+d2QCYHKW mURpSYp7h7Wyo1wUULXd3JGZdLn+EZ/sSpiMbOOgLquFBCFYMFVj2eYpuikmDKntyG9No3HBwhBK WdpiimlivcoI8mlQlDetyWSJbgVoNcna1rTT29HZP1TpC3ygS5iP/ese+tCcm0aAibN9DypcIdtx cTyYYESE5P5PDTkOHGUH6gdoPa5Bp9SxfXmnaCC5JeIwvwp4r6w5hLl9cri+ek2PnN7N --001a114c68700ad02d05471d6d8d-- From nobody Fri Jan 27 17:45:35 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C797129B61 for ; Fri, 27 Jan 2017 17:45:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.417 X-Spam-Level: X-Spam-Status: No, score=-7.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bL8ffneRGIIQ for ; Fri, 27 Jan 2017 17:45:31 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD58E12941D for ; Fri, 27 Jan 2017 17:45:31 -0800 (PST) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v0S1jUh8004750 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 28 Jan 2017 01:45:30 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v0S1jThB001953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 28 Jan 2017 01:45:30 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v0S1jTjH007112; Sat, 28 Jan 2017 01:45:29 GMT Received: from [25.248.207.127] (/24.114.41.213) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 27 Jan 2017 17:45:28 -0800 Content-Type: multipart/alternative; boundary=Apple-Mail-1559A4A9-C400-4F03-9598-C4D8859DE3C5 Mime-Version: 1.0 (1.0) From: "Phil Hunt (IDM)" X-Mailer: iPhone Mail (14C92) In-Reply-To: <588bf27e.c16f630a.5cac3.9bb1@mx.google.com> Date: Fri, 27 Jan 2017 17:45:24 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <5889010c.06d0620a.31d79.5dd8@mx.google.com> <823CE48E-D778-4704-B13D-B6C302ED14D6@oracle.com> <093116990b28d9837f42a7477fc09d80@nleyten.com> <588bf27e.c16f630a.5cac3.9bb1@mx.google.com> To: ve7jtb@ve7jtb.com X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: IETF oauth WG Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2017 01:45:33 -0000 --Apple-Mail-1559A4A9-C400-4F03-9598-C4D8859DE3C5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable What is concerning is that many are using resource owner flow so the client a= pp can capture the uid/password under the assumption that the client needs t= o control the branding experience much has been done in silo approaches of t= he past.=20 Adding to the confusion I note that many of the cloud provider site docs do n= ot clearly distinguish mobile apps from web apps. Mobile app developers arw r= eading docs and telling me that oracle, google, and azure require the mobile= app to register for an openid client id.=20 Near as I can tell it is confusion over the difference between authz and aut= hN.=20 Phil > On Jan 27, 2017, at 5:23 PM, ve7jtb@ve7jtb.com wrote: >=20 > It sounds like you are currently doing something like the OAuth resource o= wner flow. > =20 > Is there a Authorization server currently associated with your resource se= rver? > =20 > If so you can change the OAuth flow you are using to the code one as descr= ibed in App Auth. > =20 > You still need to authenticate the users at your server using the current = username and password or via OpenID Connect to Google. > =20 > This is a two step process. If you try to combine them by trying to make y= our NA the connect client you may save a step in the short term but will reg= ret it in the long term when you decide to add another identity provider lik= e Microsoft etc. > =20 > =20 > OAuth from the NA to your server to authorize the native app, and your ser= ver to Google via Connect to Authenticate the user. > =20 > Regards > John B. > =20 > =20 > =20 > =20 > Sent from Mail for Windows 10 > =20 > From: Dario Teixeira > Sent: January 27, 2017 9:16 AM > To: John Bradley > Cc: Phil Hunt; IETF oauth WG > Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app > =20 > Hi, > =20 > Thanks for your reply and your patience! > =20 > > Our recommendations are based on the assumption that the end state > > is your app having an access token for your rest API. > > If that is not what you are trying to do then we may be talking at > > cross purposes. > =20 > Yes, that is exactly the end state I'm looking for, though there > is a chance there is some misunderstanding about the whole picture. > Allow me to summarise the current situation: > =20 > Users interact with a Native App (NA) running on a mobile phone. > This app talks with a Resource Server (RS) via a RESTful API. > Because there is private user data on the RS, the very first > interaction between the NA and the RS is a login where the NA asks > the user for an email+password combination, which it then sends > to the RS. If the email+password combination is valid, the RS > replies with an access token that must be used by the NA in all > its future requests. > =20 > This works fine, but has the disadvantage of requiring users to > manually enter their email and password. The user experience would > be much improved if users had the option to login using their Google, > Facebook, or Github account. > =20 > Now, it is my understanding that OpenID Connect is the technology > used nowadays to provide this sort of Single Sign-On. All I'm > looking for is documentation on how OIDC is actually implemented > in this scenario. > =20 > Best regards, > Dario Teixeira > =20 > =20 --Apple-Mail-1559A4A9-C400-4F03-9598-C4D8859DE3C5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
What is concerning is that many are us= ing resource owner flow so the client app can capture the uid/password under= the assumption that the client needs to control the branding experience muc= h has been done in silo approaches of the past. 

Adding to the confusi= on I note that many of the cloud provider site docs do not clearly distingui= sh mobile apps from web apps. Mobile app developers arw reading docs and tel= ling me that oracle, google, and azure require the mobile app to register fo= r an openid client id. 

<= div id=3D"AppleMailSignature">Near as I can tell it is confusion over the di= fference between authz and authN. 
=
Phil

On Jan 27, 2017, at 5:23 PM, ve7jtb@ve7jtb.com wrote:

It sounds like= you are currently doing something like the OAuth resource owner flow.

 

Is there a A= uthorization server currently associated with your resource server?

 

If so you can c= hange the OAuth flow you are using to the code one as described in App Auth.=

 

You s= till need to authenticate the users at your server using the current  u= sername and password or via OpenID Connect to Google.

 

This is a two step process.&= nbsp; If you try to combine them by trying to make your NA the connect clien= t you may save a step in the short term but will regret it in the long term w= hen you decide to add another identity provider like Microsoft etc.

 

 

OAuth from the NA to your server to authorize t= he native app, and your server to Google via Connect to Authenticate the use= r.

 

Reg= ards

John B.

 =

 

 

 

Sent from Mail for Windows 10

 

From: Dario Teixeira
Sent: January 27, 2017 9:16 AM
To: = John Bradley
Cc: Phil Hunt; IETF oauth WG
Subject: Re: [OAUTH-WG] OAuth2/OIDC for clien= t-server mobile app

 

Hi,

 

Thanks for your reply and your patience!

 

> Our recommendations= are based on the assumption that the end state

&g= t; is your app having an access token for your rest API.

> If that is not what you are trying to do then we may be talking a= t

> cross purposes.

<= o:p> 

Yes, that is exactly the end stat= e I'm looking for, though there

is a chance there i= s some misunderstanding about the whole picture.

A= llow me to summarise the current situation:

&= nbsp;

Users interact with a Native App (NA) r= unning on a mobile phone.

This app talks with a Re= source Server (RS) via a RESTful API.

Because ther= e is private user data on the RS, the very first

i= nteraction between the NA and the RS is a login where the NA asks

the user for an email+password combination, which it then se= nds

to the RS.  If the email+password combina= tion is valid, the RS

replies with an access token= that must be used by the NA in all

its future req= uests.

 

This works fine, but has the disadvantage of requiring users to

manually enter their email and password. The user experience w= ould

be much improved if users had the option to l= ogin using their Google,

Facebook, or Github accou= nt.

 

No= w, it is my understanding that OpenID Connect is the technology

used nowadays to provide this sort of Single Sign-On.  All I= 'm

looking for is documentation on how OIDC is act= ually implemented

in this scenario.

 

Best regards,

Dario Teixeira

 

 

= --Apple-Mail-1559A4A9-C400-4F03-9598-C4D8859DE3C5-- From nobody Fri Jan 27 18:16:24 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F23129434 for ; Fri, 27 Jan 2017 18:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ve7jtb-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9TpDy8kqc-P for ; Fri, 27 Jan 2017 18:16:21 -0800 (PST) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98D5E129426 for ; Fri, 27 Jan 2017 18:16:21 -0800 (PST) Received: by mail-pg0-x235.google.com with SMTP id 3so26987904pgj.3 for ; Fri, 27 Jan 2017 18:16:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=message-id:mime-version:to:cc:from:subject:date:importance :in-reply-to:references; bh=PK9vqiyFi0AunBi9rQrzONlyomZFchyCxhRpGW7Cd6g=; b=I/Zwj5QYr2uxEIGaKNGGtv2LCeH1SbzGeuPFN2LuVk6JcLRTegDe/w2d2GEKg8rch5 5BIgF+gFDkN02QJzerpp6zpsSuPA0EIgNGGQGna7FKMEQBUrH18xkDy7dmP51OLXmytD McFdP+3t6M0cEb+AS5ZJkrAebybJpoKsTEYbbWouTgnmk3vc9YaveRtHeRwxoLsQtEMt OgdtbolZJt/DHZTo+WMBlHJrBkDrcd+HZQDm4ZDqwnhPyPLjE/+Bo2mH8tw+NimIgPEH 0Fp3m1UX+Ja4B13Vq+oxO6f4gFQCWEzDMbm/sia9NLtVtVT3jcrBkfM67hvz3qhqkAIq LVbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:mime-version:to:cc:from:subject:date :importance:in-reply-to:references; bh=PK9vqiyFi0AunBi9rQrzONlyomZFchyCxhRpGW7Cd6g=; b=sNvVGYRVoWoYPTyySXqxpzhNXqL4Fpj78Ptvd/3JquFxWWnoPHUUN/U/hQJhd9SOou EvWS8FkSxch6pnv70Tvs9EDH0b6b/S0M2h8MsL/Ru4gRCl7M5E8uRACJrU2AkVJeU92x MuclnZtTS8ahLOTUoZ4a0+OsS3DdG4DqzCaRh1xl/xPhr+z6Mu2QJ4Yt2t5sCNGxDpVz YLdYWgGO2NsOy5fquLi4x4zJf+cQIqpC/1BIvlAM7NmLlLfXPm7Bb4Cq289sjtMHt50p kaW9G8sHbSAhefAivuaIHrxufEfY/jyTT+3UF9YHcV6stRX0+voMxLZ62460IATIGXp2 qKPA== X-Gm-Message-State: AIkVDXI1rvpgtPazk36EwiOmtwvs0JHKT7wSEYaPIXfl+CZ+cX+I1ueRxj1q095hbrqMwd+w X-Received: by 10.84.198.164 with SMTP id p33mr16802952pld.156.1485569781059; Fri, 27 Jan 2017 18:16:21 -0800 (PST) Received: from ?IPv6:2001:569:7128:2400:dd34:490f:5338:686d? (node-1w7jr9qhemnddm7lx0d20ehkd.ipv6.telus.net. [2001:569:7128:2400:dd34:490f:5338:686d]) by smtp.gmail.com with ESMTPSA id 64sm14200837pfz.48.2017.01.27.18.16.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Jan 2017 18:16:19 -0800 (PST) Message-ID: <588bfef3.4319620a.b813.ac72@mx.google.com> MIME-Version: 1.0 To: "Phil Hunt (IDM)" From: Date: Fri, 27 Jan 2017 18:16:19 -0800 Importance: normal X-Priority: 3 In-Reply-To: References: <5889010c.06d0620a.31d79.5dd8@mx.google.com> <823CE48E-D778-4704-B13D-B6C302ED14D6@oracle.com> <093116990b28d9837f42a7477fc09d80@nleyten.com> <588bf27e.c16f630a.5cac3.9bb1@mx.google.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="94eb2c18a3381a634805471e2b1e" Archived-At: Cc: IETF oauth WG Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jan 2017 02:16:23 -0000 --94eb2c18a3381a634805471e2b1e Content-Type: multipart/alternative; boundary="_29CA52CF-5155-4590-B470-452FA250CA98_" --_29CA52CF-5155-4590-B470-452FA250CA98_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" A mobile app that just used Google API only would/should register for a Goo= gle client Id and use connect with Google. A mobile app that uses only its own API should have a client ID from its ow= n authorization server, and leave it to the authorization server to deal wi= th the authentication. Where it gets more grey is when the native app wants to access both Google = API directly and its own REST API. In the simple AppAuth model you could have the App owners Resource server p= roxy the information from Google etc as it gets a google access token if th= e user authenticates to google via Connect. I think that is the safest way to do it. Justin=E2=80=99s recommendation is a bit more optimised for this scenario w= here the Native application wants to access two resource servers. In that= case with one client_id from Google it can get both a id_token and access = token for Google. It uses the acess token to get the plus friends list or= something like that and sends the id_token to its backend to exchange for = a cookie or some other form of access token assuming the Native apps author= ization/resource server doing the exchange properly validates the signature= and audience in the id_token. =20 The original question was not about multiple RS and I don=E2=80=99t think t= hat is really the most common case, so I didn=E2=80=99t go there in my answ= er as it adds more complexity to something that is complex enough. John B. Sent from Mail for Windows 10 From: Phil Hunt (IDM) Sent: January 27, 2017 5:45 PM To: ve7jtb@ve7jtb.com Cc: Dario Teixeira; IETF oauth WG Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app What is concerning is that many are using resource owner flow so the client= app can capture the uid/password under the assumption that the client need= s to control the branding experience much has been done in silo approaches = of the past.=C2=A0 Adding to the confusion I note that many of the cloud provider site docs do= not clearly distinguish mobile apps from web apps. Mobile app developers a= rw reading docs and telling me that oracle, google, and azure require the m= obile app to register for an openid client id.=C2=A0 Near as I can tell it is confusion over the difference between authz and au= thN.=C2=A0 Phil On Jan 27, 2017, at 5:23 PM, ve7jtb@ve7jtb.com wrote: It sounds like you are currently doing something like the OAuth resource ow= ner flow. =C2=A0 Is there a Authorization server currently associated with your resource ser= ver? =C2=A0 If so you can change the OAuth flow you are using to the code one as descri= bed in App Auth. =C2=A0 You still need to authenticate the users at your server using the current = =C2=A0username and password or via OpenID Connect to Google. =C2=A0 This is a two step process.=C2=A0 If you try to combine them by trying to m= ake your NA the connect client you may save a step in the short term but wi= ll regret it in the long term when you decide to add another identity provi= der like Microsoft etc. =C2=A0 =C2=A0 OAuth from the NA to your server to authorize the native app, and your serv= er to Google via Connect to Authenticate the user. =C2=A0 Regards John B. =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sent from Mail for Windows 10 =C2=A0 From: Dario Teixeira Sent: January 27, 2017 9:16 AM To: John Bradley Cc: Phil Hunt; IETF oauth WG Subject: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app =C2=A0 Hi, =C2=A0 Thanks for your reply and your patience! =C2=A0 > Our recommendations are based on the assumption that the end state > is your app having an access token for your rest API. > If that is not what you are trying to do then we may be talking at > cross purposes. =C2=A0 Yes, that is exactly the end state I'm looking for, though there is a chance there is some misunderstanding about the whole picture. Allow me to summarise the current situation: =C2=A0 Users interact with a Native App (NA) running on a mobile phone. This app talks with a Resource Server (RS) via a RESTful API. Because there is private user data on the RS, the very first interaction between the NA and the RS is a login where the NA asks the user for an email+password combination, which it then sends to the RS.=C2=A0 If the email+password combination is valid, the RS replies with an access token that must be used by the NA in all its future requests. =C2=A0 This works fine, but has the disadvantage of requiring users to manually enter their email and password. The user experience would be much improved if users had the option to login using their Google, Facebook, or Github account. =C2=A0 Now, it is my understanding that OpenID Connect is the technology used nowadays to provide this sort of Single Sign-On.=C2=A0 All I'm looking for is documentation on how OIDC is actually implemented in this scenario. =C2=A0 Best regards, Dario Teixeira =C2=A0 =C2=A0 --_29CA52CF-5155-4590-B470-452FA250CA98_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

A mobile app that just used Google A= PI only would/should register for a Google client Id and use connect with G= oogle.

 

A = mobile app that uses only its own API should have a client ID from its own = authorization server, and leave it to the authorization server to deal with= the authentication.

 

Where it gets more grey is when the native app wants to access= both Google API directly and its own REST API.

 

In the simple AppAuth model you coul= d have the App owners Resource server proxy the information from Google etc= as it gets a google access token if the user authenticates to google via C= onnect.

 

I= think that is the safest way to do it.

 =

Justin=E2=80=99s recommendation is a bit mor= e optimised for this scenario where the Native application wants to access = two resource servers.=C2=A0=C2=A0 In that case with one client_id from Goog= le it can get both a id_token and access token for Google.=C2=A0=C2=A0 It u= ses the acess token to get the plus friends list or something like that and= sends the id_token to its backend to exchange for a cookie or some other f= orm of access token assuming the Native apps authorization/resource server = doing the exchange properly validates the signature and audience in the id_= token.=C2=A0

 

The original question was not about multiple RS and I don=E2=80=99t th= ink that is really the most common case, so I didn=E2=80=99t go there in my= answer as it adds more complexity to something that is complex enough.

=

 

John B.

<= p class=3DMsoNormal> 

 

 

Sent= from Mail= for Windows 10

 

From: Phil Hunt (IDM)=
Sent: January 27, 2017 5:45 PM
To: ve7jtb@ve7jtb.com
Cc: Dario Teixeira; IETF oauth WG
Subject: Re: [OAUTH-WG] OAuth2/OIDC for cli= ent-server mobile app

 

What is concerning is that many are using resource owner= flow so the client app can capture the uid/password under the assumption t= hat the client needs to control the branding experience much has been done = in silo approaches of the past. 

 

Adding to the confusion I note that many of th= e cloud provider site docs do not clearly distinguish mobile apps from web = apps. Mobile app developers arw reading docs and telling me that oracle, go= ogle, and azure require the mobile app to register for an openid client id.=  

 

Near as I can tell it is confusion over the difference between authz an= d authN. 


Phil


On Jan 27, 2017, at 5:23 PM, ve7jtb@ve7jtb.com wrote:

= It sounds like you are currently doing something like the OAuth resource ow= ner flow.

 

Is there a Authorization server currently associated with your= resource server?

 

<= p class=3DMsoNormal>If so you can change the OAuth flow you are using to th= e code one as described in App Auth.

&nb= sp;

You still need to authenticate the u= sers at your server using the current  username and password or via Op= enID Connect to Google.

 

This is a two step process.  If you try to c= ombine them by trying to make your NA the connect client you may save a ste= p in the short term but will regret it in the long term when you decide to = add another identity provider like Microsoft etc.

 

 

OAuth from the NA to your server to authorize the native= app, and your server to Google via Connect to Authenticate the user.<= /o:p>

 

Reg= ards

John B.

 

 

 

 

Sent from Mail for Windows 10

 

From: Dario Teixeira
Sent: January 27, 2017 9:16 AM
To: John Bradley
Cc: Ph= il Hunt; IETF oauth WG
Subj= ect: Re: [OAUTH-WG] OAuth2/OIDC for client-server mobile app=

 

Hi= ,

 

Thanks for your reply and your patience!

 

> Our recommendations are= based on the assumption that the end state

> is your app having an access token for your rest API.

> If that is not what you are trying to do then w= e may be talking at

> cross purposes.=

 

Yes, that is exactly the end state I'm looking for, though there

is a chance there is some misunderstanding abou= t the whole picture.

Allow me to summari= se the current situation:

 

Users interact with a Native App (NA) running o= n a mobile phone.

This app talks with a = Resource Server (RS) via a RESTful API.

= Because there is private user data on the RS, the very first

=

interaction between the NA and the RS is a login where= the NA asks

the user for an email+passw= ord combination, which it then sends

to = the RS.  If the email+password combination is valid, the RS=

replies with an access token that must be used by = the NA in all

its future requests.<= /o:p>

 

Thi= s works fine, but has the disadvantage of requiring users to

=

manually enter their email and password. The user expe= rience would

be much improved if users h= ad the option to login using their Google,

Facebook, or Github account.

 

Now, it is my understanding that OpenID C= onnect is the technology

used nowadays t= o provide this sort of Single Sign-On.  All I'm

looking for is documentation on how OIDC is actually implement= ed

in this scenario.

 

Best regards,

Dario Teixeira

 

 

 

=
= --_29CA52CF-5155-4590-B470-452FA250CA98_-- --94eb2c18a3381a634805471e2b1e Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIRGwYJKoZIhvcNAQcCoIIRDDCCEQgCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg gg4rMIIErzCCA5egAwIBAgIRAOAjyxUSg1OJrWFuelRnayEwDQYJKoZIhvcNAQELBQAwbzELMAkG A1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0xNDEy MjIwMDAwMDBaFw0yMDA1MzAxMDQ4MzhaMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRl ZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1 cmUgRW1haWwgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCJsQ3aelMZTnBSHbxW pgYmt7hJ4JbnUavx8FoTSRWjtIwbYLx6UUKneYykIt8XYU6R1XYjChTTSgJ/th0JgG6lBD3ZursW /qGHqS5DUkMWfK8yUMimT1rpCNjPkyWce4joMGTmpPhWgP0qJBQzF5msROVpi6NGBkvCM9TpQJ8G sLGsk0C5tQiTOpwqU6MQ2z0gYTxVA47ZTnYlAiEp+qN8cXZP7uFfgen7VIDbw3s1UreE3iI9LDAt MX9ZvVI3sDNpLUPr+tal8Zd3Z1GM2e4n67ylBzh2jKSpOP/fjPUDrEm+yvdzmToPMquclToTPQ5G Old0YVC+xkA/y+Tin6IhAgMBAAGjggEXMIIBEzAfBgNVHSMEGDAWgBStvZh6NLQm9/rEJlTvA73g JMtUGjAdBgNVHQ4EFgQUkmFrguGioKpP7GfxwqP3tIAAwewwDgYDVR0PAQH/BAQDAgGGMBIGA1Ud EwEB/wQIMAYBAf8CAQAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBEGA1UdIAQKMAgw BgYEVR0gADBEBgNVHR8EPTA7MDmgN6A1hjNodHRwOi8vY3JsLnVzZXJ0cnVzdC5jb20vQWRkVHJ1 c3RFeHRlcm5hbENBUm9vdC5jcmwwNQYIKwYBBQUHAQEEKTAnMCUGCCsGAQUFBzABhhlodHRwOi8v b2NzcC51c2VydHJ1c3QuY29tMA0GCSqGSIb3DQEBCwUAA4IBAQAbKm6sVcE6q4jF2O3NVfOqa2Er wAkQI5kPxWZqb7H1tLV3Xg8CYQDffQX+ErOkgIAA/PsdW2pyAgpBvAW6wVjVJsLq1U2E+/6CmM9Y G+MiY5xS+LsFNqt9WKXeqztj5drVc+/s4Pt74qP/8EIjnMq2jU0+5EsYA7KoLdTYu0JLkGmFENum NzToe+ABEKWcyjrHn0+ING6KZdAairup3MrKNtH0/MJkKTWv1rGncRHSA0Oxjz6a7J4yU/R2ksqG NAe5LMrmHErYmQ3BhuKQkvtaQmojIRDpZcf11bt+6oyFIAJi6tE6ByxZxZkz8jiJ5bbpFnofeRT2 ShAaJvp8ivubMIIENjCCAx6gAwIBAgIBATANBgkqhkiG9w0BAQUFADBvMQswCQYDVQQGEwJTRTEU MBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4dGVybmFsIFRUUCBOZXR3 b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290MB4XDTAwMDUzMDEwNDgzOFoX DTIwMDUzMDEwNDgzOFowbzELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYD VQQLEx1BZGRUcnVzdCBFeHRlcm5hbCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0 ZXJuYWwgQ0EgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALf3GjPm8gAELTng TlvtH7xsD821+iO2zt6bETOXpClMfZOfvUq8k+0DGuOPz+VtUFrWlymUWoCwSXrbLpX9uMq/Nzgt Hj6RQa1wVsfwTz/oMp50ysiQVOnGXw94nZpAPA6sYapeFI+eh6FqUNzXmk6vBbOmcZSccbNQYArH E504B4YCqOmoaSYYkKtMsE8jqzpPhNjfzp/haW+710LXa0Tkx63ubUFfclpxCDezeWWkWaCUN/cA Lw3CknLa0Dhy2xSoRcRdKn23tNbE7qzNE0S3ySvdQwAl+mG5aWpYIxG3pzOPVnVZ9c0p10a3Citl ttNCbxWyuHv77+ldU9U0WicCAwEAAaOB3DCB2TAdBgNVHQ4EFgQUrb2YejS0Jvf6xCZU7wO94CTL VBowCwYDVR0PBAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wgZkGA1UdIwSBkTCBjoAUrb2YejS0Jvf6 xCZU7wO94CTLVBqhc6RxMG8xCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQG A1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5ldHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4 dGVybmFsIENBIFJvb3SCAQEwDQYJKoZIhvcNAQEFBQADggEBALCb4IUlwtYj4g+WBpKdQZic2YR5 gdkeWxQHIzZlj7DYd7usQWxHYINRsPkyPef89iYTx4AWpb9a/IfPeHmJIZriTAcKhjW88t5RxNKW t9x+Tu5w/Rw56wwCURQtjr0W4MHfRnXnJK3s9EK0hZNwEGe6nQY1ShjTK3rMUUKhemPR5ruhxSvC Nr4TDea9Y355e6cJDUCrat2PisP29owaQgVR1EX1n6diIWgVIEM8med8vSTYqZEXc4g/VhsxOBi0 cQ+azcgOno4uG+GMmIPLHzHxREzGBHNJdmAPx/i9F4BrLunMTA5amnkPIAou1Z5jJh5VkpTYghda e9C8x49OhgQwggU6MIIEIqADAgECAhEA2TLMtWuXNcB2cbqZ/VgVujANBgkqhkiG9w0BAQsFADCB mzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2Fs Zm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2 IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MDEwOTAwMDAw MFoXDTE4MDEwOTIzNTk1OVowIjEgMB4GCSqGSIb3DQEJARYRdmU3anRiQHZlN2p0Yi5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDW2rqobOFQ/XmzH3DG2UK1Dt6jtc+OFZ71KQoB o8IZa/V94Ey12BPjBcoj+cjHNVsLd2QiUpMcf5sZFMX1cmvpR7TiUISgVcHe8zgiUUvN5Jn5tPDM Kb4E34TtDEG2X5FyY35AwCl8NV/loj2D5KLid9BLdVTJjfqokjLQ/4qCQjWBjfTpIdAdr3lXfg5f a5UPyIkphEIplM8/yGfX0W/PBl804XAL0gesLrfEMdgG58UCN1wJMgH4uRKmKU/U2Ap4W9hTpioN M722U8x7N6P1v6MqTAWCUaskdOp+ktNxFGxOlCE7BEo/EIaWbEt5RHwDePctScDLsi56+VI3TysR AgMBAAGjggHvMIIB6zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQU Yg3SsFWhMro4Abonbn1IX4JKj5QwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9 MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0 L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9TSEEy NTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEFBQcBAQSB gzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RPU0hBMjU2Q2xp ZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMBwGA1UdEQQVMBOBEXZlN2p0YkB2ZTdqdGIuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQCC26y+6/+SJoRQWepca+rB9eSSwaCAb8nNqA+00ZiOHb+6UbbV1xa7Z8wDIuEL 5UKbNtQ2NDArvzF9YI0xNafoV1AEmP/3+ljxQHSEI0U1p2h401sOx+nSjcwtTzACso1lw+I0oJYM JFITOIfZy8HgFpCipBrQAp9jMJ+KSKDX3xu/hzPosfdnXp7sV1KAjkFrAtR3AnQYfJ5W8QrsmC4N BbiAKoYWUSdklqn3v1neTG/+oOhcw7hcGZo+YmPyF9Cdy0gBtwSHPt8hluhg2TlzmqYfi0dVL/mU jCBNUY/BFH+MBqKF7sOIRMv8ALWceVaM/NEcBciKs4eR99A4cw9ZMYICtDCCArACAQEwgbEwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRANkyzLVrlzXAdnG6mf1Y FbowDQYJYIZIAWUDBAIBBQCggdQwLwYJKoZIhvcNAQkEMSIEIOnWsXjFXxg/4hVg4MJcY6hXBPGH 7GamDZVX7iBgTONSMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3 MDEyODAyMTYyMVowaQYJKoZIhvcNAQkPMVwwWjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsG CWCGSAFlAwQBAjAKBggqhkiG9w0DBzALBgkqhkiG9w0BAQowCwYJKoZIhvcNAQEHMAsGCWCGSAFl AwQCATANBgkqhkiG9w0BAQEFAASCAQBjl+StGr7sh+O1MHs+oCRgZpnHCKssY3/B4b/H6NippKm0 QuKPDE5mMHTB3OW58GtrZhr/AhUXIOEePLgN0VLZnoFufiGtGVYeLfwiH2y7k/3NoqxWXmrkKrUP wpEpyWxVwcHcFeoqMN9MyCLOygjk/PoWO6p4DnLHC2zqdTVATc6ZzlR3iakd7KckG2eehFX3F69a R/Rhudao9hk9H99MCgj2WFW3vxKM16Va/5yYkKZ/FvuG0kFdw3ZinKdCj7xbi58QJnZrRcx8so4l VpsUIgFGILS+RtABOhrEeT4IqRE7ZUzaiJz7qksA8SfRE1H9IubThop7zYRGskHIs+Z1 --94eb2c18a3381a634805471e2b1e-- From nobody Mon Jan 30 00:44:10 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D35F1293EC; Mon, 30 Jan 2017 00:44:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148576584657.29836.5879798626307814195.idtracker@ietfa.amsl.com> Date: Mon, 30 Jan 2017 00:44:06 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-10.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 08:44:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR) Authors : Nat Sakimura John Bradley Filename : draft-ietf-oauth-jwsreq-10.txt Pages : 24 Date : 2017-01-30 Abstract: The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that Authorization Request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that (a) the communication through the user agents are not integrity protected and thus the parameters can be tainted, and (b) the source of the communication is not authenticated. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be JWS signed and/or JWE encrypted so that the integrity, source authentication and confidentiality property of the Authorization Request is attained. The request can be sent by value or by reference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 30 02:07:31 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAEA1293F4; Mon, 30 Jan 2017 02:07:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148577085038.29921.15823305818513918248.idtracker@ietfa.amsl.com> Date: Mon, 30 Jan 2017 02:07:30 -0800 Archived-At: Cc: oauth@ietf.org Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-jwsreq-11.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 10:07:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol of the IETF. Title : The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR) Authors : Nat Sakimura John Bradley Filename : draft-ietf-oauth-jwsreq-11.txt Pages : 24 Date : 2017-01-30 Abstract: The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that Authorization Request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that (a) the communication through the user agents are not integrity protected and thus the parameters can be tainted, and (b) the source of the communication is not authenticated. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be JWS signed and/or JWE encrypted so that the integrity, source authentication and confidentiality property of the Authorization Request is attained. The request can be sent by value or by reference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 30 02:14:05 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1877F12943B for ; Mon, 30 Jan 2017 02:14:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHW5sJt0ixGz for ; Mon, 30 Jan 2017 02:14:01 -0800 (PST) Received: from nrifs03.index.or.jp (nrigw01.index.or.jp [133.250.250.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459301293F4 for ; Mon, 30 Jan 2017 02:14:01 -0800 (PST) Received: from nrimmfm052.index.or.jp (unknown [172.19.246.144]) by nrifs03.index.or.jp (Postfix) with ESMTP id 9E08C17EA47; Mon, 30 Jan 2017 19:14:00 +0900 (JST) Received: from index.or.jp (unknown [172.19.246.151]) by nrimmfm052.index.or.jp (Postfix) with ESMTP id 1EF334E0046; Mon, 30 Jan 2017 19:14:00 +0900 (JST) Received: from nriea02.index.or.jp (localhost.localdomain [127.0.0.1]) by pps.mf051 (8.15.0.59/8.15.0.59) with SMTP id v0UAE0wm019195; Mon, 30 Jan 2017 19:14:00 +0900 Received: from nrims00a.nri.co.jp ([192.50.135.11]) by nriea02.index.or.jp with ESMTP id v0UADxFm019193; Mon, 30 Jan 2017 19:13:59 +0900 Received: from nrims00a.nri.co.jp (localhost.localdomain [127.0.0.1]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id v0UADxXw022681; Mon, 30 Jan 2017 19:13:59 +0900 Received: (from mailnull@localhost) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.0/Submit) id v0UADxS1022680; Mon, 30 Jan 2017 19:13:59 +0900 X-Authentication-Warning: nrims00a.nri.co.jp: mailnull set sender to n-sakimura@nri.co.jp using -f Received: from nrizmf14.index.or.jp ([172.100.25.23]) by nrims00a.nri.co.jp (Switch-3.3.4/Switch-3.3.4) with ESMTP id v0UADx5Z022677; Mon, 30 Jan 2017 19:13:59 +0900 From: "Nat Sakimura" To: , "'John Bradley'" References: <148577085049.29921.13673476753538866150.idtracker@ietfa.amsl.com> In-Reply-To: <148577085049.29921.13673476753538866150.idtracker@ietfa.amsl.com> Date: Mon, 30 Jan 2017 19:13:58 +0900 Message-ID: <003801d27ae1$926ddef0$b7499cd0$@nri.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQIb0y+5WOj4f+xR2RrOKxoyGx+1t6C+Gx9Q Content-Language: ja X-MailAdviser: 20141126 Archived-At: Cc: 'Steve KENT' Subject: Re: [OAUTH-WG] New Version Notification for draft-ietf-oauth-jwsreq-11.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 10:14:04 -0000 Hi OAuthers:=20 I have finally pushed -10 and -11 which hopefully resolved all the = comments provided by Jan 17.=20 Changes are as follows.=20 #20: KM1 -- some wording that is awkward in the TLS section. Accepted the suggested edit.=20 #21: KM2 - the additional attacks against OAuth 2.0 should also have a = pointer Accepted.=20 Added the references to the security considerations in RFC7515, 7516, = 7518. #22: KM3 -- Nit: in first line of 10.4: Accepted.=20 s/researchs/research/ #23: KM4 -- Mention RFC6973 in Section 11 in addition to ISO 29100 Accepted in principle.=20 Added a paragraph on RFC6973.=20 #24: SECDIR review: Section 4 -- Confusing requirements for sign+encrypt Accepted in principle. Modified as follows:=20 - JWS signature should also be applied.=20 - In this case, it MUST be signed then encrypted, - with the result being a Nested JWT, as defined in - JWT.=20 + JWS signature SHOULD also be applied so that the source = authentication=20 + can be done.=20 + When both signature and encryption are being applied,=20 + the JWT MUST be signed then encrypted as advised in=20 + the section 11.2 of .=20 + The result is a Nested JWT, as defined in + . =20 - The Authorization Request Object may be sent by value as=20 + The Authorization Request Object MAY be sent by value as #36: DP - More precise qualification on Encryption needed. Accepted in principle.=20 - JWE encrypted; or + JWE encrypted (when symmetric keys are being used); or #25: SECDIR review: Section 6 -- authentication and integrity need not = be provided if the requestor encrypts the token? Superseded by #36 #26: SECDIR Review: Section 10 -- why no reference for JWS algorithms? Accepted by modifying as:=20 - JWS signed with then considered appropriate algorithm=20 - or encrypted using . + signed using JWS=20 + or encrypted using JWE=20 + with then considered appropriate algorithm. #27: SECDIR Review: Section 10.2 - how to do the agreement between = client and server "a priori"? Accepted. Resolved by adding the following:=20 + Note that the such agreement needs to be done in a=20 + secure fashion. For example, the developers from the=20 + server side and the client side can have a face to face=20 + meeting to come to such an agreement. #28: SECDIR Review: Section 10.3 - Indication on "large entropy" and = "short lifetime" should be indicated Accepted. Resolved by adding:=20 + The adequate shortness of the validity and=20 + the entropy of the Request Object URI depends=20 + on the risk calculation based on the value =20 + of the resource being protected. A general guidance=20 + for the validity time would be less than a minute=20 + and the Request Object URI is to include a cryptographic =20 + random value of 128bit or more at the time of the=20 + writing of this specification. #29: SECDIR Review: Section 10.3 - Typo Accepted.=20 - applies. In addition, the Authorization Server=20 + apply. In addition, the Authorization Server #30: SECDIR Review: Section 10.4 - typos and missing articles Fixed several. According to grammarly.com, there is no errors left, but = there may be more...=20 #31: SECDIR Review: Section 10.4 - Clearer statement on the lack of = endpoint identifiers needed Accepted. Resolved by modifying as: =20 - An extension specification should be created.=20 + An extension specification should be created=20 + as a preventive measure to address=20 + potential vulnerabilities that has not yet been identified. #32: SECDIR Review: Section 11 - ISO29100 needs to be moved to normative = reference Accepted.=20 #33: SECDIR Review: Section 11 - Better English & Entropy language = needed Accepted. Modified as:=20 - of one-time use and MUST have large enough entropy=20 + used only once, have short validity period, and MUST have large enough = entropy + The adequate shortness of the validity and=20 + the entropy of the Request Object URI depends=20 + on the risk calculation based on the value =20 + of the resource being protected. A general guidance=20 + for the validity time would be less than a minute=20 + and the Request Object URI is to include a cryptographic =20 + random value of 128bit or more at the time of the=20 + writing of this specification. #34: Section 4: Typo Fixed the errors spotted by grammarly.com #35: More Acknowledgement Added Denis Pinkas, Kathleen Moriarty (as AD), and Steve Kent (as = SECDIR). Please let me know if there are other changes needed.=20 Best,=20 Nat Sakimura -- PLEASE READ :This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, January 30, 2017 7:08 PM > To: Nat Sakimura ; John Bradley = > Subject: New Version Notification for draft-ietf-oauth-jwsreq-11.txt >=20 >=20 > A new version of I-D, draft-ietf-oauth-jwsreq-11.txt has been = successfully > submitted by Nat Sakimura and posted to the IETF repository. >=20 > Name: draft-ietf-oauth-jwsreq > Revision: 11 > Title: The OAuth 2.0 Authorization Framework: JWT Secured > Authorization Request (JAR) > Document date: 2017-01-30 > Group: oauth > Pages: 24 > URL: > https://www.ietf.org/internet-drafts/draft-ietf-oauth-jwsreq-11.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ > Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-11 > Diff: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-oauth-jwsreq-11 >=20 > Abstract: > The authorization request in OAuth 2.0 described in RFC 6749 = utilizes > query parameter serialization, which means that Authorization = Request > parameters are encoded in the URI of the request and sent through > user agents such as web browsers. While it is easy to implement, = it > means that (a) the communication through the user agents are not > integrity protected and thus the parameters can be tainted, and (b) > the source of the communication is not authenticated. Because of > these weaknesses, several attacks to the protocol have now been put > forward. >=20 > This document introduces the ability to send request parameters in = a > JSON Web Token (JWT) instead, which allows the request to be JWS > signed and/or JWE encrypted so that the integrity, source > authentication and confidentiality property of the Authorization > Request is attained. The request can be sent by value or by > reference. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat From nobody Mon Jan 30 11:07:08 2017 Return-Path: X-Original-To: oauth@ietfa.amsl.com Delivered-To: oauth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32E52129A98 for ; Mon, 30 Jan 2017 11:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQNLDlYlyIdV for ; Mon, 30 Jan 2017 11:07:04 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D69841293F9 for ; Mon, 30 Jan 2017 11:07:03 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id v23so213054162qtb.0 for ; Mon, 30 Jan 2017 11:07:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lw2Uf96Qmp3eQi3pLexNMmrcCEyNf6zCEGana8tfETs=; b=RvRPgGBJ78MKEtBC8p5khm3y0+g/6eNZVVf2nnJ5ZUwAIC2QVOk1ITn3V+njasrKs/ LVcq3PuIcmLIRZ+MNgUMg7c8PaxUJTr5mSy3O0Mkz4p0erOGDvIrzxWBRCPgH4btZPIb UslG8M6jbtky4tVoAWO0Emy6hpIO04z/zUBn2ff9VvpnTnU/WQNxTxo9VnxV5clxCmLl kCmqYABNSZAoc3PLv1g4d+g6LoohdXL8GILHt6NBpBDqWsE2kbwUWe86eX/tPUVFVJen 7yWfno4luOd1maPYReB6CvWmm0xJQrIiSJaGs/wjlfnilbqQdaGqG8Wvg7a7LApG6Crl clLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lw2Uf96Qmp3eQi3pLexNMmrcCEyNf6zCEGana8tfETs=; b=MnBqASJZOOw9XZFRgMTlpG4KoGmSP/hWZ8GPGBWU2D23PAoxWsv8GzIRQ16D/0PjZW +0Xs7uh4b1YDpQod0McjraXX7OvY6LTUqbQQuZgtNPOJq7x28OKx4Xjaebf9/7NvR7DN MxiMSIV2CxdYhn6jIQh82xzIzb+jWvvQPma5xKAKlKElEedfNDTigAHBbRWM7RW95GA6 BcUZeNgIvdkSQHYZxjDhx1v4iXMCHgJ7ODPoMq6SoiLtFo4l/WDbTpn92lmhTmQ+Rhyv HAcdgxxuP8IUsTtueRsotoPFQB29p/0pqbeEF8lduBRCoxgZT4cX6ywdn804GHxLHLlk Q0uA== X-Gm-Message-State: AIkVDXJNWVCRNxkNBtKI0Ft7o+GUDHaGkzBzvdn7bf8f1lwfWJlswV0entUlD0Ux1zTPKD50k+2qJuSpzCrmVw== X-Received: by 10.200.37.141 with SMTP id e13mr20774119qte.226.1485803222237; Mon, 30 Jan 2017 11:07:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.170.30 with HTTP; Mon, 30 Jan 2017 11:07:01 -0800 (PST) In-Reply-To: <003801d27ae1$926ddef0$b7499cd0$@nri.co.jp> References: <148577085049.29921.13673476753538866150.idtracker@ietfa.amsl.com> <003801d27ae1$926ddef0$b7499cd0$@nri.co.jp> From: Kathleen Moriarty Date: Mon, 30 Jan 2017 14:07:01 -0500 Message-ID: To: Nat Sakimura Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "oauth@ietf.org" , Steve KENT Subject: Re: [OAUTH-WG] New Version Notification for draft-ietf-oauth-jwsreq-11.txt X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 19:07:06 -0000 Hi Nat, Thanks for making the updates from my review and the SecDir review. I already pulled this from this week's telechat. I can put it on the next telechat, I just need to run IETF last call first. I will request to start last call. Discussions on changes fromt he SecDir review can continue during last call as that's the normal timing for SecDir reviews anyway. Thanks, Kathleen On Mon, Jan 30, 2017 at 5:13 AM, Nat Sakimura wrote: > Hi OAuthers: > > I have finally pushed -10 and -11 which hopefully resolved all the comments provided by Jan 17. > > Changes are as follows. > > #20: KM1 -- some wording that is awkward in the TLS section. > > Accepted the suggested edit. > > #21: KM2 - the additional attacks against OAuth 2.0 should also have a pointer > > Accepted. > Added the references to the security considerations in RFC7515, 7516, 7518. > > #22: KM3 -- Nit: in first line of 10.4: > > Accepted. > s/researchs/research/ > > #23: KM4 -- Mention RFC6973 in Section 11 in addition to ISO 29100 > > Accepted in principle. > Added a paragraph on RFC6973. > > #24: SECDIR review: Section 4 -- Confusing requirements for sign+encrypt > > Accepted in principle. Modified as follows: > > - JWS signature should also be applied. > - In this case, it MUST be signed then encrypted, > - with the result being a Nested JWT, as defined in > - JWT. > + JWS signature SHOULD also be applied so that the source authentication > + can be done. > + When both signature and encryption are being applied, > + the JWT MUST be signed then encrypted as advised in > + the section 11.2 of . > + The result is a Nested JWT, as defined in > + . > > - The Authorization Request Object may be sent by value as > + The Authorization Request Object MAY be sent by value as > > #36: DP - More precise qualification on Encryption needed. > > Accepted in principle. > > - JWE encrypted; or > + JWE encrypted (when symmetric keys are being used); or > > #25: SECDIR review: Section 6 -- authentication and integrity need not be provided if the requestor encrypts the token? > > Superseded by #36 > > #26: SECDIR Review: Section 10 -- why no reference for JWS algorithms? > > Accepted by modifying as: > > - JWS signed with then considered appropriate algorithm > - or encrypted using . > + signed using JWS > + or encrypted using JWE > + with then considered appropriate algorithm. > > #27: SECDIR Review: Section 10.2 - how to do the agreement between client and server "a priori"? > > Accepted. Resolved by adding the following: > > + Note that the such agreement needs to be done in a > + secure fashion. For example, the developers from the > + server side and the client side can have a face to face > + meeting to come to such an agreement. > > #28: SECDIR Review: Section 10.3 - Indication on "large entropy" and "short lifetime" should be indicated > > Accepted. Resolved by adding: > > + The adequate shortness of the validity and > + the entropy of the Request Object URI depends > + on the risk calculation based on the value > + of the resource being protected. A general guidance > + for the validity time would be less than a minute > + and the Request Object URI is to include a cryptographic > + random value of 128bit or more at the time of the > + writing of this specification. > > #29: SECDIR Review: Section 10.3 - Typo > > Accepted. > > - applies. In addition, the Authorization Server > + apply. In addition, the Authorization Server > > #30: SECDIR Review: Section 10.4 - typos and missing articles > > Fixed several. According to grammarly.com, there is no errors left, but there may be more... > > #31: SECDIR Review: Section 10.4 - Clearer statement on the lack of endpoint identifiers needed > > Accepted. Resolved by modifying as: > > - An extension specification should be created. > + An extension specification should be created > + as a preventive measure to address > + potential vulnerabilities that has not yet been identified. > > #32: SECDIR Review: Section 11 - ISO29100 needs to be moved to normative reference > > Accepted. > > #33: SECDIR Review: Section 11 - Better English & Entropy language needed > > Accepted. Modified as: > > - of one-time use and MUST have large enough entropy > + used only once, have short validity period, and MUST have large enough entropy > > + The adequate shortness of the validity and > + the entropy of the Request Object URI depends > + on the risk calculation based on the value > + of the resource being protected. A general guidance > + for the validity time would be less than a minute > + and the Request Object URI is to include a cryptographic > + random value of 128bit or more at the time of the > + writing of this specification. > > #34: Section 4: Typo > > Fixed the errors spotted by grammarly.com > > #35: More Acknowledgement > > Added Denis Pinkas, Kathleen Moriarty (as AD), and Steve Kent (as SECDIR). > > > Please let me know if there are other changes needed. > > Best, > > Nat Sakimura > -- > PLEASE READ :This e-mail is confidential and intended for the > named recipient only. If you are not an intended recipient, > please notify the sender and delete this e-mail. > > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Monday, January 30, 2017 7:08 PM >> To: Nat Sakimura ; John Bradley >> Subject: New Version Notification for draft-ietf-oauth-jwsreq-11.txt >> >> >> A new version of I-D, draft-ietf-oauth-jwsreq-11.txt has been successfully >> submitted by Nat Sakimura and posted to the IETF repository. >> >> Name: draft-ietf-oauth-jwsreq >> Revision: 11 >> Title: The OAuth 2.0 Authorization Framework: JWT Secured >> Authorization Request (JAR) >> Document date: 2017-01-30 >> Group: oauth >> Pages: 24 >> URL: >> https://www.ietf.org/internet-drafts/draft-ietf-oauth-jwsreq-11.txt >> Status: https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ >> Htmlized: https://tools.ietf.org/html/draft-ietf-oauth-jwsreq-11 >> Diff: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-jwsreq-11 >> >> Abstract: >> The authorization request in OAuth 2.0 described in RFC 6749 utilizes >> query parameter serialization, which means that Authorization Request >> parameters are encoded in the URI of the request and sent through >> user agents such as web browsers. While it is easy to implement, it >> means that (a) the communication through the user agents are not >> integrity protected and thus the parameters can be tainted, and (b) >> the source of the communication is not authenticated. Because of >> these weaknesses, several attacks to the protocol have now been put >> forward. >> >> This document introduces the ability to send request parameters in a >> JSON Web Token (JWT) instead, which allows the request to be JWS >> signed and/or JWE encrypted so that the integrity, source >> authentication and confidentiality property of the Authorization >> Request is attained. The request can be sent by value or by >> reference. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat > -- Best regards, Kathleen From nobody Mon Jan 30 15:11:22 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 992CA12967A; Mon, 30 Jan 2017 15:11:21 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <148581788158.29828.4591033587037530374.idtracker@ietfa.amsl.com> Date: Mon, 30 Jan 2017 15:11:21 -0800 Archived-At: Cc: draft-ietf-oauth-jwsreq@ietf.org, oauth@ietf.org, oauth-chairs@ietf.org Subject: [OAUTH-WG] Last Call: (The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)) to Proposed Standard X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 23:11:22 -0000 The IESG has received a request from the Web Authorization Protocol WG (oauth) to consider the following document: - 'The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2017-02-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that Authorization Request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that (a) the communication through the user agents are not integrity protected and thus the parameters can be tainted, and (b) the source of the communication is not authenticated. Because of these weaknesses, several attacks to the protocol have now been put forward. This document introduces the ability to send request parameters in a JSON Web Token (JWT) instead, which allows the request to be JWS signed and/or JWE encrypted so that the integrity, source authentication and confidentiality property of the Authorization Request is attained. The request can be sent by value or by reference. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-oauth-jwsreq/ballot/ No IPR declarations have been submitted directly on this I-D. The document contains these normative downward references. See RFC 3967 for additional information: rfc6234: US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) (Informational - IETF stream) rfc6819: OAuth 2.0 Threat Model and Security Considerations (Informational - IETF stream) rfc6973: Privacy Considerations for Internet Protocols (Informational - IAB stream) Note that some of these references may already be listed in the acceptable Downref Registry. From nobody Tue Jan 31 07:32:03 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7171294EC; Tue, 31 Jan 2017 07:32:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148587672129.2586.10755945838145379266.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2017 07:32:01 -0800 Archived-At: Cc: oauth-chairs@ietf.org, draft-ietf-oauth-amr-values@ietf.org, oauth@ietf.org Subject: [OAUTH-WG] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_dra?= =?utf-8?q?ft-ietf-oauth-amr-values-05=3A_=28with_COMMENT=29?= X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 15:32:01 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-oauth-amr-values-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Could the values in this registry also be used for draft-ietf-kitten-krb-auth-indicator-06? From nobody Tue Jan 31 08:26:32 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8829C1299BD; Tue, 31 Jan 2017 08:26:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148587998454.2480.4991718024003414319.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2017 08:26:24 -0800 Archived-At: Cc: oauth-chairs@ietf.org, draft-ietf-oauth-amr-values@ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-amr-values-05: (with DISCUSS) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 16:26:24 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-oauth-amr-values-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This specification seems to me to break it's own rules. You state that registrations should include a reference to a specification to improve interop. And yet, for the strings added here (e.g. otp) you don't do that (referring to section 2 will not improve interop) and there are different ways in which many of the methods in section 2 can be done. So I think you need to add a bunch more references. From nobody Tue Jan 31 14:58:32 2017 Return-Path: X-Original-To: oauth@ietf.org Delivered-To: oauth@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 18D5D129642; Tue, 31 Jan 2017 14:58:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.41.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148590350709.6011.3498845571170184756.idtracker@ietfa.amsl.com> Date: Tue, 31 Jan 2017 14:58:27 -0800 Archived-At: Cc: oauth-chairs@ietf.org, draft-ietf-oauth-amr-values@ietf.org, oauth@ietf.org Subject: [OAUTH-WG] Ben Campbell's No Objection on draft-ietf-oauth-amr-values-05: (with COMMENT) X-BeenThere: oauth@ietf.org X-Mailman-Version: 2.1.17 List-Id: OAUTH WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 22:58:27 -0000 Ben Campbell has entered the following ballot position for draft-ietf-oauth-amr-values-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-oauth-amr-values/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In 6.1, the text seems to say experts must enforce one of two different standards for handling characters outside the non-printable ascii set. Is that the intent? That seems to invite inconsistent decisions from different experts. Would it make more sense to say that experts must make sure one of the two standards is met, rather than choosing which standard they want to follow?