[Openid-specs-ab] Connect Flows and Userinfo Endpoint

Fri Jan 7 16:51:54 UTC 2011

There are other advantages of returning the token in the UserInfo endpoint.
An important one is that it alleviates concerns about token length.

On Fri, Jan 7, 2011 at 08:46, Nat Sakimura <sakimura at gmail.com> wrote:

> Hideki's suggestion was to return a JWT token that has user_id etc. within
> as access_token. It should work as long as the resource
> endpoint understands the access_token.
>
> A issue however comes up if we have a OAuth 2.0 Resource Endpoint that we
> do not want to change. Then, the Authorization Server is constrained to
> issue the access_token the way it has been doing and cannot convert the
> access_token to the JWT token.
>
> I am interested to find out if there are so many Resource Endpoints that
> falls under this category. If it is negligible, then we can drop this
> requirement.
>
> =nat
>
>
> On Sat, Jan 8, 2011 at 1:13 AM, Breno de Medeiros <breno at google.com>wrote:
>
>>
>>
>> On Fri, Jan 7, 2011 at 08:06, Nat <sakimura at gmail.com> wrote:
>>
>>> That is the whole point I and Hideki was making.
>>>
>>> I assumed that what David is pointing out is that the protected resource
>>> being a PoCo endpoint directly or existing OAuth endpoint.
>>>
>>
>> Nat, could you be more explicit. I am not sure what point you and Hideki
>> were making.
>>
>> As for the protected resource being an existing OAuth endpoint, I think
>> that is an orthogonal issue to a large extent.
>>
>>
>>>
>>> =nat via iPhone
>>>
>>> On 2011/01/08, at 0:24, John Bradley <ve7jtb at ve7jtb.com> wrote:
>>>
>>> One of the motivating factors of the JWT is that it can be a oAuth access
>>> token.
>>>
>>> It seems simpler to include claims like userID in the signed access
>>> token,  rather than having to include a separate access token inside.
>>> The access token is for the user info endpoint in ether case.
>>>
>>> Accessing public info at the user-info endpoint without a token should
>>> not be impacted by the access token format.  Am I missing something?
>>>
>>> If you get the access token through some other flow there is no
>>> particular issue with it being a JWT or some other format as long as the
>>> protected resource understands it.
>>>
>>> Or are you talking about the protected resource being a PoCo endpoint
>>> directly?
>>>
>>> John B.
>>>
>>>
>>> On 2011-01-07, at 6:39 AM, Nat Sakimura wrote:
>>>
>>> Hmmm. That is interesting. So, it means that I should not optimize for
>>> the OpenID/OAuth use cases. The two cases below are different use cases than
>>> the OpenID/OAuth protected resource access. Is there any other use cases
>>> that people have in mind?
>>>
>>> On Fri, Jan 7, 2011 at 4:43 PM, David Recordon < <dr at fb.com>dr at fb.com>wrote:
>>>
>>>>  I see two cases which may not work here:
>>>>
>>>>    1. you're requesting public data in which case just a userid is
>>>>    required and no access token or JWT
>>>>
>>>> For accessing public data, one can always ask without a token.
>>> (I actually like the <http://graph.facebook.com/username>
>>> graph.facebook.com/username style access.)
>>> Using JWT received as a token to access restricted content does not
>>>  prevent this behavior.
>>> Am I missing something? (In the older version of the connect proposal, it
>>> was returning such URL instead of opaque user_id. That was good.) So this
>>> does not seem to be a blocking factor.
>>>
>>>
>>>
>>>
>>>>    1. you got the access token via a non-OpenID OAuth 2.0 flow. I can
>>>>    imagine a PoCo endpoint doubling as the OpenID user info API.
>>>>
>>>> This probably is more relevant.
>>>
>>> Then the question would gets to the point Hideki pointed out:
>>> why cannot we make "signed" as we call now the "access_token" with
>>> token_type=signed_openid?
>>> It will save us from defining an OAuth extension variable called "signed"
>>> and more OAuth2.0 compliant.
>>>
>>> (As a side issue: I started to feel that we probably do not need "code"
>>> in the OAuth2.0 spec., but just "access_token" with type="authz_code".
>>> "code" is just another type of access_token which can only be used once and
>>> at the authz endpoint.)
>>>
>>>
>>>
>>>>
>>>>   On 1/6/11 11:40 PM, "Nat Sakimura" < <sakimura at gmail.com>
>>>> sakimura at gmail.com> wrote:
>>>>
>>>>  Hi guys.
>>>>
>>>>  Do you have objection to passing the entire JWT ("signed") instead of
>>>> access_token and user_id extracted to the UserInfo endpoint?
>>>> That seems to be a lot simpler.
>>>>
>>>>  =nat
>>>>
>>>>
>>>
>>>
>>> --
>>> Nat Sakimura (=nat)
>>> <http://www.sakimura.org/en/>http://www.sakimura.org/en/
>>>  <http://twitter.com/_nat_en>http://twitter.com/_nat_en
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> <Openid-specs-ab at lists.openid.net>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
>>>
>>>
>>
>>
>> --
>> --Breno
>>
>
>
>
> --
> Nat Sakimura (=nat)
> http://www.sakimura.org/en/
> http://twitter.com/_nat_en
>

-- 
--Breno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110107/424c5a9b/attachment.html>