[Openid-specs-ab] Lite Draft 9

nov matake nov at matake.jp
Thu Aug 25 01:03:21 UTC 2011


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



More information about the Openid-specs-ab mailing list