Re: [OAUTH-WG] Short lived access token and no refresh token

"Phil Hunt (IDM)" <phil.hunt@oracle.com> Tue, 25 July 2017 18:21 UTC

Return-Path: <phil.hunt@oracle.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 023F412ECF0 for <oauth@ietfa.amsl.com>; Tue, 25 Jul 2017 11:21:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.218
X-Spam-Level:
X-Spam-Status: No, score=-4.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, 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=-0.001, 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 JtAlE2MGKk0u for <oauth@ietfa.amsl.com>; Tue, 25 Jul 2017 11:21:06 -0700 (PDT)
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 3BDCD131E9B for <oauth@ietf.org>; Tue, 25 Jul 2017 11:21:04 -0700 (PDT)
Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v6PIL25f006041 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 Jul 2017 18:21:02 GMT
Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v6PIL1Fm024483 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 Jul 2017 18:21:02 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v6PIKxJx023179; Tue, 25 Jul 2017 18:21:00 GMT
Received: from [10.0.1.19] (/24.86.190.97) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 25 Jul 2017 11:20:59 -0700
Content-Type: multipart/alternative; boundary=Apple-Mail-5ACC0C5E-0279-4925-A125-492D8B9C388E
Mime-Version: 1.0 (1.0)
From: "Phil Hunt (IDM)" <phil.hunt@oracle.com>
X-Mailer: iPhone Mail (14G60)
In-Reply-To: <HE1PR0301MB213884E812F89B529EC5FE5887B80@HE1PR0301MB2138.eurprd03.prod.outlook.com>
Date: Tue, 25 Jul 2017 11:20:56 -0700
Cc: John Bradley <ve7jtb@ve7jtb.com>, Bill Burke <bburke@redhat.com>, "oauth@ietf.org" <oauth@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <AE16C069-A913-47BB-92DC-51B49E066451@oracle.com>
References: <CAP+kwAV9pHE_3aL_-97T4-7WsP-8U=nt9J2UwdhCBhQe0x_95A@mail.gmail.com> <f8d2add3-ce9a-ef3a-80cc-889f426a1b92@redhat.com> <47685EB5-84E0-43FB-87CF-447C3F958588@ve7jtb.com> <HE1PR0301MB213884E812F89B529EC5FE5887B80@HE1PR0301MB2138.eurprd03.prod.outlook.com>
To: CARLIER Bertrand <Bertrand.CARLIER@wavestone.com>
X-Source-IP: aserv0021.oracle.com [141.146.126.233]
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/RvoG5YIGGDt1zWQRHNhGFL5XD-s>
Subject: Re: [OAUTH-WG] Short lived access token and no refresh token
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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, 25 Jul 2017 18:21:09 -0000

In OAuth, the audience for the token is the resource server and not the client. OAuth delegates a client to act for a user. OIDC issues an ID token whose audience is the client. 

Assuming OAuth...

The life of the token is dependent on the risk at the resource. 

Refresh token lets the client do a proof of possession authentication test to ensure confidence when user not necessarily present. 

Re-authorize forces the user context in browser to be reverified. 

Note that many implementations at this stage just re-evaluate cookie state to determine if SSO and grant state is still valid and either authorization is regranted or user is re-authenticated etc. 

As John mentions, OIDC layers on additional features since it role is user authen for the client rather than delegation to the client. 

Phil

> On Jul 25, 2017, at 9:47 AM, CARLIER Bertrand <Bertrand.CARLIER@wavestone.com> wrote:
> 
> Hello,
>  
> Depending on what is meant by “scenario to be supported from the authorization server (platform) itself and not in the client app or resource server”, it may be it difficult (or impossible) to achieve.
> In the end, the resource server only applies token lifetime policy *if it decides to do so*, whatever the AS kindly asked him to do
>  
> --
> Bertrand CARLIER
> 
>  
> De : OAuth [mailto:oauth-bounces@ietf.org] De la part de John Bradley
> Envoyé : mardi 25 juillet 2017 18:03
> À : Bill Burke <bburke@redhat.com>
> Cc : oauth@ietf.org
> Objet : Re: [OAUTH-WG] Short lived access token and no refresh token
>  
> Max-age has to do with user re-auth in connect.
>  
> Some AS only give refresh tokens if a scope of offline_acess or some such special scope is requested.
> There is no standard scope for that.
>  
> I don’t know of any way for the client to control the lifetime of the access token other than by revoking it with the AS.
> https://tools.ietf.org/html/rfc7009
>  
> Depending on the AS you should be able to control the AT lifetime on a per client basis.
>  
> John B.
>  
> On Jul 25, 2017, at 11:37 AM, Bill Burke <bburke@redhat.com> wrote:
>  
> For browser apps, implicit flow provides an access token but no refresh token.  For non-browser apps only client credentials grant doesn't supply a refresh token.  As for token access times, I believe only extensions to OAuth define those types of capabilities.  i.e. OpenID Connect defines a "max-age" claim that you can pass when requesting a token.
>  
> On 7/25/17 10:48 AM, Saurav Sarkar wrote:
> Hi All,
>  
> We have a scenario where one of our stakeholder wants to mandatorily initiate the authentication at certain point of time.
>  
> As per https://www.oauth.com/oauth2-servers/access-tokens/access-token-lifetime/
> there can be an option where access token is set for certain time and refresh token is not set. So we want to explore this option for this scenario.
>  
> I have couple of questions regarding this
>  
> (a) Is this  option part of OAuth 2 specification ? If yes can you please point me to the exact IETF link ?
>  
> (b) Is there any other way our scenario can be achieved ? We want this scenario to be supported from the authorization server (platform) itself and not in the client app or resource server.
>  
> Thanks and Best Regards,
> Saurav
> 
> 
> 
> _______________________________________________
> 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
>  
> The information transmitted in the present email including the attachment is intended only for the person to whom or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete all copies of the material. 
> 
> Ce message et toutes les pièces qui y sont éventuellement jointes sont confidentiels et transmis à l'intention exclusive de son destinataire. Toute modification, édition, utilisation ou diffusion par toute personne ou entité autre que le destinataire est interdite. Si vous avez reçu ce message par erreur, nous vous remercions de nous en informer immédiatement et de le supprimer ainsi que les pièces qui y sont éventuellement jointes.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth