Subject: [OAUTH-WG] Assertion flow: please add optional refresh_token in response

From: Andrew Arnott <[email-masked]>
Date: Mon, 14 Jun 2010 20:31:39 -0700

For an application I'm building, the installed client app will have
intermittent windows of time where it can obtain a (non-OAuth) assertion for
user identity.  During this time, it seems appropriate for it to use the
assertion flow to obtain an OAuth authorization so that it can impersonate
the user.  So far this is just standard Assertion Flow stuff.  But without a
refresh_token, the app will break when the access token expires if the app
doesn't have the ability at the moment (due to not being on the corporate
network at the moment for example) to obtain a new assertion.  Since the
security model for this app would certainly allow for a refresh_token to be
issued from the original OAuth authorization server exchange, this would
solve it, if the spec didn't specifically ban such a parameter.

Also, the user identity is asserted to the authorization server *not*through an
*assertion* parameter but using Kerberos (I assume) as part of the HTTP
protocol, so perhaps the spec for the assertion flow can specifically allow
for assertions to be carried as part of the transport?

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 14 Jun 2010 20:50:01 -0700

First, the spec says "SHOULD NOT issue a refresh token" which means, don't do it unless you have to. But what stops the client from keeping the same assertion and reusing it later?

As for using other methods for providing an assertion, you need to be more specific about what you have in mind. But either way, you can extend the token endpoint to support other ways of providing assertions.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Arnott
Sent: Monday, June 14, 2010 8:32 PM
To: OAuth WG ([email-masked])
Subject: [OAUTH-WG] Assertion flow: please add optional refresh_token in response

For an application I'm building, the installed client app will have intermittent windows of time where it can obtain a (non-OAuth) assertion for user identity.  During this time, it seems appropriate for it to use the assertion flow to obtain an OAuth authorization so that it can impersonate the user.  So far this is just standard Assertion Flow stuff.  But without a refresh_token, the app will break when the access token expires if the app doesn't have the ability at the moment (due to not being on the corporate network at the moment for example) to obtain a new assertion.  Since the security model for this app would certainly allow for a refresh_token to be issued from the original OAuth authorization server exchange, this would solve it, if the spec didn't specifically ban such a parameter.

Also, the user identity is asserted to the authorization server not through an assertion parameter but using Kerberos (I assume) as part of the HTTP protocol, so perhaps the spec for the assertion flow can specifically allow for assertions to be carried as part of the transport?

--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre

---

From: Brian Eaton <[email-masked]>
Date: Mon, 14 Jun 2010 21:02:07 -0700

> solve it, if the spec didn't specifically ban such a parameter.

I think this is a different use case than the one envisioned by most
people who are using the assertion flow.

I'm inclined to steer different use cases to different profiles.  It
makes it much easier to guide deployments, for example.

Cheers,
Brian

---

From: Dick Hardt <[email-masked]>
Date: Mon, 14 Jun 2010 23:00:16 -0700

+1

On 2010-06-14, at 9:02 PM, Brian Eaton wrote:

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

---

From: Andrew Arnott <[email-masked]>
Date: Tue, 15 Jun 2010 06:58:45 -0700

Well it's easy enough for me to just make up a profile that follows rules I
set.  But since I don't think this need will be unique to myself, would you
like me to write up a spec somewhere? (I've never written an IETF spec
before)
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre

---

From: Andrew Arnott <[email-masked]>
Date: Tue, 15 Jun 2010 07:03:19 -0700

In this case, the assertion the client starts with is from Windows
authentication, and the assertion is obtained from an Active Directory
server that is inaccessible unless the client app is running on a computer
currently connected to the corporate network.  I imagine that assertion has
a limited lifetime, and the client doesn't have access to it anyway since it
is added to the HTTP request by the platform, and is a challenge-response
based protocol and therefore cannot be replayed later.

So sure, I can read "SHOULD NOT" as a recommendation and do it anyway (using
the standard parameter name refresh_token).  The assertion itself being a
challenge-response type thing in the transport itself, this profile seems to
apply even less unless it can be worded to say the assertion can be found
elsewhere. (there's precedence for this in the spec that talks about how
client credentials can be found in any of multiple places but must only be
found in ONE of them).

Let me know what you think.  If I need to invent my own profile I guess I
can do that.
--
Andrew Arnott
"I [may] not agree with what you have to say, but I'll defend to the death
your right to say it." - S. G. Tallentyre

On Mon, Jun 14, 2010 at 8:50 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> First, the spec says “SHOULD NOT issue a refresh token” which means, don’t
> do it unless you have to. But what stops the client from keeping the same
> assertion and reusing it later?
>
>
>
> As for using other methods for providing an assertion, you need to be more
> specific about what you have in mind. But either way, you can extend the
> token endpoint to support other ways of providing assertions.
>
>
>
> EHL
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Andrew Arnott
> *Sent:* Monday, June 14, 2010 8:32 PM
> *To:* OAuth WG ([email-masked])
> *Subject:* [OAUTH-WG] Assertion flow: please add optional refresh_token in
> response
>
>
>

---

From: Dick Hardt <[email-masked]>
Date: Tue, 15 Jun 2010 07:05:53 -0700

Why can the client app access the AS to get an access token but not the corporate network to get a new assertion?

How does the client app get the assertion to begin with? How did delegation from the user happen?

Would you elaborate more on the use case so that we can understand the full trust model?

The assertion flow was intended for autonomous clients rather than user delegation -- hence Brian's response and mine that this is a different flow if the access token is for user delegation.

-- Dick

On 2010-06-15, at 6:58 AM, Andrew Arnott wrote:

> Well it's easy enough for me to just make up a profile that follows rules I set.  But since I don't think this need will be unique to myself, would you like me to write up a spec somewhere? (I've never written an IETF spec before)
> --
> Andrew Arnott

---

From: Dick Hardt <[email-masked]>
Date: Tue, 15 Jun 2010 07:12:39 -0700

Are you envisioning the client makes a call to AD to get an assertion where the call is automagically authenticated as the user by NTLM? 

What do you envision being the relationship between the AS and AD? What authority does the AS have? How long is the refresh token valid for?

I think you have an interesting use case here, but it would be useful to step back and describe how the client got to the point you are envisioning per my last email.

-- Dick

On 2010-06-15, at 7:03 AM, Andrew Arnott wrote:

> In this case, the assertion the client starts with is from Windows authentication, and the assertion is obtained from an Active Directory server that is inaccessible unless the client app is running on a computer currently connected to the corporate network.  I imagine that assertion has a limited lifetime, and the client doesn't have access to it anyway since it is added to the HTTP request by the platform, and is a challenge-response based protocol and therefore cannot be replayed later.
> 
> So sure, I can read "SHOULD NOT" as a recommendation and do it anyway (using the standard parameter name refresh_token).  The assertion itself being a challenge-response type thing in the transport itself, this profile seems to apply even less unless it can be worded to say the assertion can be found elsewhere. (there's precedence for this in the spec that talks about how client credentials can be found in any of multiple places but must only be found in ONE of them).
> 
> Let me know what you think.  If I need to invent my own profile I guess I can do that.
> --
> Andrew Arnott
> On Mon, Jun 14, 2010 at 8:50 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> First, the spec says “SHOULD NOT issue a refresh token” which means, don’t do it unless you have to. But what stops the client from keeping the same assertion and reusing it later?
> 
>

---

From: Andrew Arnott <[email-masked]>
Date: Tue, 15 Jun 2010 08:19:16 -0700

Hi Dick,

Responses inline.

On Tue, Jun 15, 2010 at 7:12 AM, Dick Hardt <[email-masked]> wrote:

> Why can the client app access the AS to get an access token but not the
> corporate network to get a new assertion?
>

The corporate network where the AD lives is behind a firewall, whereas the
AS is on the public Internet.  So when the client is on the public Internet,
the AD is not available but the AS is.  Also, the resource server is on the
public Internet (probably obvious).

How does the client app get the assertion to begin with? How did delegation
> from the user happen?

There are two possible scenarios here, which I will outline and inject the
steps in each scenario:

   1. The client app is initially launched while on the corporate network
      1. The client sends an HTTP request to *an *endpoint on a *corpnet *AS(1)
      (directly -- not through a browser), which sniffs the request for NTLM
      credentials (or however Windows auth does it) and if present immediately
      responds with an authorization code (a.k.a. verification code)
rather than
      prompting the user for permission.  This is considered reasonable in this
      application because the client is already running on a trusted
machine and
      the privacy ramifications are minimal.
      2. The client app exchanges the authorization code for a refresh token
      and an access token at the AS(2) token endpoint, which lies outside the
      corporate firewall, and can thereby refresh access tokens when
the client is
      off corpnet.
      3. All resource requests use an OAuth access token to gain access.
      2. The client app is initially launched *off* the corporate network.
      1. This just uses the standard user agent or web server flows,
      including prompting the user for authorization.

> Would you elaborate more on the use case so that we can understand the full

Perhaps my description above covers this question.  I'll just add that the
goal is to make the authorization process as painless (or altogether absent
from the user's point of view) as possible.  We're also considering
providing customized app downloads to each user based on the Windows auth
user that downloads the .zip file, such that the client app includes a file
containing the authorization code encoded for that particular user.

> The assertion flow was intended for autonomous clients rather than user
> delegation -- hence Brian's response and mine that this is a different flow
> if the access token is for user delegation.
>

That makes sense.

Are you envisioning the client makes a call to AD to get an assertion where
> the call is automagically authenticated as the user by NTLM?
>

Perhaps my scenarios above clarified this. My client never explicitly calls
AD though.  Whether that happens implicitly by the Windows platform, I don't
know.

What do you envision being the relationship between the AS and AD? What
> authority does the AS have? How long is the refresh token valid for?
>

The refresh token would be valid until the user logged into the AS (or RS
perhaps) to revoke it. The AD is altogether unaware of the AS, but the AS
trusts the AD to have authenticated the user and trusts the AD assertion.

---

From: George Fletcher <[email-masked]>
Date: Tue, 15 Jun 2010 11:40:04 -0400

To me, the use case described is more similar to the "Username and 
Password flow" but where the user credentials are NOT username & 
password. Should we have two "user credential" flows? (1) Username and 
Password and (2) assertion/token? I can see it being useful to have a 
"user credential" flow that allows for other means of verifying the user 
identity than just username and password. Otherwise, I think the 
semantics of the flow should be the same.

Thoughts?

Thanks,
George

On 6/15/10 11:19 AM, Andrew Arnott wrote:
> Hi Dick,
>
> Responses inline.
>
> On Tue, Jun 15, 2010 at 7:12 AM, Dick Hardt <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Why can the client app access the AS to get an access token but
>     not the corporate network to get a new assertion?
>
>
> The corporate network where the AD lives is behind a firewall, whereas 
> the AS is on the public Internet.  So when the client is on the public 
> Internet, the AD is not available but the AS is.  Also, the resource 
> server is on the public Internet (probably obvious).
>
> There are two possible scenarios here, which I will outline and inject 
> the steps in each scenario:
>
>          1. The client sends an HTTP request to /an /endpoint on a
>             /corpnet /AS(1) (directly -- not through a browser), which
>             sniffs the request for NTLM credentials (or however
>             Windows auth does it) and if present immediately responds
>             with an authorization code (a.k.a. verification code)
>             rather than prompting the user for permission.  This is
>             considered reasonable in this application because the
>             client is already running on a trusted machine and the
>             privacy ramifications are minimal.
>          2. The client app exchanges the authorization code for a
>             refresh token and an access token at the AS(2) token
>             endpoint, which lies outside the corporate firewall, and
>             can thereby refresh access tokens when the client is off
>             corpnet.
>    2. The client app is initially launched /off/ the corporate network.
>          1. This just uses the standard user agent or web server
>             flows, including prompting the user for authorization.
>
>
> Perhaps my description above covers this question.  I'll just add that 
> the goal is to make the authorization process as painless (or 
> altogether absent from the user's point of view) as possible.  We're 
> also considering providing customized app downloads to each user based 
> on the Windows auth user that downloads the .zip file, such that the 
> client app includes a file containing the authorization code encoded 
> for that particular user.
>
>
>     The assertion flow was intended for autonomous clients rather than
>     user delegation -- hence Brian's response and mine that this is a
>     different flow if the access token is for user delegation.
>
>
> That makes sense.
>
>     Are you envisioning the client makes a call to AD to get an
>     assertion where the call is automagically authenticated as the
>     user by NTLM?
>
>
> Perhaps my scenarios above clarified this. My client never explicitly 
> calls AD though.  Whether that happens implicitly by the Windows 
> platform, I don't know.
>
>     What do you envision being the relationship between the AS and AD?
>     What authority does the AS have? How long is the refresh token
>     valid for?
>
>
> The refresh token would be valid until the user logged into the AS (or 
> RS perhaps) to revoke it. The AD is altogether unaware of the AS, but 
> the AS trusts the AD to have authenticated the user and trusts the AD 
> assertion.
>
>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Tue, 15 Jun 2010 17:54:05 +0200

Wouldn't it be an alternative solution, if the AS first tries to  
authenticate the user using SPNEGO within the Web Server flow? This  
should work in the inhouse scenario. If it fails, it can fall back to  
username/password auth..

Thoughts?

regards,
Torsten.

Am 15.06.2010 um 17:19 schrieb Andrew Arnott <[email-masked]>:

> Why can the client app access the AS to get an access token but not  
> the corporate network to get a new assertion?
>
> The corporate network where the AD lives is behind a firewall,  
> whereas the AS is on the public Internet.  So when the client is on  
> the public Internet, the AD is not available but the AS is.  Also,  
> the resource server is on the public Internet (probably obvious).
>
> There are two possible scenarios here, which I will outline and  
> inject the steps in each scenario:
> The client app is initially launched while on the corporate network
> The client sends an HTTP request to an endpoint on a corpnet AS(1)  
> (directly -- not through a browser), which sniffs the request for  
> NTLM credentials (or however Windows auth does it) and if present  
> immediately responds with an authorization code (a.k.a. verification  
> code) rather than prompting the user for permission.  This is  
> considered reasonable in this application because the client is  
> already running on a trusted machine and the privacy ramifications  
> are minimal.
> The client app exchanges the authorization code for a refresh token  
> and an access token at the AS(2) token endpoint, which lies outside  
> the corporate firewall, and can thereby refresh access tokens when  
> the client is off corpnet.
> All resource requests use an OAuth access token to gain access.
> The client app is initially launched off the corporate network.
> This just uses the standard user agent or web server flows,  
> Perhaps my description above covers this question.  I'll just add  
> that the goal is to make the authorization process as painless (or  
> also considering providing customized app downloads to each user  
> based on the Windows auth user that downloads the .zip file, such  
> that the client app includes a file containing the authorization  
> code encoded for that particular user.
>
>
> assertion where the call is automagically authenticated as the user  
> by NTLM?
>
> Perhaps my scenarios above clarified this. My client never  
> explicitly calls AD though.  Whether that happens implicitly by the  
> Windows platform, I don't know.
>
> What authority does the AS have? How long is the refresh token valid  
> for?
>
> The refresh token would be valid until the user logged into the AS  
> (or RS perhaps) to revoke it. The AD is altogether unaware of the  
> AS, but the AS trusts the AD to have authenticated the user and  
> trusts the AD assertion.

---

From: Brian Eaton <[email-masked]>
Date: Tue, 15 Jun 2010 15:35:38 -0700

On Tue, Jun 15, 2010 at 8:54 AM, Torsten Lodderstedt
<[email-masked]> wrote:
> authenticate the user using SPNEGO within the Web Server flow? This should
> work in the inhouse scenario. If it fails, it can fall back to
> username/password auth..

This would let you skip password entry, but I think you'd still
require user confirmation to grant the access.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Fri, 18 Jun 2010 08:51:18 +0200

> require user confirmation to grant the access.

which is ok, if you want to involve the user in the process. So he/her 
realizes what's going on.

Otherwise, the assertion workflow would be the better choice.

regards,
Torsten.