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

Todd W Lainhart lainhart at us.ibm.com
Mon Nov 5 12:08:35 UTC 2012


FWIW, we needed session semantics in our application, so we ended up with 
defining new token, response and grant types for session, along with 
endpoints for validating (introspecting), extending, and terminating a 
session (i.e. it uses the network).  This using the extensibility 
mechanisms described in 6749.






From:   "Richer, Justin P." <jricher at mitre.org>
To:     "openid-specs-ab at lists.openid.net Working Group" 
<openid-specs-ab at lists.openid.net>
Date:   11/04/2012 11:40 PM
Subject:        [Openid-specs-ab] An alternative session management 
proposal
Sent by:        openid-specs-ab-bounces at lists.openid.net



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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20121105/80830a71/attachment-0001.html>


More information about the Openid-specs-ab mailing list