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<mailto: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<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto: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
