no user credentials use case (was: Appendix A missing wrap_client_id)

[Marius Scurtescu]

On Tue, Dec 1, 2009 at 3:55 PM, Dick Hardt <dick....@gmail.com> wrote:
>> There is another related use case, not captured explicitly in the
>> spec, when the server will trust the client to impersonate a set of
>> users without requiring the client to send user credentials. In this
>> profile the client must authenticate itself, like in profile 1 or 2,
>> and also specify what user it wants to impersonate. While this can be
>> easily implemented on top of profiles 1 and 2 with some additional
>> parameters, it could be useful to formalize.
>
> Would you elaborate on this use case? Perhaps a specific example? I'm confused if the user is involved or not.

Two examples:

1. An autonomous client collecting reporting data, just like in your
example, but when gathering customer data it needs to authenticate to
the protected resource as the customer. So the Access Token it
presents would be the exact same as coming from the actual customer.
No user involved in this case.

2. The user authenticates to the client using NTLM for example and
then the client needs to access to protected resource on behalf of the
client. If the "Username and Password" or "Web App" profiles were used
then the user would be prompted again for credentials. But if there is
a trust relationship between the Authorization Server and the Client,
then the client could ask for an Access Token on behalf of the user
and just claim that it did authenticate the user already.

--
Marius

[Dick Hardt]

On 2009-12-02, at 8:11 AM, Marius Scurtescu wrote:

> On Tue, Dec 1, 2009 at 3:55 PM, Dick Hardt <dick....@gmail.com> wrote:
>>> There is another related use case, not captured explicitly in the
>>> spec, when the server will trust the client to impersonate a set of
>>> users without requiring the client to send user credentials. In this
>>> profile the client must authenticate itself, like in profile 1 or 2,
>>> and also specify what user it wants to impersonate. While this can be
>>> easily implemented on top of profiles 1 and 2 with some additional
>>> parameters, it could be useful to formalize.
>>
>> Would you elaborate on this use case? Perhaps a specific example? I'm confused if the user is involved or not.
>
> Two examples:
>
> 1. An autonomous client collecting reporting data, just like in your
> example, but when gathering customer data it needs to authenticate to
> the protected resource as the customer. So the Access Token it
> presents would be the exact same as coming from the actual customer.
> No user involved in this case.

So it is acting as as the enterprise, correct? There is no user here, so I am not certain how it relates to your example above.

>
> 2. The user authenticates to the client using NTLM for example and
> then the client needs to access to protected resource on behalf of the
> client. If the "Username and Password" or "Web App" profiles were used
> then the user would be prompted again for credentials. But if there is
> a trust relationship between the Authorization Server and the Client,
> then the client could ask for an Access Token on behalf of the user
> and just claim that it did authenticate the user already.

A new profile could be written for how the Client uses NTLM to obtain an access token from the Authorization Server.

[Marius Scurtescu]

On Wed, Dec 2, 2009 at 1:28 PM, Dick Hardt <Dick....@microsoft.com> wrote:
>
> On 2009-12-02, at 8:11 AM, Marius Scurtescu wrote:
>
>> On Tue, Dec 1, 2009 at 3:55 PM, Dick Hardt <dick....@gmail.com> wrote:
>>>> There is another related use case, not captured explicitly in the
>>>> spec, when the server will trust the client to impersonate a set of
>>>> users without requiring the client to send user credentials. In this
>>>> profile the client must authenticate itself, like in profile 1 or 2,
>>>> and also specify what user it wants to impersonate. While this can be
>>>> easily implemented on top of profiles 1 and 2 with some additional
>>>> parameters, it could be useful to formalize.
>>>
>>> Would you elaborate on this use case? Perhaps a specific example? I'm confused if the user is involved or not.
>>
>> Two examples:
>>
>> 1. An autonomous client collecting reporting data, just like in your
>> example, but when gathering customer data it needs to authenticate to
>> the protected resource as the customer. So the Access Token it
>> presents would be the exact same as coming from the actual customer.
>> No user involved in this case.
>
> So it is acting as as the enterprise, correct? There is no user here, so I am not certain how it relates to your example above.

Yes, this would be an enterprise use case. There is no user, but from
the protected resource's point of view there is. The protected
resources do not know the difference, so no extra logic has to be
added to them to deal with an autonomous client.

>> 2. The user authenticates to the client using NTLM for example and
>> then the client needs to access to protected resource on behalf of the
>> client. If the "Username and Password" or "Web App" profiles were used
>> then the user would be prompted again for credentials. But if there is
>> a trust relationship between the Authorization Server and the Client,
>> then the client could ask for an Access Token on behalf of the user
>> and just claim that it did authenticate the user already.
>
> A new profile could be written for how the Client uses NTLM to obtain an access token from the Authorization Server.

I wondering about a more general profile in which the Authorization
Server thrust the Client and allows the client to impersonate a user.
This would cover both examples above.



--
Marius

[Dick Hardt]

On 2009-12-02, at 12:35 PM, Marius Scurtescu wrote:

> On Wed, Dec 2, 2009 at 1:28 PM, Dick Hardt <Dick....@microsoft.com> wrote:
>>
>> On 2009-12-02, at 8:11 AM, Marius Scurtescu wrote:
>>
>>> On Tue, Dec 1, 2009 at 3:55 PM, Dick Hardt <dick....@gmail.com> wrote:
>>>>> There is another related use case, not captured explicitly in the
>>>>> spec, when the server will trust the client to impersonate a set of
>>>>> users without requiring the client to send user credentials. In this
>>>>> profile the client must authenticate itself, like in profile 1 or 2,
>>>>> and also specify what user it wants to impersonate. While this can be
>>>>> easily implemented on top of profiles 1 and 2 with some additional
>>>>> parameters, it could be useful to formalize.
>>>>
>>>> Would you elaborate on this use case? Perhaps a specific example? I'm confused if the user is involved or not.
>>>
>>> Two examples:
>>>
>>> 1. An autonomous client collecting reporting data, just like in your
>>> example, but when gathering customer data it needs to authenticate to
>>> the protected resource as the customer. So the Access Token it
>>> presents would be the exact same as coming from the actual customer.
>>> No user involved in this case.
>>
>> So it is acting as as the enterprise, correct? There is no user here, so I am not certain how it relates to your example above.
>
> Yes, this would be an enterprise use case. There is no user, but from
> the protected resource's point of view there is. The protected
> resources do not know the difference, so no extra logic has to be
> added to them to deal with an autonomous client.

That the PR does not know the difference is a feature of WRAP. What am I missing?

>
>
>>> 2. The user authenticates to the client using NTLM for example and
>>> then the client needs to access to protected resource on behalf of the
>>> client. If the "Username and Password" or "Web App" profiles were used
>>> then the user would be prompted again for credentials. But if there is
>>> a trust relationship between the Authorization Server and the Client,
>>> then the client could ask for an Access Token on behalf of the user
>>> and just claim that it did authenticate the user already.
>>
>> A new profile could be written for how the Client uses NTLM to obtain an access token from the Authorization Server.
>
> I wondering about a more general profile in which the Authorization
> Server thrust the Client and allows the client to impersonate a user.
> This would cover both examples above.

How does the AS know it is the Client? Somehow the Client authenticates to the AS. What is the difference between the Client acting as itself and acting on behalf of a user where the user is not involved? It would seem to me to be a parameter provided by the Client to the AS to specify the user being impersonated. The Client still needs to Authenticate to the AS, which is what 5.1 and 5.2 do. When the user is delegating to the Client, the user is authenticating to the AS.

Am I missing something else?

-- Dick

[Evan Gilbert]

We may be interested in this profile as well (if I'm understanding correctly).

The PR may be looking at the userid + scope authorized by the token to determine whether a token can access a resource.

I don't see a standard way to get a user-scoped token for this case. 

 

>
>
>>> 2. The user authenticates to the client using NTLM for example and
>>> then the client needs to access to protected resource on behalf of the
>>> client. If the "Username and Password" or "Web App" profiles were used
>>> then the user would be prompted again for credentials. But if there is
>>> a trust relationship between the Authorization Server and the Client,
>>> then the client could ask for an Access Token on behalf of the user
>>> and just claim that it did authenticate the user already.
>>
>> A new profile could be written for how the Client uses NTLM to obtain an access token from the Authorization Server.
>
> I wondering about a more general profile in which the Authorization
> Server thrust the Client and allows the client to impersonate a user.
> This would cover both examples above.

How does the AS know it is the Client?

Here's input/output that would allow verifying the client and returning a user-scoped token.

Inputs:

 wrap_client_id

 wrap_client_secret

 wrap_username

 wrap_scopes

Outputs:

 wrap_refresh_token

 wrap_access_token

 wrap_access_token_expires_in

 Somehow the Client authenticates to the AS.  What is the difference between the Client acting as itself and acting on behalf of a user where the user is not involved? It would seem to me to be a parameter provided by the Client to the AS to specify the user being impersonated.

As noted above, think it is just a parameter - but would be useful to standardize.

The Client still needs to Authenticate to the AS, which is what 5.1 and 5.2 do. When the user is delegating to the Client, the user is authenticating to the AS.

There are cases where access has been granted by the user or an enterprise admin through a separate process. This profile would allow getting a token in these cases.

 

Am I missing something else?

-- Dick

--

You received this message because you are subscribed to the Google Groups "OAuth WRAP WG" group.
To post to this group, send email to oauth-...@googlegroups.com.
To unsubscribe from this group, send email to oauth-wrap-w...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/oauth-wrap-wg?hl=en.

[Evan Gilbert]

Following up on this suggestion - does anyone have concerns about adding this profile?

Use case is:

- Someone besides the user (usually a domain admin) grants access to a user's data

- Client needs a way to get a user-scoped token

[Dick Hardt]

Would you walk me/us through the use case in more detail (it is not obvious to me)? Why is a domain admin doing this? Where is the Client running?

[Evan Gilbert]

Yep, happy to:

1. User works at company.com
2. IT admin for company.com authorizes usefulapp.com to access Protected Resource for all users at company.com (through some AS-specific admin flow)
3. User logs in at usefulapp.com
4. To process requests at usefulapp.com, usefulapp's servers need to get a WRAP access token, scoped to User, for accessing Protected Resource.

[Dick Hardt]

Thanks for the crisp example Evan.

Checking i understand the scenario quickly: usefulapp.com is  a 3rd party app that is independent from company.com. Company.com users will use usefulapp.com to access protected resources at company.com.

In this scenario, step 3 where the user authenticates to usefulapp.com, company.com is usually involved since company.com manages provisioning and de-provisioning of users. While there are deployments where the user provides their username/password to usefulapp.com which then checks them with company.com, there is a growing preference for the usefulapp.com to redirect the user to company.com where an assertion is obtained and presented to usefulapp.com.

Usefulapp.com could take that same assertion and use the WRAP Assertion Profile to obtain an Access Token from the AS. Microsoft gave demos that had this flow at the recent PDC. Alternatively, once usefulapp.com knows which user, it could use its own credentials per 5.1 or 5.2 and obtain an Access Token, Once could imagine that the call to the AS included a parameter indicating which user, so that the Access Token has the user id embedded in it.

Does this make sense? Does it address the use case  you describe?

-- Dick

[Evan Gilbert]

On Mon, Dec 28, 2009 at 10:36 AM, Dick Hardt <Dick....@microsoft.com> wrote:

Thanks for the crisp example Evan.

Checking i understand the scenario quickly: usefulapp.com is  a 3rd party app that is independent from company.com. Company.com users will use usefulapp.com to access protected resources at company.com.

In this scenario, step 3 where the user authenticates to usefulapp.com, company.com is usually involved since company.com manages provisioning and de-provisioning of users. While there are deployments where the user provides their username/password to usefulapp.com which then checks them with company.com, there is a growing preference for the usefulapp.com to redirect the user to company.com where an assertion is obtained and presented to usefulapp.com.

Want to make sure I understand how an assertion might be obtained - few questions:

- What are possible mechanics of getting an assertion? (input parameters, output parameters, in browser redirect or on server)

- Does the 3rd party app need to get this assertion for every user at company.com?

- Is this assertion short-lived or long-lived?

[Dick Hardt]

To answer your questions below:

 

It is common practice with Google Apps and Salesforce.com to redirect the user to their organizations website and get back a SAML assertion.

 

The app needs to get the assertion for each user – that is how the app authenticates the user and knows the user is allowed access to the app. (ie, how step 3 happens in your example)

 

The assertion is usually shortlived.

 

Note that how the user authenticates to usefulapp.com and how userfulapp.com authenticates to company.com do not need to be the same assertion.

 

I can envision that the OpenID OAuth hybrid could evolve so that this use case is more straight forward. For example:

 

1.      Usefulapp.com does OpenID discovery to determine company.com is the OP for the user

2.      Usefulapp.com redirects user to company.com asking for profile data, OpenID and OAuth verification code.

3.      Usefulapp.com can obtain an Access Token and Refresh Token if it does not already have one to call company.com protected resources.

[Evan Gilbert]

Thanks for the example, definitely clarifies.

There's a second use case that makes this flow less optimal. As Marius mentioned in the original post, usefulapp.com may need to access data for User when User is not at their computer, and possibly when User has never gone to usefulapp.com. For example, a calendar reporting tool might need access to your calendar data. It would be useful for have a standard for service providers to create a user-scoped token without the user needing to be at the computer.

Also, for use cases where the user is at the browser, I think we have a good WRAP-only solution that doesn't require SAML assertions or OpenID. If the Web App profile supports an optional wrap_username (both for the existing spec and the new JS version that Luke is proposing), then usefulapp.com can just ask for the access token using the Web App profile:

1. usefulapp.com can make a call to https://company.com/authservice?wrap_client_id=usefulapp.com&wrap_username=us...@company.com&wrap_callback=https://usefulapp.com/authorization

2. company.com checks that user is logged in and usefulapp.com has access to protected resource

3. Depending on request type, request is redirected back to usefulapp.com, and this can redirect back with a verification code or an access token in the hash

[Dick Hardt]

In enterprise use cases, usefulapp.com is usually delegating authentication to company.com. That is why SAML / OpenID are needed – for usefulapp.com to know which user is being served and if they have access. Company.com is the authority not only on access to company.com protected resources, but also access to usefulapp.com. In contrast, in consumer use cases, usefulapp.com has a direct relationship with the user.

 

Per your second use case below, usually usefulapp.com has a contractual relationship with company.com, so 5.1 or 5.2 work well for usefulapp.com to access company.com protected resources when the user is not present. Given that usefulapp.com can use any token when calling company.com, what advantage is there to having the token user scoped? Why would company.com just have the user id as another parameter on APIs? The user is not present, and usefulapp.com can act on behalf of any user at company.com

 

Note in your example below, usefulapp.com does not learn who the user is from company.com – something usefulapp.com might need to know. That is where the OpenID part of the hybrid comes in.

 

-Dick

[Evan Gilbert]

On Mon, Dec 28, 2009 at 3:54 PM, Dick Hardt <Dick....@microsoft.com> wrote:

In enterprise use cases, usefulapp.com is usually delegating authentication to company.com. That is why SAML / OpenID are needed – for usefulapp.com to know which user is being served and if they have access. Company.com is the authority not only on access to company.com protected resources, but also access to usefulapp.com. In contrast, in consumer use cases, usefulapp.com has a direct relationship with the user.

Agreed this is very often the case. However, there are cases where the 3rd party has their own account system and may allow linking to your enterprise account.

Either way, it's not clear to me that SAML/OpenID is a requirement in this flow (this was an open topic during the WRAP discussion at Facebook). Naively, if you start with the WRAP authorization flow, you can easily get identity by calling an API from the service provider to get information about the logged in user (i.e., GET https://company.com/user, Authorization: WRAP access_token=ABC123).

 

Per your second use case below, usually usefulapp.com has a contractual relationship with company.com, so 5.1 or 5.2 work well for usefulapp.com to access company.com protected resources when the user is not present. Given that usefulapp.com can use any token when calling company.com, what advantage is there to having the token user scoped? Why would company.com just have the user id as another parameter on APIs? The user is not present, and usefulapp.com can act on behalf of any user at company.com

There are a few benefits of a user-scoped token:

1. Principle of least access - we don't have access tokens floating around that can access all of the data that usefulapp.com has access to. In general, I'd prefer that 3rd parties use tokens that are scoped to (wrap_username, wrap_scopes) unless there is a strong reason not to.
2. Allows for making requests on behalf of a specific user, even when the user is not at the computer. For example, a calendar client could look for meetings that you *might* be interested in attending. These requests need to return data that is the intersection of what the (app, user) can see.
3. Consistent usage of tokens. Many 3rd parties work with both individual users as well as users whose access is gated by an IT/domain admin. The same user can even be in both categories - companies allow individuals at the company to share some of their data with 3rd parties. For these cases, I think it is simpler and safer for the 3rd party to always use user-scoped token - it's one way to access data, and having a 3rd party work with both user-scoped access tokens and domain-scoped access tokens seems likely to lead to a bad mix-up.

[Dick Hardt]

On 2009-12-28, at 4:23 PM, Evan Gilbert wrote:

On Mon, Dec 28, 2009 at 3:54 PM, Dick Hardt <Dick....@microsoft.com> wrote:

In enterprise use cases, usefulapp.com is usually delegating authentication to company.com. That is why SAML / OpenID are needed – for usefulapp.com to know which user is being served and if they have access. Company.com is the authority not only on access to company.com protected resources, but also access to usefulapp.com. In contrast, in consumer use cases, usefulapp.com has a direct relationship with the user.

Agreed this is very often the case. However, there are cases where the 3rd party has their own account system and may allow linking to your enterprise account.

Agreed. Provisioning / de-provisioning then is done "manually".

Either way, it's not clear to me that SAML/OpenID is a requirement in this flow (this was an open topic during the WRAP discussion at Facebook). Naively, if you start with the WRAP authorization flow, you can easily get identity by calling an API from the service provider to get information about the logged in user (i.e., GET https://company.com/user, Authorization: WRAP access_token=ABC123).

Agreed. Sorry, was not implying that SAML/OpenID was required, merely stating that was common practice today.

The Web App Profile works fine for usefulapp.com to acquire an Access Token from company.com and as you suggest, call an API to learn the user.

Since company.com does not need permission from the user to grant access to usefulapp.com, the user experience at the AS can be optimized to only authenticate the user. If there is an active session or auto authn such as NTLM, then acquisition of the Access Token will be some redirects requiring no user interaction. Usefulapp.com can then store the Access Token and Refresh Token and call company.com in the user's context whenever needed.

In your use case, it seems you would like usefulapp.com to be able to call company.com before the user has visited usefulapp.com. Your suggestion as I understand it was the admin at company.com would get Access Tokens to usefulapp.com.

Here are a few thoughts intended to spark conversation.

The admin at company.com could go to usefulapp.com and use the web app profile to grant usefulapp.com an Access Token that can be used to make admin API calls to company.com, let's call this the Admin Access Token or ATT. There is a Refresh Token that is used to refresh the ATT. Usefulapp.com could then use ATT to acquire user level Access Tokens using the Assertion Profile, where ATT is the assertion. Company.com would require an additional parameter containing the user id in the Access Token acquisition call.

This enables company.com to revoke usefulapp.com's access by not issuing new ATT's, and user level rights can be embedded in the user Access Tokens, making it easier for company.com protected resources to apply user specific access control without a lookup.

Is this useful?

-- Dick

[osyrisdc]

You are suggesting a multi-domain Authentication and Authorization
model.

There needs to exist a trust relationship between the two domains. (I
am using the term domain loosely as it could easily represent multiple
corporate entities or divisions etc...)

In order to do this without lowering the perceived and/or actual
assurance level of the model, a secure backend user mapping standard
must be instituted.

I would move to remove the inclusion of this use case.

On Dec 28, 11:31 am, Evan Gilbert <uid...@google.com> wrote:
> Yep, happy to:
>
>    1. User works at company.com
>    2. IT admin for company.com authorizes usefulapp.com to access Protected

>    Resource for all users at company.com (through some AS-specific admin
>    flow)

>    3. User logs in at usefulapp.com
>    4. To process requests at usefulapp.com, usefulapp's servers need to get

>    a WRAP access token, scoped to User, for accessing Protected Resource.
>

> On Sun, Dec 27, 2009 at 11:43 PM, Dick Hardt <Dick.Ha...@microsoft.com>wrote:
>
> > Would you walk me/us through the use case in more detail (it is not obvious
> > to me)? Why is a domain admin doing this? Where is the Client running?
>
> > On 2009-12-21, at 10:05 PM, Evan Gilbert wrote:
>
> > Following up on this suggestion - does anyone have concerns about adding
> > this profile?
>
> > Use case is:
> > - Someone besides the user (usually a domain admin) grants access to a
> > user's data
> > - Client needs a way to get a user-scoped token
>
> > On Wed, Dec 2, 2009 at 5:34 PM, Evan Gilbert <uid...@google.com> wrote:
>
> >> Here's input/output that would allow verifying the client and returning a
> >> user-scoped token.
>
> >> Inputs:
> >>  wrap_client_id

> >> * wrap_client_secret*

> >>  wrap_username
> >>  wrap_scopes
>
> >> Outputs:
> >>  wrap_refresh_token
> >>  wrap_access_token
> >>  wrap_access_token_expires_in
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "OAuth WRAP WG" group.
> > To post to this group, send email to oauth-...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > oauth-wrap-w...@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/oauth-wrap-wg?hl=en.
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "OAuth WRAP WG" group.
> > To post to this group, send email to oauth-...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > oauth-wrap-w...@googlegroups.com<oauth-wrap-wg%2Bunsu...@googlegroups.com>

[Evan Gilbert]

On Mon, Dec 28, 2009 at 9:53 AM, osyrisdc <osyr...@gmail.com> wrote:

You are suggesting a multi-domain Authentication and Authorization
model.

There needs to exist a trust relationship between the two domains. (I
am using the term domain loosely as it could easily represent multiple
corporate entities or divisions etc...)

In order to do this without lowering the perceived and/or actual
assurance level of the model, a secure backend user mapping standard
must be instituted.

Can you clarify these concerns a little more? Specifically:

- How does this lower security?

- What do you mean by a secure backend user mapping standard?

[Evan Gilbert]

On Mon, Dec 28, 2009 at 8:22 PM, Dick Hardt <Dick....@microsoft.com> wrote:

In your use case, it seems you would like usefulapp.com to be able to call company.com before the user has visited usefulapp.com. Your suggestion as I understand it was the admin at company.com would get Access Tokens to usefulapp.com.

Here are a few thoughts intended to spark conversation.

The admin at company.com could go to usefulapp.com and use the web app profile to grant usefulapp.com an Access Token that can be used to make admin API calls to company.com, let's call this the Admin Access Token or ATT. There is a Refresh Token that is used to refresh the ATT. Usefulapp.com could then use ATT to acquire user level Access Tokens using the Assertion Profile, where ATT is the assertion. Company.com would require an additional parameter containing the user id in the Access Token acquisition call.

This enables company.com to revoke usefulapp.com's access by not issuing new ATT's, and user level rights can be embedded in the user Access Tokens, making it easier for company.com protected resources to apply user specific access control without a lookup.

Is this useful?

This flow meets the criteria that it works for most cases and is reasonably simple.

Few downsides:

- Requires a browser redirect to initiate getting a token. It would be useful to have a way to make calls that can be initiated by the 3rd party directly - this might allow recovery of tokens and avoids the failure mode of the 3rd party site being down.

- Requires has a different flow for obtaining a token for domain-admin managed access and user-managed access to data. For example, if I want to get an access token for b...@company.com, I need to see if I have a refresh token for bob in my store, and if not then I call and get an ATT to get an access token.

- It's going to be a more complex flow with possible per-provider differences. The wrap_scope parameter in the initial call to get an ATT would be hard to standardize, and we also have to document additional parameters on the assertion profile to support wrap_username.

What are the goals of this revised flow?

- Do you want to ensure that a user is at a browser at some point to get a token?

- Are we trying to avoid creating another profile?

- (or other)

-- Dick

[Dick Hardt]

On 2009-12-29, at 9:56 AM, Evan Gilbert wrote:

On Mon, Dec 28, 2009 at 8:22 PM, Dick Hardt <Dick....@microsoft.com> wrote:

In your use case, it seems you would like usefulapp.com to be able to call company.com before the user has visited usefulapp.com. Your suggestion as I understand it was the admin at company.com would get Access Tokens to usefulapp.com.

Here are a few thoughts intended to spark conversation.

The admin at company.com could go to usefulapp.com and use the web app profile to grant usefulapp.com an Access Token that can be used to make admin API calls to company.com, let's call this the Admin Access Token or ATT. There is a Refresh Token that is used to refresh the ATT. Usefulapp.com could then use ATT to acquire user level Access Tokens using the Assertion Profile, where ATT is the assertion. Company.com would require an additional parameter containing the user id in the Access Token acquisition call.

This enables company.com to revoke usefulapp.com's access by not issuing new ATT's, and user level rights can be embedded in the user Access Tokens, making it easier for company.com protected resources to apply user specific access control without a lookup.

Is this useful?

This flow meets the criteria that it works for most cases and is reasonably simple.

Few downsides:

- Requires a browser redirect to initiate getting a token. It would be useful to have a way to make calls that can be initiated by the 3rd party directly - this might allow recovery of tokens and avoids the failure mode of the 3rd party site being down.

I was envisioning that usefulapp.com had a web interface that the admin at company.com would use to setup the relationship. This could be out of band token as well. I only have the one browser redirect in the example above, and the ATT could be obtained with other methods. Not sure we are on the same page here.

- Requires has a different flow for obtaining a token for domain-admin managed access and user-managed access to data. For example, if I want to get an access token for b...@company.com, I need to see if I have a refresh token for bob in my store, and if not then I call and get an ATT to get an access token.

You could use the refresh token, or you could just just get a new Access Token each time with the ATT. The later is simpler. 

- It's going to be a more complex flow with possible per-provider differences.

The wrap_scope parameter in the initial call to get an ATT would be hard to standardize, and we also have to document additional parameters on the assertion profile to support wrap_username.

That is somewhat of an issue for all profiles. I can see there being a trend to standardize a set of APIs that use OAuth WRAP. Portable contacts is an example that comes to mind. If this is a common design pattern, I could envision formal or informal standardization of additional parameters and values for wrap_scope.

What are the goals of this revised flow?

- Do you want to ensure that a user is at a browser at some point to get a token?

That is not a requirement. In the example, only the admin is at the browser, and as mentioned above, the ATT could be acquired in a different way.

- Are we trying to avoid creating another profile?

- (or other)

I was describing how you could accomplish your use case using the existing spec. 

In my flow above, the web profile was used by the admin to delegate admin capability to usefulapp.com. Usefulapp.com is then able to obtain Access Tokens for users as required to act autonomously for the user -- a requirement I gathered as usefulapp.com needs to act on behalf of the user before the user has ever visited usefulapp.com.

If you think a new profile is warranted, I'd encourage you to write it up so that we have something concrete to reference. My intention was not to discourage a new profile -- I was wanting to understand the use case, and then was testing to see if existing profiles provided a solution. Happy to take the conversation in another direction if you like, or conclude it if we have reached a shared understanding.

-- Dick

[Evan Gilbert]

Thanks for all the useful feedback. Notes below...

On Tue, Dec 29, 2009 at 11:38 AM, Dick Hardt <Dick....@microsoft.com> wrote:

On 2009-12-29, at 9:56 AM, Evan Gilbert wrote:

On Mon, Dec 28, 2009 at 8:22 PM, Dick Hardt <Dick....@microsoft.com> wrote:

In your use case, it seems you would like usefulapp.com to be able to call company.com before the user has visited usefulapp.com. Your suggestion as I understand it was the admin at company.com would get Access Tokens to usefulapp.com.

Here are a few thoughts intended to spark conversation.

The admin at company.com could go to usefulapp.com and use the web app profile to grant usefulapp.com an Access Token that can be used to make admin API calls to company.com, let's call this the Admin Access Token or ATT. There is a Refresh Token that is used to refresh the ATT. Usefulapp.com could then use ATT to acquire user level Access Tokens using the Assertion Profile, where ATT is the assertion. Company.com would require an additional parameter containing the user id in the Access Token acquisition call.

This enables company.com to revoke usefulapp.com's access by not issuing new ATT's, and user level rights can be embedded in the user Access Tokens, making it easier for company.com protected resources to apply user specific access control without a lookup.

Is this useful?

This flow meets the criteria that it works for most cases and is reasonably simple.

Few downsides:

- Requires a browser redirect to initiate getting a token. It would be useful to have a way to make calls that can be initiated by the 3rd party directly - this might allow recovery of tokens and avoids the failure mode of the 3rd party site being down.

I was envisioning that usefulapp.com had a web interface that the admin at company.com would use to setup the relationship. This could be out of band token as well. I only have the one browser redirect in the example above, and the ATT could be obtained with other methods. Not sure we are on the same page here.

This seems reasonable. You're saying that there are many possible methods of getting an ATT,  and gave the web app flow as one option.

 

- Requires has a different flow for obtaining a token for domain-admin managed access and user-managed access to data. For example, if I want to get an access token for b...@company.com, I need to see if I have a refresh token for bob in my store, and if not then I call and get an ATT to get an access token.

You could use the refresh token, or you could just just get a new Access Token each time with the ATT. The later is simpler. 

(just to clarify - this use case was when b...@company.com might also have the ability to individually authorize. In the case where Bob individually authorized the client would have to use a refresh token to get an access token)

 

- It's going to be a more complex flow with possible per-provider differences.

The wrap_scope parameter in the initial call to get an ATT would be hard to standardize, and we also have to document additional parameters on the assertion profile to support wrap_username.

That is somewhat of an issue for all profiles. I can see there being a trend to standardize a set of APIs that use OAuth WRAP. Portable contacts is an example that comes to mind. If this is a common design pattern, I could envision formal or informal standardization of additional parameters and values for wrap_scope.

What are the goals of this revised flow?

- Do you want to ensure that a user is at a browser at some point to get a token?

That is not a requirement. In the example, only the admin is at the browser, and as mentioned above, the ATT could be acquired in a different way.

- Are we trying to avoid creating another profile?

- (or other)

I was describing how you could accomplish your use case using the existing spec. 

In my flow above, the web profile was used by the admin to delegate admin capability to usefulapp.com. Usefulapp.com is then able to obtain Access Tokens for users as required to act autonomously for the user -- a requirement I gathered as usefulapp.com needs to act on behalf of the user before the user has ever visited usefulapp.com.

If you think a new profile is warranted, I'd encourage you to write it up so that we have something concrete to reference. My intention was not to discourage a new profile -- I was wanting to understand the use case, and then was testing to see if existing profiles provided a solution. Happy to take the conversation in another direction if you like, or conclude it if we have reached a shared understanding.

Agreed that this use case is possible today. I'm hoping we can standardize enough of this flow so that 3rd parties might have consistent behavior across service providers.

This can either be by standardizing some parameters on existing profiles or by creating a new profile. I still have a slight leaning towards a new profile but could be influenced back to a layer on top of existing profiles. I'll document the option for a new profile soon.

[Dick Hardt]

On 2009-12-29, at 5:22 PM, Evan Gilbert wrote:

Thanks for all the useful feedback. Notes below...

On Tue, Dec 29, 2009 at 11:38 AM, Dick Hardt <Dick....@microsoft.com> wrote:

 

In my flow above, the web profile was used by the admin to delegate admin capability to usefulapp.com. Usefulapp.com is then able to obtain Access Tokens for users as required to act autonomously for the user -- a requirement I gathered as usefulapp.com needs to act on behalf of the user before the user has ever visited usefulapp.com.

If you think a new profile is warranted, I'd encourage you to write it up so that we have something concrete to reference. My intention was not to discourage a new profile -- I was wanting to understand the use case, and then was testing to see if existing profiles provided a solution. Happy to take the conversation in another direction if you like, or conclude it if we have reached a shared understanding.

Agreed that this use case is possible today. I'm hoping we can standardize enough of this flow so that 3rd parties might have consistent behavior across service providers.

I agree this is a good goal to have.

This can either be by standardizing some parameters on existing profiles or by creating a new profile. I still have a slight leaning towards a new profile but could be influenced back to a layer on top of existing profiles. I'll document the option for a new profile soon.

I look forward to it. It could be as simple as additional parameter standardization.

-- Dick