[Openid-specs-ab] client_credentials grant_type

Dale Olds olds at vmware.com
Mon Sep 17 17:27:12 UTC 2012


If I understand the original use case, a client wants to get claims 
about a specific subject, but does not have the subject's access token 
with scope openid, etc. Therefore, it is natural to use a client 
credentials grant, but the client just needs a way to specify the 
subject to the /userinfo endpoint.

We see this pattern quite frequently, but we did not extend the 
/userinfo for per-subject client use. It would be hard to predict all 
the ways in which a client application may want to get information about 
users and potentially modify the user info.  Some applications need a 
small bit of info about the user, some start off that way and then turn 
into are rather substantial user account management apps. So the usual 
pattern for our system is to use client credentials grant and the scim 
protocol for info regarding other subjects (uses), and Connect for 
authentication/userinfo stuff.

I'd like to support Connect as much possible, but I guess the question 
is purpose of the protocol. If a client wants to get information about a 
user for which it does not have a token (i.e. it is not operating on 
behalf of that user), then I would think it's making a directory service 
request.

--Dale

On 09/17/2012 06:49 AM, John Bradley wrote:
> In some ways it is standard OAuth , but standard OAuth doesn't specify 
> how identify the subject , request claims or retrieve the result.
>
> You could do all of that from scratch, but it may be useful to use 
> what already exists in Connect.   That could be done as part of 
> Connect or a separate spec that profiles Connect.
>
> John B.
> On 2012-09-17, at 2:30 AM, Torsten Lodderstedt 
> <torsten at lodderstedt.net <mailto:torsten at lodderstedt.net>> wrote:
>
>> Hi John,
>>
>> ressource owner password credential grant makes definitely sense in 
>> my opinion. I'm not sure for client credentials, esp. w/o id_token, 
>> as this boils down to standard OAuth to get access to the user info 
>> endpoint.
>>
>> Regards,
>> Torsten.
>>
>>
>>
>> John Bradley <ve7jtb at ve7jtb.com <mailto:ve7jtb at ve7jtb.com>> schrieb:
>>
>>     Last week I had several conversations with FICAM people around OAuth and Connect.
>>
>>     One thing that they do and is also not uncommon in enterprises is permission access based on client credentials.
>>     Think SAML Attribute query.
>>
>>     We do have that in OAuth 2.0.
>>
>>     One thing we don't say in Connect is how to support that grant_type.
>>
>>     It seems fairly strait forward that you would have a scope of openid and any other user_info related scopes, that nonce and state are not required.
>>     Returning a id_token probably doesn't make sense.
>>
>>     To specify the user who is the subject we already have a way of passing the required user_id in the request object.
>>
>>     I can see this being useful to compliment or replace a SAML/SOAP flow.
>>
>>     We don't specifically talk about this or the Resource owner Password credentials Grant.
>>
>>     As
>>     long as we don't do something in the core specs to preclude them we could put them in a separate profile as they are sort of special case.
>>
>>     John B.
>>
>>
>>     ------------------------------------------------------------------------
>>
>>     Openid-specs-ab mailing list
>>     Openid-specs-ab at lists.openid.net  <mailto:Openid-specs-ab at lists.openid.net>
>>     http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>
>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20120917/b11c3c74/attachment.html>


More information about the Openid-specs-ab mailing list