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

[George Fletcher <[e-mail]>]

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 <[e-mail] 
> <mailto:[e-mail]>> 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 trust model?
>
>
> 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.
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth