[Openid-specs-ab] An alternative session management proposal

Nat Sakimura sakimura at gmail.com
Mon Nov 5 22:52:22 UTC 2012


Just for the historical note:
The first incarnation of the session management sketch was more or less the
same as you have described, if I remember correctly.

Googlers changed it drastically at the last RSA meeting saying that their
implementation did not work too well. It could have been the scale issue
but there may have been others. I do not remember them off my head.

Nat

On Mon, Nov 5, 2012 at 8:02 PM, Richer, Justin P. <jricher at mitre.org> wrote:

> I'm not sure how you'd do an OP->RP push in a simple fashion, which is why
> I left it as polling only. The current approach is also polling based, it's
> just that it's using a side-effectful cookie edit to avoid network traffic
> during the poll.
>
>  -- Justin
>
> On Nov 5, 2012, at 9:57 AM, Casper Biering wrote:
>
> > I agree with the overall architecture.
> >
> > Personally I would like OPs to be able to push session changes to RPs in
> > this proposal as well, but I'm not 100% sure if the benefits outweighs
> > the increase in complexity. This should of course be optional for RPs.
> >
> > In your proposal you write "Ending a session is simply calling the
> > Revocation Endpoint with the id_token.". We should also be able to
> > handle that OPs might want to confirm the revocation with the user (when
> > dealing with untrusted RPs).
> >
> > --
> > -- Casper
> >
> >
> > On Mon, 2012-11-05 at 04:40 +0000, Richer, Justin P. wrote:
> >> I would like to propose an alternative method of handling session
> management in OpenID Connect. I believe that we can build this capability
> by making use of the id_token with a set of existing and proposed token
> management capabilities in OAuth2.
> >>
> >> Starting a new session is easy -- this is just vanilla OpenID Connect
> token issuance as it exists today. The id_token that you get issued is the
> representation of your session.
> >>
> >> Checking on the status is done through an Introspection Endpoint, using
> the id_token as an access_token. The community hasn't fully centered around
> a draft for an Introspection Endpoint yet, but there was a lot of interest
> in it at the last IIW and I think that there are some legs to this general
> mechanism. This also gives you dumb-client validation, which was thrown out
> with the Check ID Endpoint.
> >>
> >> Renewing the session is a little tricky, but since the id_token is a
> JWT, I think we can use the Assertion flow of OAuth2 to trade in one
> id_token for a new one. There are also a handful of approaches being
> discussed around methods of trading in one access token for another access
> token which might apply here.
> >>
> >> Ending a session is simply calling the Revocation Endpoint with the
> id_token. Note that this might keep the refresh token and access token
> still valid in the wild, depending on the application. Separation of these
> life cycles is, I argue, a good thing.
> >>
> >> This differs significantly from the current spec approach as it uses
> network calls as opposed to a JavaScript API to accomplish its goals. I
> already know this is going to cause cries of overusing the network, but I
> think that unless you're Google this isn't going to be as huge of a problem
> as it's been made out to be. In my view, this approach trades the extreme
> runtime scalability for a devleopment-time simplicity and flexibility (and
> therefore, deployment scalability, as it doesn't rely on a single vendor's
> implementation or a single runtime environment, like JavaScript). You can
> use the same functions on either the front channel (in the browser) or in
> the back channel, depending on your application's construction, with no
> differences to the protocol. It also works on native applications without
> relying on an embedded browser panel. Finally, it doesn't run afoul of
> browser cookie policies.
> >>
> >> In summary, I think this approach is much more simple to implement and
> architecturally more elegant, and all of the tools it would use to do its
> job would have general applicability in the wider OAuth2 world.
> >>
> >> -- Justin
> >>
> >>
> >> _______________________________________________
> >> 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
>



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20121105/fe2e2d38/attachment-0001.html>


More information about the Openid-specs-ab mailing list