[Openid-specs-ab] Lite Draft 9

Nat Sakimura sakimura at gmail.com
Thu Aug 25 01:05:39 UTC 2011


Nov,

I see. That is a very important feedback.

All:
We should consider this as well on the next call.

=nat

On Thu, Aug 25, 2011 at 10:03 AM, nov matake <nov at matake.jp> wrote:
> Rack is the most commonly used HTTP layer middleware in Ruby world.
> Almost all web application frameworks in Ruby are built on top of Rack. (and Rails is the most major one among them)
>
> It provides basic web server features. (Eg. convert HTTP request to Ruby object, parse query/body/header params etc.)
> It also has Basic Authentication support and the feature is widely used in APIs written in Ruby.
> My Rack::OAuth2 provides similar interface with Rack's Basic Authentication feature.
>
> But in Rails, routing information is written in Rails layer, not Rack layer.
> So even if Rack middleware get the requested path info, it basically doesn't know which controller's which action is mapped to the path.
> So I'll need to hard code check session endpoint path info in middleware layer.
> That's why I don't prefer handling endpoint in Rack layer.
> (With current spec, I'll ignore any access tokens containing 2 "." and handle it in Rails layer)
>
> On 2011/08/25, at 9:29, Nat Sakimura wrote:
>
>> On Thu, Aug 25, 2011 at 9:15 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>>> Brenno was the one that wanted to make the check session endpoint a standard OAuth protected resource, protecting and passing the token in abby way supported by OAuth.
>>>
>>> I am not opposed to treating it as a non OAuth endpoint and passing things in as form encoded.
>>> We need to decide if passing them as URL parameters is safe.  (probably not a good idea)
>>
>> It should not be a URL parameter.
>> It should be a POST.
>>
>>>
>>> Now that we need to pass both access and id_token the argument for protecting the id_token as if it were an access token is a bit weaker.
>>>
>>> I still don't understand why passing the id_token as the access token is harder for the OP.
>>
>> Right. That was a question that I was going to ask so that I
>> understand the issue accurately as well.
>>
>> Since I am not familier with Rack architecture, it is very kind of
>> you, Nov, if you could enlighten me why it is difficult to switch the
>> table depending on the endpoints. Check Session endpoint and the other
>> regular oauth2 resource endpoint are different endpoints (URLs). Is it
>> not easy to switch the table depending on the endpoint?
>>
>> FYI, I have no strong opinion on the "Check Session endpoint" per se.
>>
>> However, if I view it as a generic "JWT Introspection Endpoint", I
>> want an appropriate authorization happen before decrypting and
>> returning the content of the encrypted JWT, because it would then
>> defeat the purpose of audience restriction by encryption.
>>
>> =nat
>>
>>>
>>> It should be easier for the client if it supports receiving multiple tokens for different endpoints as some of them do.
>>>
>>> John
>>> On 2011-08-24, at 4:45 PM, Nat Sakimura wrote:
>>>
>>>> That further increases the length of the id_token.
>>>>
>>>> What Nov is making a point on is that, from a developer point of view,
>>>> since usual access_token and id_token are very different in its
>>>> characteristics, the argument that treating id_token as an
>>>> access_token to the check session endpoint makes the life for the
>>>> developer simpler because one can reuse OAuth library is simply not
>>>> true.
>>>>
>>>> In fact, it would pose a significant challenge in some cases, so it is
>>>> better to make id_token as a parameter separate from an access_token
>>>> for the check session endpoint.
>>>>
>>>> Nov has been providing Rack-OAuth2 library for sometime, which is
>>>> being used in many places, so he may have some point as a developer
>>>> feedback.
>>>>
>>>> =nat
>>>>
>>>>
>>>> On Thu, Aug 25, 2011 at 2:56 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>>>>> Yes that is what the OP check session endpoint is supposed to do.
>>>>>
>>>>> Google has however added a bit of a twist on the last call.
>>>>>
>>>>> They are proposing that a hash of the access token be included in the id_token.
>>>>> The idea is that that allows a RP to know if the received access token relates to the id_token.
>>>>>
>>>>> That change would require the check session endpoint to take the user-info access token as a parameter, so that it can check the hash for the client.
>>>>>
>>>>> This is still being discussed, but could cause a change in the current Check Session endpoint.
>>>>>
>>>>> I am inclined to leave the check session endpoint as is, and make the client calculate the hash if they want to.
>>>>> This correlation check between the two tokens is not required for the code flow, only the token flow to prevent cut and paste.
>>>>>
>>>>> John
>>>>> On 2011-08-23, at 7:03 PM, nov matake wrote:
>>>>>
>>>>>> Aren't you talking about RPs?
>>>>>>
>>>>>> If so, sorry for the confusing.
>>>>>> I'm on OP side now.
>>>>>>
>>>>>> This is the actual OP check session endpoint code in Ruby.
>>>>>> I just verify signature and return extracted JSON here.
>>>>>> https://github.com/nov/openid_connect_sample/blob/master/lib/check_session_endpoint.rb
>>>>>>
>>>>>> On 2011/08/24, at 2:10, Breno de Medeiros wrote:
>>>>>>
>>>>>>> On Mon, Aug 22, 2011 at 19:00, nov matake <nov at matake.jp> wrote:
>>>>>>>> Since there is significant difference in its length between OAuth 2.0 access token and id_token,
>>>>>>>> I personally doesn't want to store them in the same table in DB.
>>>>>>>>
>>>>>>>> And I do access token validation in middleware layer in my Rails app, it's not so simple to lookup different token tables based on the requested endpoint.
>>>>>>>>
>>>>>>>> So handling id_token as access token doesn't seem simpler solution for me.
>>>>>>>
>>>>>>> The intended usage is to handle id_token as a cookie. You may rely on
>>>>>>> static validation to treat as a stateless credential or if you have
>>>>>>> session storage, you can store a shorter hash of the id_token to
>>>>>>> prevent re-validation everytime.
>>>>>>>
>>>>>>>>
>>>>>>>> Plus, in the current format of access token response, there are no information about the token type of id_token.
>>>>>>>> When the type of access token is Bearer, the type of id_token is always Bearer too?
>>>>>>>> What happens when the access token is MAC token or others?
>>>>>>>>
>>>>>>>> If we use id_token as access token, I prefer defining new access token type. (eg. use IdToken as Authorization Scheme)
>>>>>>>>
>>>>>>>> --
>>>>>>>> nov matake
>>>>>>>>
>>>>>>>> On 2011/08/23, at 5:21, John Bradley wrote:
>>>>>>>>
>>>>>>>>> Treating the id_token as the access token for the Check session endpoint, makes it clear what you need to do with it.
>>>>>>>>> We can invent a new unauthenticated API, but I think that is more complicated.
>>>>>>>>>
>>>>>>>>> I have had other providers talk about delivering multiple access tokens from a single request.
>>>>>>>>> I suspect that it will not be uncommon with OAuth 2.
>>>>>>>>>
>>>>>>>>> There are lots of reasons why a IdP might want to use different access tokens fro different services. especialy if they are stateless.
>>>>>>>>>
>>>>>>>>> John
>>>>>>>>> On 2011-08-22, at 4:04 PM, Breno de Medeiros wrote:
>>>>>>>>>
>>>>>>>>>> On Mon, Aug 22, 2011 at 13:00, Allen Tom <allentomdude at gmail.com> wrote:
>>>>>>>>>>> Hi Breno -
>>>>>>>>>>> I don't have much first hand experience with FB's signed_request, but my
>>>>>>>>>>> understanding is allows FB to return a signed response to an app, so that
>>>>>>>>>>> the app knows that it came from FB.
>>>>>>>>>>
>>>>>>>>>> Actually, signed_request is intended to be the identity assertion so
>>>>>>>>>> that apps can login users to their sites. The alternative is to make a
>>>>>>>>>> call to their version of the user info endpoint. In other words, the
>>>>>>>>>> FB Connect design is nearly identical to this.
>>>>>>>>>>
>>>>>>>>>>> https://developers.facebook.com/docs/authentication/signed_request/
>>>>>>>>>>> The docs don't say that there are two Access Tokens, instead the Access
>>>>>>>>>>> Token is a signed parameter contained within the signed_request.
>>>>>>>>>>> My concern regarding the id_token and the CheckSession API is that it could
>>>>>>>>>>> be confusing to tell developers that the id_token is an Access Token, but
>>>>>>>>>>> only for the CheckSession API. All other endpoints use the regular Access
>>>>>>>>>>> Token.
>>>>>>>>>>
>>>>>>>>>> The id_token can be statically validated, the CheckSession is a
>>>>>>>>>> convenience mechanism for those who don't want to implement static
>>>>>>>>>> validation.
>>>>>>>>>>
>>>>>>>>>> I think the CheckSession endpoint is morally an
>>>>>>>>>> non-authentication-required endpoint that cracks open the id_token.
>>>>>>>>>> Passing the id_token instead of the access_token may make it easier to
>>>>>>>>>> re-use code.
>>>>>>>>>>
>>>>>>>>>>> Allen
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Aug 22, 2011 at 12:31 PM, Breno de Medeiros <breno at google.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Aug 22, 2011 at 12:05, Allen Tom <allentomdude at gmail.com> wrote:
>>>>>>>>>>>>> I think it might be confusing to developers to have multiple access
>>>>>>>>>>>>> tokens.
>>>>>>>>>>>>> I don't think I've seen any other Connect/OAuth
>>>>>>>>>>>>> type implementations that
>>>>>>>>>>>>> return multiple access tokens. Are there any examples out there?
>>>>>>>>>>>>
>>>>>>>>>>>> Yes. Facebook Connect uses signed_request as the id_token.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> --Breno
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Openid-specs-ab mailing list
>>>>>>>>> Openid-specs-ab at lists.openid.net
>>>>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> --Breno
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Openid-specs-ab mailing list
>>>>> Openid-specs-ab at lists.openid.net
>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Nat Sakimura (=nat)
>>>> Chairman, OpenID Foundation
>>>> http://nat.sakimura.org/
>>>> @_nat_en
>>>
>>>
>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> Chairman, OpenID Foundation
>> http://nat.sakimura.org/
>> @_nat_en
>
>



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en


More information about the Openid-specs-ab mailing list