Subject: [OAUTH-WG] prompt parameter for Authorization Request

From: Lewis Adam-CAL022 <[email-masked]>
Date: Thu, 13 Sep 2012 20:36:13 +0000

Hi,

OpenID Connect defines a parameter for the Authorization Request that I really like a lot, the prompt parameter which can force the AS to re-challenge the user for primary authentication.

This would be a nice feature to have for OAuth too.

I have some high assurance use cases where my resource servers will require a certain "freshness" of the access token.  The RS will only accept a AT within a certain lifetime (say for example 1hr).  If a client presents an AT to the RS that was minted over 1hr ago, the RS (via its RESTful API) will return an error message indicating such to the client.  Further, the RS requires explicit re-authentication of the end user (by the AS) to obtain a new token.

However, if the UA still has an active session with the AS, the AS will not know to re-prompt for primary auth.

Hence having a PROMPT parameter in OAuth would be ideal.

Obviously, the train has left the station in terms of the core draft.  But I'm wondering if anybody else has come across such use cases before?

Tx
adam

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 14 Sep 2012 07:45:12 +0200

Hi Adam,

I think this parameter makes sense for OAuth. It could be defined as extension to the core spec.

Regards,
Torsten.

Lewis Adam-CAL022 <[email-masked]> schrieb:

>Hi,
>
>OpenID Connect defines a parameter for the Authorization Request that I
>really like a lot, the prompt parameter which can force the AS to
>re-challenge the user for primary authentication.
>
>I have some high assurance use cases where my resource servers will
>require a certain "freshness" of the access token.  The RS will only
>accept a AT within a certain lifetime (say for example 1hr).  If a
>client presents an AT to the RS that was minted over 1hr ago, the RS
>(via its RESTful API) will return an error message indicating such to
>the client.  Further, the RS requires explicit re-authentication of the
>end user (by the AS) to obtain a new token.
>
>Obviously, the train has left the station in terms of the core draft. 
>But I'm wondering if anybody else has come across such use cases
>before?
>
>
>Tx
>adam
>
>
>
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>OAuth mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/oauth

---

From: "Richer, Justin P." <[email-masked]>
Date: Fri, 14 Sep 2012 14:18:30 +0000

I don't think it actually makes sense in core anyway, because there are flows where there's no user interaction and such a parameter doesn't make any sense. This is the kind of thing that would fit really well with the UX extension that David put up two years ago:

http://tools.ietf.org/html/draft-recordon-oauth-v2-ux-00

As far as I know, nobody's picked it up or stated that they intend to keep bringing it forward as its own extension, but OIDC has picked up the "display" parameter and extended the context with the "prompt" parameter (among others).

 -- Justin

On Sep 13, 2012, at 4:36 PM, Lewis Adam-CAL022 wrote:

Hi,

I have some high assurance use cases where my resource servers will require a certain “freshness” of the access token.  The RS will only accept a AT within a certain lifetime (say for example 1hr).  If a client presents an AT to the RS that was minted over 1hr ago, the RS (via its RESTful API) will return an error message indicating such to the client.  Further, the RS requires explicit re-authentication of the end user (by the AS) to obtain a new token.

Obviously, the train has left the station in terms of the core draft.  But I’m wondering if anybody else has come across such use cases before?

Tx
adam

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth