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

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Fri, 14 Sep 2012 15:20:43 +0000

Adam,

In your use case, how does AS request user re-authentication?
In OAuth the user agent is redirected back to the Client after the user has authorized the client.
The AS is a web server and cannot initiate a call to the user agent. I assume that the request to re-authenticate comes in a response from RS to the Client, and then the Client in a response to the user agent re-directs the user agent back to the AS for another round of authentication and authorization. Is this correct?
I would like to learn more about your use case. Do you have a pointer to a description?

Zachary

-------- Original Message --------
Subject:

[OAUTH-WG] prompt parameter for Authorization Request

Date:

Thu, 13 Sep 2012 20:36:13 +0000

From:

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

To:

[email-masked]<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>

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: Lewis Adam-CAL022 <[email-masked]>
Date: Tue, 18 Sep 2012 16:25:15 +0000

Hi Zachary,

Your assumption below is correct.

The use case is as follows:  We have OAuth clients (both native and confidential) the our users log into in order to access resources hosted by a high-assurance RS.  The assurance requirements of this RS requires that the end user who authenticated to the AS in order to enable the client with an access token is still actively logged onto the client.

The enablement of this is exactly as you describe.  The RESTful API between the client and RS enables the RS to instruct the client that its access token is now "stale" and no longer valid for accessing its protected resources.  At this point the client can redirect the end user back to the RS to re-authenticate, but the issue is that if the session with the AS is still valid, it will authenticate the end-user via a session cookie and not ask for primary credentials again.  So it would be nice to have a prompt-like parameter that would cause the AS to re-authenticate the end user via primary authentication.

I do realize (as Justin pointed out) that OAuth access tokens are designed to be usable even when the end user is not logged onto the client, but my use case (being higher assurance) explicitly requires that the user MUST be logged onto the client in order for the client to use the ATs.

-adam

From: Zeltsan, Zachary (Zachary) [mailto:[email-masked]]
Sent: Friday, September 14, 2012 10:21 AM
To: Lewis Adam-CAL022; [email-masked]
Subject: Re: [OAUTH-WG] prompt parameter for Authorization Request

Adam,

Zachary

-------- Original Message --------
Subject:

Date:

From:

To:

Hi,

Tx
adam

---

From: John Bradley <[email-masked]>
Date: Tue, 18 Sep 2012 14:20:34 -0300

There are two things going on that should probably not be conflated.   (Though openID Connect covers both)

If we are talking about OAuth there is a authorization grant request that goes to the Authorization server. 
The Authorization server's Authentication of the user is out of scope for OAuth,  LOA etc are all left up to the authentication protocol used by the Authorization server.

You could be chaining to SAML , AD or something else completely. 

For Oauth it makes sense to say re-prompt the user for consent, and Goole amongst others do that in some flows. 
That however doesn't typically affect the authentication that the Authorization server is doing.

The If the Authorization server has a policy to re-authenticate every time and the underlying protocol has a way to do that, you can have the Authorization server always do that.

Your alternative is just use the mechanisms in Connect which can control both Authentication and Authorization,  You may not care about the id_token in the response, but you can use the request mechanism to trigger the user to be re-authenticated if they haven't done so in x amount of seconds etc.

Your other alternative is to pop a new browser each time so that the session cookie won't exist.  That may happen anyway in some native app environments.

John B.

On 2012-09-18, at 1:25 PM, Lewis Adam-CAL022 <[email-masked]> wrote:

> The enablement of this is exactly as you describe.  The RESTful API between the client and RS enables the RS to instruct the client that its access token is now “stale” and no longer valid for accessing its protected resources.  At this point the client can redirect the end user back to the RS to re-authenticate, but the issue is that if the session with the AS is still valid, it will authenticate the end-user via a session cookie and not ask for primary credentials again.  So it would be nice to have a prompt-like parameter that would cause the AS to re-authenticate the end user via primary authentication. 
>  
> Lewis Adam-CAL022 <[email-masked]>
> To:
> [email-masked] <[email-masked]>
> 
> 
> 
> 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]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Zeltsan, Zachary (Zachary)" <[email-masked]>
Date: Tue, 18 Sep 2012 19:54:53 +0000

Adam,

Thanks. The use case is clear now.

Zachary

From: Lewis Adam-CAL022 [mailto:[email-masked]]
Sent: Tuesday, September 18, 2012 12:25 PM
To: Zeltsan, Zachary (Zachary); [email-masked]
Subject: RE: [OAUTH-WG] prompt parameter for Authorization Request

Hi Zachary,

-adam

Adam,

Zachary

-------- Original Message --------
Subject:

Date:

From:

To:

Hi,

Tx
adam