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.carl...@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-boun...@ietf.org] De la part de John Bradley > Envoyé : mardi 25 juillet 2017 18:03 > À : Bill Burke <bbu...@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 <bbu...@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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
