Re: [OAUTH-WG] OAuth Digest, Vol 89, Issue 44
jo turner <joannemaree78@outlook.com> Tue, 22 March 2016 10:47 UTC
Return-Path: <joannemaree78@outlook.com>
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 4EB0512D768 for <oauth@ietfa.amsl.com>; Tue, 22 Mar 2016 03:47:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.35
X-Spam-Level:
X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 XnKO7PDOdTd9 for <oauth@ietfa.amsl.com>; Tue, 22 Mar 2016 03:47:48 -0700 (PDT)
Received: from COL004-OMC1S13.hotmail.com (col004-omc1s13.hotmail.com [65.55.34.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0137412D673 for <oauth@ietf.org>; Tue, 22 Mar 2016 03:47:47 -0700 (PDT)
Received: from COL402-EAS413 ([65.55.34.8]) by COL004-OMC1S13.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 22 Mar 2016 03:47:47 -0700
X-TMN: [2uN/qQy87V4URxFWfNtDeUQ4YLNWDCR1]
X-Originating-Email: [joannemaree78@outlook.com]
Message-ID: <COL402-EAS413B7B151CE3997AC79C549AC800@phx.gbl>
Content-Type: multipart/alternative; boundary="_44fd20dc-c53f-465f-ae62-150d0be0c4af_"
MIME-Version: 1.0
To: oauth@ietf.org
From: jo turner <joannemaree78@outlook.com>
Date: Tue, 22 Mar 2016 10:48:20 +0000
X-OriginalArrivalTime: 22 Mar 2016 10:47:47.0760 (UTC) FILETIME=[45F38300:01D18428]
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/8_I2z7AwVWan74bjRj6_ZME1ER4>
Subject: Re: [OAUTH-WG] OAuth Digest, Vol 89, Issue 44
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Mar 2016 10:47:51 -0000
Hi Sergey, Not sure why I'm on the mailing list have I accidentally accessed this ,my phone was hacked a year or so ago but since then I think my data has synced with it and I have weird search history etc that isn't mine,if I found a flaw in security am I eligible for a reward Sent from my Windows Phone ________________________________ From: oauth-request@ietf.org<mailto:oauth-request@ietf.org> Sent: 15/03/2016 13:11 To: oauth@ietf.org<mailto:oauth@ietf.org> Subject: OAuth Digest, Vol 89, Issue 44 Send OAuth mailing list submissions to oauth@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/oauth or, via email, send a message with subject or body 'help' to oauth-request@ietf.org You can reach the person managing the list at oauth-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OAuth digest..." Today's Topics: 1. Re: Client Credentials flow and Client Registrations (Justin Richer) 2. When does RS not require token introspection ? (Sergey Beryozkin) 3. Re: Client Credentials flow and Client Registrations (John Bradley) 4. Re: When does RS not require token introspection ? (Justin Richer) ---------------------------------------------------------------------- Message: 1 Date: Tue, 15 Mar 2016 08:53:12 -0400 From: Justin Richer <jricher@mit.edu> To: oauth@ietf.org Subject: Re: [OAUTH-WG] Client Credentials flow and Client Registrations Message-ID: <56E805B8.5000305@mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Is Alice the client here (the piece of software), or is Alice the resource owner? If Alice is the resource owner, then you should absolutely not be using the client credentials flow like this. The client credentials flow is designed for cases where the client is acting on its own behalf, not on behalf of any particular user. It's an optimization of the canonical authorization code flow, where there is no interaction with the resource owner because there is no resource owner as a separate entity. It's most useful for backend systems that would have traditionally used a developer key to get access to bulk data. If you're using it for single-user access, you're doing it wrong. Also, you should keep in mind that things that seem "simple" on the surface are often simplified at the cost of making specific security concessions and assumptions. The authorization code flow is "complex" for very good reasons, all of them security focused. You should never pick a different OAuth flow just because it looks simpler, you should only pick them if you're within the use case that it was designed for, and therefor the assumptions of its security patterns match. We've seen a *ton* of problems with people picking the implicit flow in the real world and using it with clients other than in-browser applications that it was designed for. If you're not in that specific space, you're taking on huge risks. -- Justin On 3/15/2016 8:37 AM, Sergey Beryozkin wrote: > Hi All > > I've alway been thinking of Client Credentials as being the simplest > flow but now that I'm looking at implementing it myself to be used in > the real productions, I'm realizing that there's something I do not > understand about it: > > Do the clients using Client Credentials flow need to be > OAuth2-registered, even when such clients are already known to the > authentication system ? > > For example, there might be some LDAP/etc entry for Alice (name, > password). Now a client is using a client credentials flow to get an > access token: > > POST /token HTTP/1.1 > Host: server.example.com > Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW > Content-Type: application/x-www-form-urlencoded > > grant_type=client_credentials > > I hope that in this case no explicit registration (the one typically > required in redirection based flows) is needed, the client (Alice) has > been 'implicitly' registered (as far as the notion of OAuth2 client is > concerned) in LDAP/etc. > > If the explicit registration with OAuth2 AS was still required in the > case above then it would lead to a fairly massive duplication of > effort (Alice is registered in Ldap, then also with OAuth2 AS), etc > > Can someone clarify it please ? > > Thanks, Sergey > > > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth ------------------------------ Message: 2 Date: Tue, 15 Mar 2016 13:01:16 +0000 From: Sergey Beryozkin <sberyozkin@gmail.com> To: oauth@ietf.org Subject: [OAUTH-WG] When does RS not require token introspection ? Message-ID: <56E8079C.3010402@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Hi After following the recent thread on multiple authorization servers, but also reading some other related threads, I have a question related to when the token introspection can be avoided. My understanding has been that given that access tokens are opaque the RS does not know anything about its content, hence that was the purpose of the token introspection spec: provide an interoperable way for RS to submit a token to AS and get the token data for RS to make a final decision about this token. I think if the access tokens are really opaque, i.e, they are sequences RS can not look into, then having the introspection option is the only way to check what the token is really about. But the recent replies with respect to using JWS or JWE tokens have confused me. 1. AccessToken as JWS JWT Token: RS can easily look into it, but Justin mentioned that in one case they first validate this JWS token and then forward it for some further introspection. Why start introspecting if the token has been validated and its content is visible ? Perhaps because some token data which are sensitive are only visible in the introspection response ? If yes then why use a self-contained token if some more external data are associated with it. 2. AccessToken as JWE JWT Token: this option was mentioned a couple of times recently, Jonh B. suggested in the other thread the introspection may not be needed (sorry if I misread it). The question here, how can RS deal with a JWE token, it would need to share the decrypting key with AS. So, is introspection needed only for the completely opaque tokens or it is also needed for JWS and JWE tokens. I'd say it might be reasonable to skip it in case of JWS, depending on the specific requirements (as the expiry, issuer, will be typically set in JWS JWT), while with JWE I can not see how RS can avoid introspecting unless it shares the secret/private key with AS. Thanks, Sergey ------------------------------ Message: 3 Date: Tue, 15 Mar 2016 10:05:07 -0300 From: John Bradley <ve7jtb@ve7jtb.com> To: Sergey Beryozkin <sberyozkin@gmail.com> Cc: oauth@ietf.org Subject: Re: [OAUTH-WG] Client Credentials flow and Client Registrations Message-ID: <C1D353A4-A7C3-4B5F-9DFD-601C2C1FB3F7@ve7jtb.com> Content-Type: text/plain; charset="us-ascii" I think you may be confusing Client credentials flow with resource owner credentials flow. If there is a resource owner in the flow use code. The resource owner credentials flow is a bad idea and only put in for backwards compatibility. John B. > On Mar 15, 2016, at 9:37 AM, Sergey Beryozkin <sberyozkin@gmail.com> wrote: > > Hi All > > I've alway been thinking of Client Credentials as being the simplest flow but now that I'm looking at implementing it myself to be used in the real productions, I'm realizing that there's something I do not understand about it: > > Do the clients using Client Credentials flow need to be OAuth2-registered, even when such clients are already known to the authentication system ? > > For example, there might be some LDAP/etc entry for Alice (name, password). Now a client is using a client credentials flow to get an access token: > > POST /token HTTP/1.1 > Host: server.example.com > Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW > Content-Type: application/x-www-form-urlencoded > > grant_type=client_credentials > > I hope that in this case no explicit registration (the one typically required in redirection based flows) is needed, the client (Alice) has been 'implicitly' registered (as far as the notion of OAuth2 client is concerned) in LDAP/etc. > > If the explicit registration with OAuth2 AS was still required in the case above then it would lead to a fairly massive duplication of effort (Alice is registered in Ldap, then also with OAuth2 AS), etc > > Can someone clarify it please ? > > Thanks, Sergey > > > > > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4326 bytes Desc: not available URL: <https://mailarchive.ietf.org/arch/browse/oauth/attachments/20160315/7d08b4d0/attachment.p7s> ------------------------------ Message: 4 Date: Tue, 15 Mar 2016 09:11:30 -0400 From: Justin Richer <jricher@mit.edu> To: Sergey Beryozkin <sberyozkin@gmail.com>, oauth@ietf.org Subject: Re: [OAUTH-WG] When does RS not require token introspection ? Message-ID: <56E80A02.20101@mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed The access tokens are opaque to the client, not the RS. -- Justin On 3/15/2016 9:01 AM, Sergey Beryozkin wrote: > Hi > > After following the recent thread on multiple authorization servers, > but also reading some other related threads, I have a question related > to when the token introspection can be avoided. > > My understanding has been that given that access tokens are opaque the > RS does not know anything about its content, hence that was the > purpose of the token introspection spec: provide an interoperable way > for RS to submit a token to AS and get the token data for RS to make a > final decision about this token. > > I think if the access tokens are really opaque, i.e, they are > sequences RS can not look into, then having the introspection option > is the only way to check what the token is really about. > > But the recent replies with respect to using JWS or JWE tokens have > confused me. > > 1. AccessToken as JWS JWT Token: > > RS can easily look into it, but Justin mentioned that in one case they > first validate this JWS token and then forward it for some further > introspection. Why start introspecting if the token has been validated > and its content is visible ? > Perhaps because some token data which are sensitive are only visible > in the introspection response ? If yes then why use a self-contained > token if some more external data are associated with it. > > 2. AccessToken as JWE JWT Token: this option was mentioned a couple of > times recently, Jonh B. suggested in the other thread the > introspection may not be needed (sorry if I misread it). > The question here, how can RS deal with a JWE token, it would need to > share the decrypting key with AS. > > So, is introspection needed only for the completely opaque tokens or > it is also needed for JWS and JWE tokens. I'd say it might be > reasonable to skip it in case of JWS, depending on the specific > requirements (as the expiry, issuer, will be typically set in JWS > JWT), while with JWE I can not see how RS can avoid introspecting > unless it shares the secret/private key with AS. > > > Thanks, Sergey > > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth ------------------------------ Subject: Digest Footer _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ------------------------------ End of OAuth Digest, Vol 89, Issue 44 *************************************