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

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 <andrewarnott@gmail.com>:

> Hi Dick,
>
> Responses inline.
>
> On Tue, Jun 15, 2010 at 7:12 AM, Dick Hardt <dick.hardt@gmail.com>  
> 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:
> 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,  
> 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
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth