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

Casper Biering cb at peercraft.com
Tue Nov 6 16:56:44 UTC 2012


> I'm not sure how you'd do an OP->RP push in a simple fashion

------------
Option 1: I would put a session_update_endpoint url inside either the
Client Registration Request or OpenID Request Object, the later would
give it more flexibility (similar to redirect_uri).

The Authorization Server would send a HTTP(S) POST request to the
session_update_endpoint with two params:
- id_token
- status

The status parameter should be the same value as the RP would get
through your proposed "Introspection Endpoint".
------------

Since option 1 might send the id_token and status unencrypted, I have
added an alternative option, which is a litte more complex.

------------
Option 2: I would put a session_update_endpoint url inside either the
Client Registration Request or OpenID Request Object, the later would
give it more flexibility (similar to redirect_uri).

If session_update_endpoint is defined, The Authorization Server puts a
session_id key (opaque to the RP) inside the ID token.

When the session is revoked at the OP, the OP would send a HTTP(S) POST
request to the session_update_endpoint with two params:
- iss (issuer)
- session_id

If iss and session_id matches, the RP looks up the id_token and sends it
to your proposed "Introspection Endpoint" to get the status.
------------

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

Yes, but open websites would get "instant"-signout as well, since
polling every second has extremely low overhead.

To sum up af few RP website implementation options:

------------
Case 1: Current proposal, browser polling method (eg. every 3 secs)
+ Instant signout for open websites.
- Instant signout for closed websites.
+ Low network overhead
- Prevents OP tracking for every viewed page on multi-page websites.
  (see comment 1)
- Stable revisits (see comment 2)
- No iframes allowing OPs to break out
- Older browser support
- No extra channel between browser and serverside
  (see comment 3)
- Support for NoScript browsers
------------

------------
Case 2: Justin proposal, browser direct to OP polling (eg. every 15 min)
- Instant signout for open websites.
- Instant signout for closed websites.
- Low network overhead
+ Prevents OP tracking for every viewed page on multi-page websites.
  (see comment 1)
- Stable revisits (see comment 2)
+ No iframes allowing OPs to break out
- Older browser support
- No extra channel between browser and serverside
  (see comment 3)
- Support for NoScript browsers
------------

------------
Case 3: Justin proposal, browser through serverside polling (eg. every
15 min)
- Instant signout for open websites.
- Instant signout for closed websites.
- Low network overhead
+ Prevents OP tracking for every viewed page on multi-page websites.
  (see comment 1)
- Stable revisits (see comment 2)
+ No iframes allowing OPs to break out
+ Older browser support
+ No extra channel between browser and serverside
  (see comment 3)
- Support for NoScript browsers
------------

------------
Case 4: Justin proposal, serverside cron polling (eg. every 15 min)
- Instant signout for open websites.
- Instant signout for closed websites.
- Low network overhead
+ Prevents OP tracking for every viewed page on multi-page websites.
  (see comment 1)
+ Stable revisits (see comment 2)
+ No iframes allowing OPs to break out
+ Older browser support
- No extra channel between browser and serverside
  (see comment 3)
+ Support for NoScript browsers
------------

------------
Case 5: Justin proposal + OP push method
+ Instant signout for open websites.
+ Instant signout for closed websites.
+ Low network overhead
+ Prevents OP tracking for every viewed page on multi-page websites.
  (see comment 1)
+ Stable revisits (see comment 2)
+ No iframes allowing OPs to break out
+ Older browser support
- No extra channel between browser and serverside
  (see comment 3)
+ Support for NoScript browsers

To increase reliability RPs could do cron polling (eg. every 1 hour)
------------

------------
Case 6 & 7 (variations on cases 2 & 3): If you increase the polling
frequency to every page load and afterwards every 30-60 secs when idle,
you could get something similar to "Instant signout for open websites",
but will drastically increase traffic.
------------

------------
Comment 1: For single-page websites (such as Facebook, Google Calendar,
Remember The Milk etc.) tracking might not be a large problem.

Tracking can be minimized on multi-page websites (such as nytimes.com,
openid.net etc.) by only inserting iframes once in a while (eg. every 15
min). But then you loose instant signout.
------------

------------
Comment 2: This is what happens, when an implementation does not support
"stable revisits".

1. User A goes to Website A and signs in.
2. After some time, User A leaves and goes to Website B (or closes the
browser tab).
3. After some time, User A signs out of his OP.
4. After some time, User A (or another user at the same PC) revisits
Website A.
5. Website A says "Hello User A".
6. After a only few seconds (hopefully), Website A says "Ups, you are
actually not signed in!".

------------
Comment 3: In case of browser polling, the browser needs to tell the
server that the user is no longer signed in. This could be done using
existing comet/websockets, ajax call or a page redirect.

In case of serverside push or pulling, the server might want to tell the
browser that the user is no longer signed in. This cloud be done using
existing comet/websockets, using an ajax call every 30 seconds, or wait
to tell the user until reaches a new page. The last option is what most
websites do right now anyway if the user has multiple tabs open for the
same website.
------------

My preferred implementation is case 5, but depending on website policies
and system limitations case 4 or 3 could easily be used.

-- 
-- Casper


On Mon, 2012-11-05 at 19:02 +0000, Richer, Justin P. 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
> > 
> 



More information about the Openid-specs-ab mailing list