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

[Breno de Medeiros]

On Fri, Jan 7, 2011 at 07: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.
>

It becomes complicated when you consider that there will be multiple scopes
encoded in the request, not only for userinfo endpoint, but possibly for
other APIs.

A major advantage is that the OpenID Connect response becomes a simple
OAuth2 response, and works identically for both flows.


>
> Accessing public info at the user-info endpoint without a token should not
> be impacted by the access token format.  Am I missing something?
>

Well, yes. There have been problems with disclosing user identities through
the browser in initial authentication, with identity leaking through
embedded content, for instance. But if the identity is not encoded in the
response, then a token is needed for even public information at the UserInfo
endpoint to identify the user. Additionally, the UserInfo endpoint might be
able to provide information even for users that do not have public profile
data if the request always uses a token.


>
> 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.
>

Agreed.


>
> Or are you talking about the protected resource being a PoCo endpoint
> directly?
>

That's an orthogonal discussion, in my view.


>
> 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> 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 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> 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://twitter.com/_nat_en
> _______________________________________________
> Openid-specs-ab mailing list
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110107/b6e6cae9/attachment.html>